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
> 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
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
>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
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
5 matches
Mail list logo