real metalevel (was: blue ideas)
Marcel Weiher
marcel at metaobject.com
Mon Aug 26 22:16:47 UTC 2002
On Tuesday, August 27, 2002, at 12:03 Uhr, Jecel Assumpcao Jr wrote:
> On Monday 26 August 2002 09:53, Marcel Weiher wrote:
>> On Tuesday, August 20, 2002, at 10:06 Uhr, Alan Kay wrote:
>>> and some action somewhere between instantiation and cloning that
>>> would work better
>>
>> I am still swimming a bit on that one. There is plain "invocation",
>> supplying the required arguments and getting a result. But what is
>> the result? Either (a) "p-object + params" or (b) "result of some
>> message sent to p-object + params".
>>
>> Answer (a) is closer to normal instance creation, (b) is closer to
>> method invocation.
>
> In (a) you might have either p-object modified by the parameters or a
> clone of p-object modified by the parameters.
Those aren't the only options. You can also have a "context" object
(holding the parameters) refering to the original object, which isn't
modified. Just like a method is neither copied nor modified when you
call it. It just looks at the MethodContext for parameters.
> The latter is, as you
> say, like instanciation while the former is like assignment (another
> direction I was interested in exploring).
>
>> Then there is currying, which is "p-object + some params", clearly a
>> variant of (a). Interestingly enough, this would be considered a
>> refinement step similar to subclassing, but it could also be
>> considered partial instantiation.
>
> Beta uses these similarities to lump everything into a single "pattern"
> construct.
Yes, I just looked at Beta the other day, but somehow it didn't seem to
be what I am aiming for. I am also not sure that all this is a single
construct, but rather a continuum of related ones.
>> Existing method invocation is a special case of (b): the method is a
>> parametrized object, the method-context holds the parameters, it is
>> then sent the "value" message. This definition is, of course,
>> recursive, but that doesn't bother us, we just cut the recursion off
>> at the primitive level.
>
> Unless we don't care about reentrant methods, we had better copy them
> before sending "value". So, once again, this is like instanciation.
Quite the contrary, re-entrant code is achived without making copies of
methods all the time. In fact, I strongly believe that instantiation
is too complex/messy/procedural most of the time using just the example
of methods/functions: just imagine that everytime you wanted to call a
method, you'd have to make a copy first, then mutate that copy and
finally send value to it!
>>> We need a complete (or darn close) and real metasystem.
>>
>> How do we know when we have a complete metasystem? There are too
>> many different directions in wich we can abstract. Anyway, the only
>> credible candidate I've seen so far is the research done in software
>> architecture. They start off with "components" and "connectors", and
>> then refine from there.
>
> A complete metasystem would allow us to implement Squeak in Squeak.
> We
> don't have that now - we can implement *another* Squeak in Squeak,
> which isn't the same thing!
I am not sure I am getting the distinction you are making here.
Marcel
--
Marcel Weiher Metaobject Software Technologies
marcel at metaobject.com www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
More information about the Squeak-dev
mailing list
|