[racket-dev] new release policy

On Aug 13, Noel Welsh wrote:
> 
> I think this is incorrect. I read:
> 
> - When we provide APIs we lock ourselves into them
> - The proposed sequence API is slow and can't be sped up without
>   significant effort (cf worldwide shortage of Matthew-Flatt-hours)
> - We shouldn't lock ourselves into a slow API without considering
>   alternatives (cf performance of stream/lazy list abstraction)

Yes to all of that, with an addition that IMO some 2x slower feature
is mostly something to improve, a 100x slowdown makes it a bug.


On Aug 13, Jay McCarthy wrote:
> Since the API I added merely promises some sequence, there's nothing
> preventing us from having it always return a future lazy stream that
> can be viewed as a sequence if that ends up being faster. If someday
> we have such nice lazy streams, then I predict we'll certainly want
> similar functions and we'll have another request for making the
> sequence api more like the lazy stream api.

Obviously -- but getting there involves more work now.  (And until we
get there we have that buggy (IMO) code.)


On Aug 13, Jay McCarthy wrote:
> On Fri, Aug 13, 2010 at 7:37 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
> > And, on the other side of the coin, I'm sure Jay is willing to
> > entertain alternative proposals, esp. if they come with
> > implementations.
> 
> Even if they don't actually :)

I *did* make an alternative proposal (that didn't come with an
implementation).  And in fact that blog post was explicit about it
too.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!