Re: [racket-users] cannot produce units from syntax transformers

[Nota Poin]

On Saturday, November 28, 2015 at 11:24:28 PM UTC, Matthew Flatt wrote:
> That is, `import` is a binding form, just like `let`. 
Oh, that makes sense. So it gets swapped in the macro for a hygenic named 
variable, and the ones I pass by that name don't get swapped in the same 
fashion, thus aren't bound.

Maybe I'll try your non-hygenic thing. I could also just 

(define-syntax-rule (asyn imp^ body ...)
  (unit
(import imp^)
(export)
body ...))

...or something. 

Probably not be very useful, since you might as well use the unit syntax if 
you're going to be specifying imports and exports with every invocation. I like 
your non-hygenic solution better. Which is to say I don't like it, but heck if 
I know a better way to make things that create a unit of one single specific 
signature.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] cannot produce units from syntax transformers

[Matthew Flatt]

Your example is similar to

 (define-syntax-rule (with-x body)
   (let ([x 5])
 body))

 (with-x x) ; => unbound identifier

That is, `import` is a binding form, just like `let`. Bindings
introduced by a hygienic macro do not capture identifiers at the
macro-use site.

If you want non-hygienic binding, here's one way:

 (require (for-syntax racket/base
  syntax/parse))

 (define-syntax (asyn stx)
   (syntax-parse stx
 [(_ body ...)
  (with-syntax ([foo^ (datum->syntax stx 'foo^)]
[bar^ (datum->syntax stx 'bar^)])
#'(unit
(import foo^)
(export bar^)
body ...))]))

Non-hygienic macros have various issues, such as not composing nicely,
but if that's what you want, hopefully the above example helps you onto
the right path.

At Sat, 28 Nov 2015 13:56:31 -0800 (PST), Nota Poin wrote:
> I'm not sure why, but this works:
> 
> (unit
>   (import foo^)
>   (export bar^)
>   (+ foo bar)))
> 
> while this fails:
> 
> (define-syntax-rule (asyn body ...)
>   (unit
> (import foo^)
> (export bar^)
> body ...))
> 
> (asyn (+ foo bar))
> 
> with the error "unit: undefined export" for any imported variables.
> 
> Somehow the (unit...) form is tied to the physical source location that it's 
> written in, so if a syntax transformer tries to introduce a unit syntax, when 
> the new syntax is used, the unit will consider the body spliced into it to be 
> outside of it, since the body has a different source location than the actual 
> definition of the syntax transformer itself.
> 
> Is there any way to work around this? I don't necessarily want to rely on 
> units, so I made a general syntax that would let me swap them out according 
> to 
> my specific use of them, like (with-that-stuff etc ...) instead of (unit 
> (import that-stuff^) (export) etc ...). But that doesn't work, because for no 
> reason I can fathom, the etc... part gets evaluated before it gets spliced 
> in, 
> even though define-syntax says it gets spliced in before evaluation.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.