vincenz is right : Lua deals with vectors this way. Actually, it doesn't even bother to ask you whether you are using it as a vector or as a hash table. Each table is implemented as both a vector (for numeric keys) and a regular hash table (for other keys).
This way, you've got performance (and lua is one of the fastest "scripting" languages) with a really minimal language.
I think that would be a good approach for Arc too : don't bother with vectors, hash tables are enough :)
I wanted to do the same thing in Lua, but I finally thought it was too much work... Since it can be done with Javascript, I guess I'll finally give it a try... You know, just to understand better how it does work...
Very good app. This (and its source code) is the kind of things that makes me sure Arc is really a great language for webapps... How long did it take you to make it ?
Seconded. Reading the source code is a lot of fun. It's well organized and really makes the case for Arc's approach to HTML. I know I'm a convert; having stuff in so many separate files, MVC style, feels like sludge compared to this. Even if you do have to start breaking things into separate files as the app gets more complex, being able to start out like this is a serious gain.
This is a big one but a simple solution is possible in a first time. Since Arc is mainly for web apps, why not at least convert non-ascii characters into their url-encoding equivalents ? Arc is already converting those characters, but in a broken way : EUR instead of the euro symbol, for exemple.
Modules would be great, too. Well, nothing new here, anyway.
Equal? recursively compares the contents of pairs, vectors, and strings, applying eqv? on other objects such as numbers and symbols. A rule of thumb is that objects are generally equal? if they print the same. Equal? may fail to terminate if its arguments are circular data structures.
There is a silver lining though. In R6RS the following was added:
Note: The equal? procedure must always terminate, even if its arguments contain cycles.
That is, there is a good chance that the behaviour of equal? changes, when the PLT Scheme team begins implementing the R6RS language.
I submitted a bug report to PLT Scheme about that. Here's their answer :
"The process for generating an `equal?' hash key is defined to not
terminate on circular objects, such as a hash table that contains
itself. So `(hash-table-get <any-table> t)' loops trying to generate a
key for `t'.
The specification of hashing has changed for the next release to deal
gracefully with cyclic data, just as `equal?' has changed so that it
can compare cyclic data. In the current pre-release version,
v3.99.0.10, your example returns immediately.
(It returns with a "key not found" error. That's because the process of installing a hash table into itself changes the table's own `equal?'
hash key.)"