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

Matthias Felleisen wrote:

OK, I follow.

But is there a way around it? What I like to do
is conditionally expand to a variable or a symbol.
And can I put that in a module?

Thanks in advance,

Hans



>
> 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
>>>
>>
>