This is not a change, but a reiteration of a goal: keep it small, keep it fundamental. It would be wonderful if arc 1.0 turned out to be the 100-year, onion-free language, and all else occurred in libraries. pg wisely deferred the Unicode issue, and I hope he's actually doing that to demonstrate that it's not ultimately a language issue--and to give others a chance to provide a silver bullet(s) for all things character-ish. I chased Scheme through two major releases, until it went off the r6rs cliff. I want a tool for thinking about problems/applications, and I don't want to do yet another brain transplant every 3 years as the language grows more cruft. Oh, and a worthy thing to bundle with arc would be a test suite that implements every algorithm in TAOCP. Thank you:-)
People keep saying that it's unicode is a library issue, but it's not! It's a language issue!
If you move unicode to the libraries, you have to move the string type to the libraries too, assuming strings are lists of unicode characters. And if you move the string type to the library, how can you convert a symbol to a string?
That's not an option, so the alternative is that strings are just byte arrays, ignorant of their encoding, and you need libraries to find out what the length of a string is, and you're back in the tar pit where Ruby and PHP were in 1997 and where they pretty much still are today.
I've been down that road before. I know exactly where it ends.
I guess I'm enjoying thinking of characters/strings/whatever in the same way I think of a media stream. I don't reason about media streams in my general programming, but when I need to do so I use a specialized, application-specific library--the language isn't built with any preconceived notion of what music is, or an image, or video. I like a minimal (if even that) built-in notion of what char/text is. I like Arc (so far) and I do hope it avoids premature textualization for a very long time:-)
