Hi Joe, Sorry, I completely misunderstood your question. I thought it was a simple application question.
>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. Can't you avoid this expansion through the use of an identity macro? Best regards Bent ~ 2017-01-24 5:59 GMT+01:00 Joseph Donaldson <[email protected]>: > 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 on distribution list, here is my point of view: > I don't think you should fear colliding bindings in the macros using the > instantiate macro. This is just what the hygienic macro system is about: > identify bindings in the macro definition and replace those names with > generated names as well as looking up free variables in the scope of the > macro definition. > I am not exactly sure if you refer to the auxiliary macro “identity” in > the example I gave, when you write “and they can be rewritten by other > macros”. I am also not sure what you were trying to do with the example you > gave – I think it was some sort of information hiding. If you don't like > the auxiliary macro you could make your object creating 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 my opinion be safe and never give > collisions – or am I overlooking something? > Best regards > Bent > > > > 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 > > > > > >
