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 things, but most of them were supposed to go all the way > down to primitive methods (in some sense) if all else failed. > > 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?
I like the primitive / derived distinction, but I don't think that the distinction should be done based on the presence of fallback implementations. IMO, it makes more sense to interpret it like Stephen did: what do I need to write to get a "minimum viable set type" and get the rest for free. Presence or absence of fallbacks is just an implementation detail. If we take that view, then "basic" (or something) may make more sense than "primitive", though. 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 the derived for free, right? Vincent _________________________ Racket Developers list: http://lists.racket-lang.org/dev