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.mccar...@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 <noelwe...@gmail.com> wrote: >> On Fri, Aug 13, 2010 at 2:45 AM, Jay McCarthy <jay.mccar...@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 <j...@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 > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
