From: Durant Schoon (durant@ilm.com)
Date: Wed Jul 18 2001 - 12:25:52 MDT
> From: "Eliezer S. Yudkowsky" <sentience@pobox.com>
> Durant Schoon wrote:
> >
> > <human:sally>
> >
> > <appendage:arms>
> > <quantity:number> 2 </quantity:number>
> > </appendage:arms>
>
> Then there's an inconvenience when the programmer needs to type:
> sally.appendage:arms = 3
> instead of
> sally.arms = 3
> with even worse problems for longer expressions.
After reading your spec though, how about this? (it seems possibly
Flare-like to me):
The default arms in class <human> can be defined to be
<appendage:arms> so you can still write:
sally.arms = 3
which will be equivalent to: sally.appendage:arms = 3
If all you're doing is setting this one arg then, you're going to
have to say this anyway:
sally.quakegunner:arms = 3
just to distinguish from appendage:arms.
then you could do something like this (the concept is borrowed from
mel, the Maya Extensible Language - I don't like the language, but
this was the only interesting thing as far as I saw).
pushcontext(quakegunner)
sally.arms = 3
# lots of other quakegunner stuff here
popcontext(quakegunner)
which should predictably be equivalent to:
sally.quakegunner:arms = 3
The quakegunner context would be on top of the context stack
so all definitions would be sought there. If you need to, you
can use "sally.human:arms" to be specific. Just so thinigs
don't get too confusing, the rule would be that the context
stack is completely cleared when you change scope, so it's
always fresh when you get to a new block.
This could have powerful (possibly dangerous) consequences though,
since you could take a chunk of code that sally.arms and wrap it.
Unlike your "replacement" and "interception" concepts which deal
with changing code on the inside of some tags, this context switching
would be changing things on the outside of some tags. There is the
potential for very powerful template-like reuse with this technique
at the cost of someone coming along an redefining quakegunner:arms
on you. If you clear the context stack as I suggest, this might make
it safer so that you know you're not inheriting any weird name
spaces with you. I imagine that passing name spaces to methods would
be very handy too.
I don't know, what do you think? Is this flexibility more a benefit
or a hazard?
> <appendage:arms> doesn't need to be unique throughout the entire program
> state; if <arms> is unique *within* class <human>, it's enough.
That could be an annoying limitation though where you have collisions
like "arms". I guess another way to solve this might be the following
(inspired by eiffel, which if I recall correctly, allows you to redefine
terms during inheritance, ie. two parents have arms defined, so redefine
one as "qarms"):
<human>
<redefine qarms=quakegunner:arms/>
# ...
</human>
sally.quarms.append(bfg())
Or just do it on the fly and don't affect <human> at all:
qarms = quakegunner:arms
sally.quarms.append(bfg())
which is not *that* inconvenient and should be optimized out by a
compiler anyway. You might even want to do both the push/popcontext
thing and this syntactic sugar thing.
In the text-based environment I envision, as you type in FlareSpeak,
you can watch the actual Flare code update at the same time. So you'd
never be surprised either way.
Is this getting too complicated? It's only two modifications to
alleviate the one thing that gives me pause about the temp Flare
spec...
-- Durant Schoon
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:36 MDT