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

On Nov 14, 2005, at 10:30 AM, Hans Oesterholt-Dijkema wrote:

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

Would this help?

(module a mzscheme

   (provide a)

   (define default 10)

   (define-syntax a
     (syntax-rules (like)
       [(_ likes x) (+ x default)]
       [(_ x y) (+ x y)]))
   )

(module b mzscheme

   (require a)

   (printf "~s~n" (= (a likes 20) 30))
   (printf "~s~n" (= (a 10 20) 30)))

(require b)

-- Matthias


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