[plt-scheme] v4 questions

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.  What about integration with the pattern matching system?  What
about integration with sequence?  What about integration with the
reader?  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.

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.

Planet's a good way to distribute experimental or niche libraries.
But as someone who comes from a Python "batteries included"
background, I can say that there's really no substitute for having a
very rich set of built-in functionality.  I know a lot of people love
Scheme's minimalistic philosophy, but I want to be able to (require
"scheme/ultra-big") and get a rich, souped up version of Scheme with
trusted support for all the things that are the norm among mainstream
languages (both imperative and functional).  Give me a rich set of
data structures, both destructive, and state-of-the-art functional,
and make sure the data structures are written in a way that is
consistent with PLT Scheme (as opposed to being written with
portability to other Schemes in mind).  Give me fully-featured
libraries for strings and reg expressions.  Give me optional laziness.
 I'm pleased to see that the new version makes it easier to use things
like optional parameters, keyword parameters, pattern matching,
comprehensions, and looping constructs.  The OO portion of PLT Scheme
is rich and easily available, for those who need it.  This is all
fantastic.  PLT Scheme is very close to being the kind of system I'd
want to use for my everyday programming needs (no insult intended, but
at this time I'm still primarily using it as an educational tool, and
turning to other languages like Python for my day-to-day programming
needs).

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.  I
think going out and finding good srfi and/or planet implementations,
and renaming and enhancing things for consistency with the rest of PLT
Scheme would cover a lot.  Many data structures that are  "missing"
from Scheme are fairly well documented in other places, and would be
good exercises.  But I think there would be tremendous value to having
these additional libraries looked over and given an official "stamp of
approval" for inclusion in the PLT Scheme distribution.

>   > 6. It would be nice if assoc and its kin could take an optional
>   > default lookup value, like hash-table-get.
>
>  Unlike hash-table-get, assoc returns the whole association, i.e. the
>  key/value pair, instead of just the value.  What you want is alist-get:
>
>   (define (alist-get alist key (default #f))
>     (let ((pair (assoc key alist)))
>       (if pair (cdr pair) default)))

Does this function already exist in the libraries, and is it
documented anywhere, or are you just proposing it?  Seems like if
there are a bunch of "alist-" functions, maybe assoc should have a
synonym of "alist-get/key-value" or something like that?

--Mark