[From nobody Tue Jan 17 23:16:31 2012
Message-ID: <4378F8A1.9050809@gawab.com>
Date: Mon, 14 Nov 2005 21:50:41 +0100
From: Hans Oesterholt <hdnews@gawab.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: nl-NL, nl, en
MIME-Version: 1.0
To: Matthias Felleisen <matthias@ccs.neu.edu>
Subject: Re: [plt-scheme] syntax form works in top-level env, but not when
	imported from module.
References: <4377C8BA.6090006@gawab.com>
	<55c011b9d3372a80aadb3cd28b7b41f0@ccs.neu.edu>
	<43783475.5000403@gawab.com>
	<8ff77f4c28123712f074e3fe30911f78@ccs.neu.edu>
	<4378ADB1.5040604@gawab.com>
	<aca4c2bcba44217dd8736321d2fa3007@ccs.neu.edu>
In-Reply-To: <aca4c2bcba44217dd8736321d2fa3007@ccs.neu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hmm, I don' know. Here's the code I'm using:

(...)

(define-syntax pexpr-basic-op
  (syntax-rules ()
    ((_ op)
     (if (or
      (eq? 'op '=)
      (eq? 'op '<)
      (eq? 'op '>)
      (eq? 'op '<=)
      (eq? 'op '>=)
      (eq? 'op 'like))
     (lambda () 'op)
     (lambda () op)))))

(define-syntax pexpr-op
  (syntax-rules ()
    ((_ op)
     (if (or
      (eq? 'op 'or)
      (eq? 'op 'and)
      (eq? 'op 'not))
     (lambda () 'op)
     (lambda () op)))))

(define-syntax pexpr-all-op
  (syntax-rules ()
    ((_ op)
     (if (eq? 'op 'all)
     (lambda () 'op)
     (lambda () op)))))

(define-syntax pexpr 
  (syntax-rules ()
    ((_ (op (objclass class attribute) value))
     (list ((pexpr-basic-op op)) (list objclass class attribute) 
(oodb-ci-marshall value)))
    ((_ (op (objclass attribute) value))
     (list ((pexpr-basic-op op)) (list objclass '* attribute) 
(oodb-ci-marshall value)))
    ((_ (op (objclass)))
     (list ((pexpr-all-op op)) (list objclass)))
    ((_ (op e1 ...))
     (list ((pexpr-op op)) (pexpr e1) ...))
    ((_ e)
     e)))

;;;
(define (psearch-intern expression)
  (map
   (lambda (oid-objcl)
     (let ((oid (car oid-objcl))
       (oc  (cadr oid-objcl)))
       ((proos-class oc) 'from-oid oid)))
   (oodb-ci-search expression)))
      
(define-syntax psearch
  (syntax-rules ()
    ((_ expression)
     (psearch-intern (pexpr expression)))))
                    ; Making a search expression

(define-syntax psearch-exp
  (syntax-rules ()
    ((_ expression)
     (pexpr expression))))


As you can see. "all" and "like" are free variables.

Best whishes,

Hans

   
Matthias Felleisen schreef:

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


]