Yeah, maybe they are just an optimization but they are definitely going to be present in production implementations and I think they should be standarized beforehand, and since they are already available in the underlying mzscheme, I think it shouldn't be too problematic to get vectors in Arc.
Again, I suggest {...} for vectors, since they stand out (so to avoid confusing them with lists) and because they remind of array oriented languages.
I'm sure there will be heated debates about the trade-offs between the "hundred-year" aspect of arc and the need to deploy reasonably fast applications. Here are some quotes from http://www.paulgraham.com/hundred.html
"Having strings in a language seems to be a case of premature optimization."
"Logically, you don't need to have a separate notion of numbers, because you can represent them as lists: the integer n could be represented as a list of n elements. You can do math this way. It's just unbearably inefficient."
So arc already deviates from the ideal minimal language; it might well deviate some more, I don't know. In a perfect world, the underlying VM should be able to figure out the most efficient implementation for each particular list you want to represent, and we would never need to bother ourselves with such details.
For comparison, "primitive types" in java are a performance compromise that (a) seriously mess up the language, and (b) are less and less relevant with each iteration of Moore's law.
Notwithstanding any of the above, I have shamelessly used
(mac fpush (thing place) ; a very primitive, naive, fast 'push
`(assign ,place (cons ,thing ,place)))
because the standard 'push uses 'atomic-invoke internally which slows some things down intolerably. Hence ... heated debates.
The only problem with using standard array notation for arc is that [] are already tied up for anonymous functions.
However, I think that too much syntactic sugar like this will end up damaging arc. Partly due to aesthetic reasons, but mostly due to the fact that each user has a different view on aesthetics, and adding too much will just exacerbate the "everyone has their own version" problem.
hmm, come to think of it, I've never used my table literal syntax {...} myself in a program. I wrote it so that I could write out and read back tables, which I use all the time, but that would work just as well with some long syntax like (literal-table k1 v1 k2 v2 ...) which doesn't use up precious syntax characters like { or #{.
