I would venture a guess that it's less about lists vs vectors than
bout lists and vectors versus two other things: "associations" and
"sequences".
-----
Associations:
In many other scripting languages, the distinction between an object,
an association list, a dictionary, and a hash table are all blurred.
Blurring the first of these (objects) with the others is a mistake.
Blurring the other three -- ie, treating everything as a dictionary,
thereby hiding the list representation of an association list, and
leaving it to the run-time system to decide whether or not to
implement things as a hash-table -- strikes me as a win at least for
prototyping.
Even literal-syntactically, hashes work reasonably well:
#hash((a . 5) (b . 7))
is really not much worse than
{a: 5, b: 7}
in the grand scheme of things (and a programmer is always welcome to
implement a reader macro for further convenience).
The lack of an infix syntax for access/set can certainly feel much
more onerous. His vector example is along these lines.
-----
Sequences:
I think one problem when approaching Racket is that, due to the Scheme
legacy, you see an enormous amount of information on lists but not
much else. Some of the data structures like hashes definitely had a
second-class feel them. That is changing with sequences, iterators,
and generators, but:
- The Racket API design seems to value precision (eg, one-valued vs
two-valued) over pure "convenience".
- Sequences still don't feel fully integrated into the language: you
can't pass a sequence where a built-in API might want a list.
- When you read the docs on sequences, hash-tables are listed but sets
aren't. This is because the fine-print talks about *built in* data
structures, which hash-tables are but sets aren't. But it means you
have to remember such stuff.
- The for... forms remind me too much of do. There just don't seem to
be primitives with the simplicity of map/filter/fold for sequences.
Perhaps I'm missing them.
Laziness is a more far-reaching issue. Given that Racket has
generators, perhaps these could be used to build a "lazy" counterpart
to eager sequences: when you know the sequence is finite, and you
intend to visit most or all elements, get a more efficient system by
using the eager versions, otherwise use the lazy ones.
Shriram
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
