This whole discussion reminds me of the idea of specialization interface
specification. The notion is due to Lamping, I think. Stevie and I read the
paper and his class contracts provide some of the power of SIs but not all. In
particular, they fail to provide the power that seems to be
I think you just ran into all of the problems with planet1 at the same
time. I started with kazzmir/peg and browsed sources, and as far as I
can tell, all of the packages you got are actually transitively required
by kazzmir/peg. So it's not a PLaneT implementation bug.
It looks like there's
At Thu, 1 Aug 2013 21:55:37 -0400, Greg Hendershott wrote:
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:
At Thu, 1 Aug 2013 18:56:08 -0400,
Carl Eastlund wrote:
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
With that in mind, I think it would make sense to move `set-first' and
`set-empty?' to the primitive set (making it clear that they are
optional, and can be derived from `set-stream' if need be). With those
two in the primitive set, anything that implements all the primitives
should get all
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote:
With that in mind, I think it would make sense to move `set-first' and
`set-empty?' to the primitive set (making it clear that they are
optional, and can be derived from `set-stream' if need be). With those
two in
Actually, I am realizing that every derived method depends on
set-stream, even the ones that don't document it (ie set-union,
set-union!, set-intersect, set-intersect!, etc), since they use
in-set.
I was in the process of creating a patch for the docs to add the
missing dependencies but I ran
Yes, this is an issue. I kind of vaguely hint at it in the documentation,
and didn't get around to making it an explicit point -- I use the phrase
implements for things that have to be directly implemented, and
supports for sort of transitive implements. I use in-set and things
like it in some
Ah. I was primed with the mental set:
(a) I got some error messages I'd never before seen when requiring a
Planet package.
(b) I guessed all the recent reorganization broke something with
Planet 1 packages.
(c) Although I was aware peg required memoize, I didn't look into
memoize's source, so I
On Fri, Aug 2, 2013 at 1:25 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Thu, 1 Aug 2013 21:55:37 -0400, Greg Hendershott wrote:
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
p.s. Anyway I do realize now there wasn't a bug per se. It sounds like
I've been so lucky with Planet requires in the past, that when (as
Ryan put it) I suddenly hit all the weak points at once, it caught me
off guard. To the extent there's even a usability issue, it's
already being addressed by
Hi all,
I'm currently trying to implement contracts for synchronizable events.
During that, I've discovered that there seems to be an undocumented
restriction that `chaperone-evt` can only chaperone an event that is not
a handle event. Here's an example:
- (sync (chaperone-evt (handle-evt
On 2013-08-02 18:32:38 -0400, Asumu Takikawa wrote:
I'm currently trying to implement contracts for synchronizable events.
During that, I've discovered that there seems to be an undocumented
restriction that `chaperone-evt` can only chaperone an event that is not
a handle event. Here's an
At Fri, 2 Aug 2013 18:32:38 -0400, Asumu Takikawa wrote:
I'm currently trying to implement contracts for synchronizable events.
During that, I've discovered that there seems to be an undocumented
restriction that `chaperone-evt` can only chaperone an event that is not
a handle event. Here's an
14 matches
Mail list logo
