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 necessa
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 a
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
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 t
> 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
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang 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 the primitive
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 int
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 s
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, s
On Fri, Aug 2, 2013 at 1:25 PM, Matthew Flatt 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 (plane
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 alwa
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 e
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
14 matches
Mail list logo
