Not sure about the structure being right or not, but the script interface to The Gimp comes to mind, at least for graphics primitives, only because it is Lisp and could be translated to Arc w/o reinventing the wheel (reinvention could be Phase II:-)).
Built-in "Industrial D" operators would be a major win--standardize ways of reasoning about data, regardless of how/where it originates or is stored. The core operators would not be for database/external storage, but just plain data. Similar to Perl's DBI:DBD, only with DBI operators built in and implementing relational calculus, not SQL function calls.
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:-)
