[racket-dev] new release policy

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

Robby

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
>