Re: Fw: Macro Question

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