Certainly, it may be possible to give this functionality to lists tagged with the type 'alist. But then what would it do when I want to find the zeroth element of an alist where 0 is a key? You could have it just default to one or the other, but then I'd just end up ignoring whichever indexing operation it doesn't default to and using a differently-named function all the time for the other type of indexing in general alist code. In which case, what's the point of overloading the function in the first place?
No contest, my idea is half-baked. I had in mind symbols as keys, where you could define reasonable semantics. I'm still bugged by the lack of symmetry: For any X with which it makes some sense at all, (X ...) seems to work. Constants, hashes, strings, lists... even lambdas ;-)
Obviously the issue is that alists are only a convention.
I don't really care if they compile or not, you can always bring your interpreter with you.
1 I think some sort of C implementation is a must.
2 It would be cool to have arc written in arc - should not be too hard.
3 Paul have you started thinking of a foreign function interface?
This release has 3450 lines of Arc and 1157 lines of Scheme, so it looks like it's mostly On Arc already. About a C implementation -- looking at benchmarks, I'd be happy if it was just ported to Ikarus Scheme. (Maybe once Ikarus is done...)
Actually, quite a few features Arc uses are taken from the underlying scheme -- like garbage collection, numbers, closures, basic I/O, strings, and so on. In that case, you'll need to count most of PLT Scheme, which dwarfs Arc's 3450 lines. So Arc isn't nearly self hosting yet. But it will be.
