Using straight Icon will make it easier to control efficiency, I think. It will also make the program usable with Arizona Icon, though I haven’t ported the AMD64 support to it.
If I feel the system still is too slow and ought to be compiled, I’ll probably convince myself it isn’t really that slow. I don’t yet know of a suitable non-Icon language. Caml isn’t particularly good dealing with strings, and requires interface files for connecting modules, which can mean more typing. I don’t know how Haskell compares to that, but it is similar enough that it should be easy to learn, and it has lazy evaluation, which is cool. From Python code I have seen, it is too primitive and so I would have to type too much, plus maybe it’s just too slow. I don’t know how Ruby compares. Sather would be too primitive, I think, though I haven’t used or examined it in many years; and the compiler was very slow back then.
Anyone know a real very-high-level language besides Icon/Unicon? It is pretty damn high level IMO; I’d say Caml is more primitive, for instance. I guess there is Icon’s ancestor, Snobol, but I have a feeling that wouldn’t help much. (I don’t know any Snobol but there is a project to include Snobol-style patterns in Unicon.)
(BTW I think the main reason why Icon became a ‘fringe’ language, despite being around since the 1970s and having the whole system be in the public domain, is that to learn the language you had to buy a book. So actually there was one part of the system that wasn’t in the public domain, nor free in any fashion, and that was the documentation. The Unicon book is copylefted but its arrival is late and it is not available in manpage or info format. [I prefer manpage to info.])
