[plt-scheme] v4 questions

From: Eli Barzilay (eli at barzilay.org)
Date: Sun Mar 30 17:18:27 EDT 2008

On Mar 30, Mark Engelberg wrote:
> On Sun, Mar 30, 2008 at 10:16 AM, Doug Orleans <dougorleans at gmail.com> wrote:
> > Mark Engelberg writes:
> >   > I've been looking through the preview reference:
> >   > http://pre.plt-scheme.org/docs/html/reference/index.html for v4.0, and
> >   > have a few comments/questions.
> >   >
> >   > 1. Why no streams?  Wouldn't it be nice to have a solid stream
> >   > implementation with namings that are consistent with the PLTScheme
> >   > list functions, and integrated into the comprehension syntax, i.e.,
> >   > for/stream ?  Please consider this...
> >
> >  I kind of agree, but this would also be pretty simple to do as a
> >  PLaneT package.  Here's a start:
> >
> >   (require srfi/40)
> >   (require scheme/control)
> 
> The problem with using srfi/40 streams is that it doesn't use a
> naming scheme that corresponds to PLT Scheme's integrated list
> functions.  For example, stream-empty, stream-first, stream-rest,
> etc.  Many functions would need to have changed names; many would
> need to be added.

That's all unavoidable -- unless you want a new language module that
has no lists at all.


> What about integration with the pattern matching system?

You can add new patterns to it.


> What about integration with sequence?

If you mean `for' then you can extend it too.


> What about integration with the reader?

Same here.  (But a reader syntax is not too useful since it means that
you could have used plain lists.)


> There end up being a lot of pieces that are probably best done in a
> definitive way by the people who control all the other related
> pieces, if you really want streams to have "first-class" status.  My
> own opinion is that streams are important enough to warrant this
> kind of attention.

My experience is that there are way too many options to have a clear
choice here -- and my personal preference for dealing with it is to
just bite all the way through and go with a lazy language, instead of
the stream half-baked approach.


> There's also a matter of trust.  Right now, Planet is relatively
> small, and it's not too hard to know what's out there.  But over
> time, it gets harder to know which things on there are high quality,
> stable, and reasonably efficient.

(That's unavoidable, and the general plan is to rely *more* on
planet.)


> Now I know that PLT Scheme is run by a small group of people who
> already have too many demands on their time.  But maybe a lot of
> these polishing touches could be handed off to some ambitious
> undergrads.

Even that requires a ton of time, and it requires finding such
people.  Also, writing the code is not even half the trouble, it is
much less.  Documentation is much more important (and usually makes it
clear how you're doing something wrong or how it should be extended),
tests, and the most important aspect is maintenance -- someone will
need to be responsible for that code for years.

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


Posted on the users mailing list.