[plt-scheme] v4 questions

On Sun, Mar 30, 2008 at 2:04 PM, Eli Barzilay <eli at barzilay.org> wrote:
>  I don't know what that means -- pure functional types like hash tables
>  are really hard, and offer little advantage over the impure ones if
>  you have them (at least IME).  And if you talk about vectors, then
>  things get even stickier (are you talking about a real vector, or
>  about something that behaves like one?).  There are many choices and I
>  don't think that there is one that clearly sticks out.  Especially if
>  you want cons/first/rest for these things (and I don't even know how
>  would you define them for vectors and hash tables).
>

I'm not talking about a true vector, just something that has improved
performance for random-access and deque operations.  The usual
arguments about the benefits of immutability apply: better ease of
testing, better easy of analyzing correctness of code, better thread
safety.  But most importantly to me, the style of writing the code
would then be consistent with list-based code.

I frequently find myself in the following situation:
I've written a lot of code that relies on lists.  At some point, I
realize that I need to do an operation that is very slow on lists.
Now, I've got a problem.  Converting over to something like a vector
requires massive changes, not only to the syntax, but to the structure
of my program.

In my ideal programming world, up at the top of a given module, I
could specify what I want my default data structure to be, e.g.,
#lang scheme
#list basic-list

Then, when I'm done with my module, I can easily test and time the
code using various data structures that make different tradeoffs:
#lang scheme
#list Hinze-Patterson-finger-tree

This would automatically convert my cons and list constructors and the
reader for lists, so that they would create the data structure that is
defined in the module to be the default.  Presumably the other
functions, such as first, rest, map, fold, comprehensions, pattern
matching, etc., would be polymorphic and work properly on all the
datatypes that could legally be substituted for lists.  Basically, I
want a super-simple way to parameterize my code over the fundamental
data structures it uses.

This is my ideal, but maybe this kind of polymorphism is a bit
far-fetched in the context of the Scheme way of doing things.

So, I'd settle for a set of data structures that use a consistent
naming scheme, so at least it's not too painful to do a
search-and-replace.  Maybe to switch all my lists over to finger
trees, I could replace cons with ft-cons, and first with ft-first,
etc.

But right now, it's way too difficult to explore the effects of
changing data structures on a given program.

>  More stuff will be added to scheme/list, which serves the same purpose
>  as mzlib/list in 372.  (This is in contrast to scheme/private/list,
>  which is part of scheme/base, and is considered more of a "built-in".)
>  But it is not going to get as big as srfi-1 is.  (If there is specific
>  srfi-1 functionality that you're missing and can argue for, then now
>  is a good time to do so.)  Also, the provided functionality will still
>  collide with srfi-1, since there are things that behave differently --
>  one of the major incompatibilities is that srfi-1's idea of mapping
>  terminates with the shortest list, and the plt operations require them
>  all to have the same length.

Is there a list of the planned list library additions somewhere?

--Mark