Re: [racket-users] Prefix-in for macros

2016-01-22 Thread Anthony Carrico
Expand into a (sub)module? -- Anthony Carrico -- 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, visi

Re: [racket-users] Prefix-in for macros

2016-01-22 Thread Alex Knauth
> On Jan 22, 2016, at 9:07 AM, brendan wrote: > > I was playing around with parser-tools, which has a convenient syntax in > which the elements of a grammar rule are bound in order to $1, $2, etc. This > led me to think about how the composability of non-hygienic macros could be > limited by

Re: [racket-users] Places performance & channel capacity

2016-01-22 Thread Tim Brown
Brian, I may be jumping in with both feet here; but this is the pattern I’ve found works for me. I don’t know if you’ve got all of your workers being fed from a single input place-channel. 1. create a (response-channel-send response-channel-recv) with make-place-channel 2. create a (request-ch

Re: [racket-users] Places performance & channel capacity

2016-01-22 Thread Gustavo Massaccesi
>In hindsight, I guess that's not too surprising since the majority of work is copying byte from >one place to another anyway (soundex isn't that slow), so if the parallel version has to copy >the line twice when the work is ~ copying the line once, it's going to be expensive getting >the data into

[racket-users] Prefix-in for macros

2016-01-22 Thread brendan
I was playing around with parser-tools, which has a convenient syntax in which the elements of a grammar rule are bound in order to $1, $2, etc. This led me to think about how the composability of non-hygienic macros could be limited by name-collisions - not very likely in this case, but easier