[plt-scheme] syntax form works in top-level env, but not when imported from module.

On Nov 14, 2005, at 1:53 AM, Hans Oesterholt wrote:

> I figured that out, but why the different behaviour?
> I first tried this with a plain 'if' statement, and it
> got evaluated as well. Why? Shouldn't it be so that
> only the condition of an if statement must be evaluated
> and the code of the part to be executed that it implies?
>
> So
>
> (if ('like eq 'like) ('like) (* like like))
>
> shouldn't that be possible?

I assume you agree that this is not a question of syntax. You can get 
the same result with plain variables.

The question is why module and top-level treat variables differently. 
The top-level is a 'thing' that has evolved over the past five decades. 
It is pragmatic from the perspective of very good hackers and very bad 
ones. Pile on code after code after code and somehow the resulting 
'program' will work. Since you may not care about a particular variable 
now, leave it free. (Historically the free variable part came about 
because it's easy to get mutual recursion that way.) As long as it is 
not now evaluated (inside of a thunk, if-branch, etc) your program will 
work, mostly.

The module part is a 'compilation unit' and thus a 'unit of good code'. 
You can compile it and determine its meaning without anything else. 
Since free variables don't have any meaning, we check for them and 
raise an error when we see one. This forces the programmer to provide 
some meaning for a variable, e.g. (define (like x) (error 'f "undefined 
variable")) [This is intentionally stupid]. Later it is replaced with 
something better but there is always a definition.

-- Matthias




>
> Matthias Felleisen schreef:
>
>>
>> On Nov 13, 2005, at 6:14 PM, Hans Oesterholt wrote:
>>
>>> (a like)
>>
>>
>> expands into (a.is-op? 'like (lambda () (* like like))) and then is 
>> checked for close-ness. Since like is not defined, the module isn't 
>> well-formed.
>>
>> At the top-level, (a like) expands into the same code. But since 
>> module isn't there, the code isn't checked for well-formedness. So an 
>> unbound id is okay as long as you don't evaluate it.
>>
>> -- Matthias
>>
>