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.
