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
> <ro...@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!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
