Hi,
Commit e51ac9cc [1] from about a month ago changed the allowed values for
local-transformer-expands context-v argument. It now refuses 'module and
'module-begin. Previously i could simply pass the result from
syntax-local-context.
I am not sure what i should pass now and what
So `--link' could be the default, while `--copy' (?) could disable
special handling of directory sources?
That sounds fine. I mean, I am unlikely to ever use --copy, but whatever
makes sense to expose in terms of the underlying model.
It could be useful if the directory is on a remote
I removed those options because the implementation did not look
sensible for those cases.
Implementation aside, using 'module-begin doesn't make sense to me. A
form in the place of `#%module-begin' is always expanded at phase-level
0, so there isn't really.
I'm less certain about 'module. It may
Here is a strip down example of a case that worked before and gave an
error with the new version.
I was only interested in the information if the argument to mac could be
expanded to something bound or not. So the quick solution here was to wrap
the provide in begin and expand it in
Just played a bit with gen:set. It looks great and in particular the
fallback implementations are very convenient.
One comment: the distinction between primitive methods and derived
methods confused me somewhat. Can you explain the reasoning for
determining which is which?
For example, when I
Hmm. Well, partially, I wasn't sure how to document the methods, because
the relationships are complex, and because we don't have existing
terminology or documentation patterns for this. I'm open to other
suggestions, and especially (though not exclusively) to patches. For the
other part, I
For the other part, I either should have made it as you say -- implement the
primitive ones and you get the others -- or else I should have clearly
documented the relationship somewhere.
You did document the dependencies, but some of them are circular, ie
some derived rely on other derived.
Ah, yes, set-stream isn't primitive because it can be derived if you have
set-first and either set-rest or set-remove. And I know there are
dependency cycles, this is intentional so that you can implement any one of
several related things, but most of them were supposed to go all the way
down to
Would it be better to just remove the primitve / derived distinction,
since it's somewhat artificial, and leave it up to the individual method
descriptions? Is there some better way I should be describing things?
Ok I can see now that there's no easy way to organize the methods.
I think we
No, that doesn't work. If someone implements, say, an efficient subset?
test, then set=? should use that rather than iterating using set-stream
and set-member?. You should use the highest-level methods you can, in
order to get the most out of an implementation. Which is why I made all
the
I'm running HEAD = c126a8a from about 1 week ago.
I wanted to try the PEG Planet 1 package.
My source file was simply this:
#lang racket
(require (planet kazzmir/peg:2:0/peg))
1. Using command-line Racket, I got:
Welcome to Racket v5.90.0.3.
; uncaught exception:
p.s. The About text from DrRacket is:
Welcome to DrRacket, version 5.90.0.3--2013-07-30(c126a8aa/d), english by PLT.
Just to confirm I ran the DrRacket built from HEAD = c126a8a, not an
older version by accident.
On Thu, Aug 1, 2013 at 9:55 PM, Greg Hendershott
greghendersh...@gmail.com wrote:
12 matches
Mail list logo
