Re: Recursive Macros generating Definitions

[Frank Terbeck]

Hey Maxime!

Maxime Devos wrote:
> On 03-10-2022 13:32, Frank Terbeck wrote:
>> When looking at  this, I also saw the following,  which might be related
>> if ‘syntax-rules’ is implemented using  ‘syntax-case’
>
> It is, IIRC.
>
>> (I didn't check if
>> this is the case):
>>      (define-syntax-rule (foobar n) (define quux n))
>>      ,exp (foobar 23)
>>    → (define quux-ea7bdcf8675f4a4 23)
>
> This is correct (as in, functioning as intended and not a bug) to my
> understanding -- in the match expression of 'foobar', 'quux' does not appear,
> so the for hygiene, the 'quux' inside shouldn't be the quux outside.
[…]
> It's sometimes a bit inconvenient -- sometimes you _want_ to define 'quux' 
> (and
> not just only available to the macro), but that's easily resolved by adding an
> additional 'quux' argument to 'foobar':
>
>       (define-syntax-rule (foobar quux n) (define quux n))
>       ,exp (foobar quux 23)

I get the point, but I think it's sort of surprising, when everything in
the macro-language is  otherwise quite literal, to  my understanding. It
may be warranted to  point this out in the documentation  that this is a
side effect of hygienic macros, I think.


>> (define-syntax generate-shorthands [...]
>
> Your recursive macro is, well, recursive.  This is fine, but IIUC a 
> consequence
> of this is that the recursive 'call' to generate-shorthands is a new lexical
> lexical environment (hence, hygience, so -?????? stuff).
>
> As such, I consider this not a bug in Guile, but a bug in your code.
>
> My proposal would be to change the 'x' in (datum->syntax x) -- instead of 
> using
> #'x (which refers to the whole expression, which in a recursive call has an
> undesired lexical environment), use something of the 'end-user' of
> generate-shorthands, say, #'s (i.e., SEMANTICS-SYMBOL) (for the right lexical
> environment).
>
> If I make that change, I get some reasonable output (no -????? suffixes):
>
> $1 = (begin
>   (define (varint:sint32-decode bv)
>     (varint-decode bv 32 zig-zag))
>   (define (varint:sint32-encode n)
>     (varint-encode n 32 zig-zag)))

Thanks, this does work indeed!

So,   clearly  I   don't  fully   understand  the   first  argument   to
‘datum->syntax’, because  I thought ‘x’  would be exactly right  since I
thought it  captured the context  of where the  macro was called  in the
original  code.  But  every  time,  I  perform  an  indirection  through
recursion, the context captured by ‘x’ is bound to something new, that's
in the context of the outer level of macro expansion.

If I understand this correctly, using #'s here, refers to something that
was created  at the source level  of where the initial  expansion of the
macro happened.  If that  is the  case, is it  correct, that  it doesn't
really matter whether I used #'s or #'w. And that seems to be the case.

And if I wanted to do this:

  ((op s w)
   (let ((base (make-base-name #'s #'w)))
     (with-syntax ((enc (datum->syntax #'op (symbol-append base '-encode)))
                   (dec (datum->syntax #'op (symbol-append base '-decode))))
       #'(begin (define (dec bv) (varint-decode bv w s))
                (define (enc  n) (varint-encode  n w s))))))

…I'd still  end up with  the -HEX amended  symbol names, because  in the
recursing cases, I am using  a literal ‘generate-shorthands’ symbol. But
if I'd do this:

  ((op (sems ...) (widths ...)) #'(begin (op sems (widths ...)) ...))
  ((op sem        (widths ...)) #'(begin (op sem widths) ...))

It should work, because ‘op’ always  refers to the syntactic object used
at the source level, where the user  used the macro, which means that in
the base-case, the  ‘op’ template variable still refers  to the original
source position,  so the scopes match  up correctly, so that  the intro-
duced bindings don't have to be amended for hygiene.

In hindsight, I should have sent this to -users after all. :)

This behaviour  is probably  explained in one  of the  ‘syntax-case’ and
‘datum->syntax’ examples  in the manual,  but it  wasn't clear to  me at
all. Not sure how, but I think there's room for improvement here. :)

Thanks for  clearing this up!  And feel free  to correct anything  I got
wrong in what I wrote in the above.


Regards, Frank