Re: Fw: Macro Question

Hello, Bent,
My concern is with the situation where the symbol used for the field name clashes with a binding in a macro. The intention of the first symbol in the pairs passed to the family of instantiate macros is intended to be the name of the field not a binding, and hence, in my mind, should not be replaced by macro expansion. That is why I suggested it may make more sense to use keywords; they would not be eligible for replacement during macro expansion.
Does that make sense?
Thank You,Joe


 
      From: Bent Phillipsen <[email protected]>
 To: Joseph Donaldson <[email protected]> 
 Sent: Monday, January 23, 2017 12:06 PM
 Subject: Re: [bigloo] Fw: Macro Question
   
 Hi Joe, As I am ondistribution list, here is my point of view:I don't think youshould fear colliding bindings in the macros using the instantiatemacro. This is just what the hygienic macro system is about: identify bindings in the macro definition and replace those nameswith generated names as well as looking up free variables in thescope of the macro definition.I am not exactlysure if you refer to the auxiliary macro “identity” in theexample I gave, when you write “and they can be rewritten by othermacros”. I am also not sure what you were trying to do with theexample you gave – I think it was some sort of information hiding.If you don't like the auxiliary macro you could make your objectcreating macro along the lines of the following:
(module insta-macro
        (static (class foo a::long b::long))
                (main start))


(define-syntax darn
        (syntax-rules (a b)
                ((_  )  (darn a 1 b 1))
                ((_ va vb) (darn a va b vb))
                ((_ a va b vb) (let ((va-evaluated va)
                                     (vb-evaluated vb))
                                        (instantiate::foo (a va-evaluated) (b vb-evaluated))))))

(define (start argv)
        (define obj1 (darn))  ; create an object with default values
        (define obj2 (darn (* 2 1) (* 2 4)))  ; create an object initialized with evaluated expressions
        (define obj3 (darn 11 22))
        (define obj4 (darn a 3 b 4))  ; create an object giving the field names 
        ;(define obj5 (darn a 4 c 9)) ; OK, this will not compile, no field c
        ;(define obj6 (darn b 5 a 5)) ; OK this will not compile, a and b must be given in right order  
        (with-access::foo obj1 (a b)
                (print "obj1 a=" a " b=" b))
        (with-access::foo obj2 (a b)
                (print "obj2 a=" a " b=" b))
        (with-access::foo obj3 (a b)
                (print "obj3 a=" a " b=" b))
        (with-access::foo obj4 (a b)
                (print "obj4 a=" a " b=" b)))
Using literal (or  "macro keywords") a b appears to be a good idea here, as it prevents (darn b 9 a 1). Without literals this would compile and assign 9 to a and 1 to b. Probably not what was intended.
Something along this line should in myopinion be safe and never give collisions – or am I overlookingsomething?Best regardsBent


2017-01-22 20:11 GMT+01:00 Joseph Donaldson <[email protected]>:

Hello, 

I can see why the behavior is occurring, but it seems that, since we are using symbols for the field specifiers in the instantiate macro and they can be rewritten by other macros introducing possibly colliding bindings, it makes uses of the instantiate macros in other macros very fragile. Am I a missing something? Would it make since to use keywords for the field names instead?
Thank You,Joe

 
      From: "[email protected]" <[email protected]>
 To: Bent Phillipsen <[email protected]> 
Cc: [email protected]; [email protected]
 Sent: Monday, January 16, 2017 5:19 AM
 Subject: Re: [bigloo] Fw: Macro Question
  
Hi Bent,

> IMO this is expected behavior - but doesn't work, as the variable in let
> will be generated:
I have missed the point you are raising in my previous answer. I think you
are right.

-- 
Manuel