[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ungar@self: Re: macros / code construction]
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.
>Date: Thu, 31 Aug 1995 00:03:54 +0200
>From: email@example.com (Rainer Blome)
>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
>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?