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
