[plt-scheme] v4 questions

On Mar 30, Mark Engelberg wrote:
> 3. I read about Clojure on a few Scheme blogs, and read through the
> docs the other day.  I really liked the use of extensible, immutable
> vectors and hashtables, and how they respond to the same
> cons/first/rest functions used for lists.  [...]

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).


> 4. I noticed that the built-in list functions and string functions
> are a tiny bit beefier than v372, but still fall short from the more
> complete SRFI implementations.  I hope that it will be extremely
> easy to bring in the missing functions without conflict.  In v372
> it's a bit awkward to get a full suite of string and list functions
> because of conflicts.

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.


> 5. OK, this has been bugging me for a while... why is the "member"
> function not "member?".  It's a predicate, right?

No, try it.


> 6. It would be nice if assoc and its kin could take an optional
> default lookup value, like hash-table-get.

`assoc' doesn't behave like `hash-table-get' -- it returns the
container instead of the value.

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