[ungar@self: Re: macros / code construction]

[Mario.Wolczko@Eng.Sun.COM (Mario Wolczko)]

Date: Wed, 30 Aug 1995 16:26:55 -0700
To: Mario.Wolczko@Eng (Mario Wolczko)
From: ungar@self (David Ungar)
Subject: Re: macros / code construction

We have had lots of discussions about
assignment, but what it boils down to for me is
that containers are appealingly intuitive notion,
and so I am happy to ground out where it does.
Going deeper does not seem to me to buy so much.

- Dave


>Date: Thu, 31 Aug 1995 00:03:54 +0200
>From: rainer@physik3.gwdg.de (Rainer Blome)
>To: self-interest@self.sunlabs.com
>Subject: macros / code construction
>
>
>yes, i know, macros as in the lisp family are a very unstructured way of
>doing things.  i don't actually care for macros, any way to make convenient
>the use of useful but awkward idioms would do.
>
>i have heard about beta's facilities in that direction but have only just
>printed the tutorial out, so i can't comment on that.  (as always: no
>library -> no book on beta :-( )  i like the common lisp/loops method
>combination stuff, so i guess i'll like beta, too.
>
>there are more things that i miss in self:  local methods and evaluation of
>literals in the dynamic context (dynamic?  lexical?  what does lexical mean
>anyway, when we don't have source-code anymore?).
>
>
>imagine doing assignment another way.  assignment is a hack (from the
>functional point of view).  it manipulates its context.  one should make
>that explicit by revealing the reflection involved in assignment.  first
>get an object that represents the place (the slot).  that is the reflective
>part.  then send it a normal message with the new value as an argument:
>
>(reflect: self slot: "x") store: 1
>
>(buggy, but you know what i mean.  how the slot implements the `store:'
>method?  don't you ask! ;-)
>
>of course, this is to be put as a method in the `assignment slot'.  now
>this `slot:' (meta-) message will always eval to the same object (the `x'
>slot), so it should not be computed every time the assignment method is
>called.
>
>note that the method now _explicitly_ `knows' the slot it refers to, as
>opposed to knowing that implicitly by reflecting on its (the method's) own
>slot name.  randy and dave mentioned a very similar way to implement
>assignment in their ecoop95 paper.
>
>to make this scheme feasible, two things are missing (that means, i
>can't see them, *I* might be missing them, not self, tell me if i do.):
>
>    a way to do computation during initialization
>
>    a convenient way to construct code.  writing this kind of
>    assignment methods must be automated.
>
>
>this is long already, i'll stop here.  any thoughts?  am i making sense?
>
>rainer

-- Dave