[plt-scheme] expansion of internal define v. set!

On Wednesday, November 12, 2003, at 10:56 AM, Joe Marshall wrote:

> Matthias Felleisen <matthias at ccs.neu.edu> writes:
>
>> How do you decide whether (f x) is a definition?  Bunch of options, 
>> all
>> equally unappealing:
>>
>>   (1) You say it doesn't look like one, so skip it.
>>
>>   (2) You say f is define-syntax'ed so it must be expanded, at least
>>       until you know whether it's a definition or not.
>>
>>   (3) You say that f is define-syntax'ed but you also know that
>>      (define (f x) ...)  binds f and therefore shadows everything
>>      following the (define ...). Of course this option presumes that
>>      you understand (a portion of) the binding structure of the 
>> program
>>      before you have finished expanding the whole thing. I.e., lexical
>>      analysis is performed at the same time as parsing, which at least
>>      on the surface sounds horribly wrong.
>
> If macros can expand into macro definitions or binding forms, you have
> to do this anyway.

Yes, the parser must understand syntactic definitions and whether or not
some other form is a value definition.

>
>> I guess that Matthew chose option 2 because define-syntax'es must be
>> recognized during expansion no matter what, unlike lexical scoping.
>
> Lexical scoping has to be recognized as well because the lexical
> bindings may shadow the syntactic ones.

Perhaps that's a problem in the design that people didn't recognize at 
the
time. There is a wide-open design space (just like say the ML module 
design
space) but we have explored this space much less than others (meaning
other spaces and people who face similar problems with equally large
design spaces) and with less of a semantic approach than others (see
above for meaning of "others").

We should explore the alternatives. My hunch is that they are useful,
simpler and cleaner than what we have.

>> In any case, Scheme is not well-defined for this corner (I am cc'ing
>> Will Clinger who is the language lawyer, aka, editor, just in case I
>> am wrong).  It shows one more time how much a full definition
>> matters, and probably how bad internal definitions are.  But I am
>> using them, too, though at other places.
>
> I wouldn't go so far as to say that internal definitions are `bad',
> but if you write macros that expand into internal definitions, then
> you are treading on thin ice.

How do you distinguish local from global definitions? Yes, you're 
bringing
up another design point that I had overlooked: not allowing the internal
definitions context as an evaluation context for macro expansion. But
honestly, I have written two macros over the last six months that did 
just
that. One of them was define/abstract (classes) and the other one was
something similar for modules. Then again, I wouldn't use this in a let
internal context.

Yes, there are many points, and we have explored little.

-- Matthias