[racket-dev] new release policy

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Fri Aug 13 09:37:35 EDT 2010

And, on the other side of the coin, I'm sure Jay is willing to
entertain alternative proposals, esp. if they come with


On Fri, Aug 13, 2010 at 8:20 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> Thanks for debugging me Noel.
> 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.
> Jay
> On Fri, Aug 13, 2010 at 3:55 AM, Noel Welsh <noelwelsh at gmail.com> wrote:
>> On Fri, Aug 13, 2010 at 2:45 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
>>> I parse your comments like this:
>>> - We can't do these sequence functions fast.
>>> - When we didn't provide them, people complained that they were missing.
>>> - When we provide them slowly, people will complain that Racket is slow.
>>> - It is worse to be slow than featureless.
>> 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)
>> N.
> --
> Jay McCarthy <jay at cs.byu.edu>
> Assistant Professor / Brigham Young University
> http://teammccarthy.org/jay
> "The glory of God is Intelligence" - D&C 93
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev

Posted on the dev mailing list.