I appreciate the nitpick; I've changed the text to be clearer. (In general, I welcome feedback on how to improve the docs, especially if I'm blatantly wrong about anything.)
I've been thinking that the Scheme code (ac.scm) should be split in two parts: an "axiomatic" part that defines car, cdr, set, annotate, etc; and a "library" part. The "library" part would define OS stuff like current-gc-milliseconds, open-socket, probably atomic-invoke, etc. There would probably be a "math" library that defines exp, sqrt, and all the missing math functions.
This structure would make it clear what parts of the language are really axioms, and what parts are in Scheme for performance, convenience, or because they are OS things that require low-level hooks.
Here "scheme-fn" is a macro that returns an Arc function that calls the named Scheme function, but still expects to be passed Scheme values and returns a Scheme value. Then various functions such as "scheme-istrue" can be used to convert Arc values to Scheme values and back again.
I can't blame him. Cutting bloat in the language core is clearly a goal. Nothing should go into the official Arc release unless it has proven its value in real code (which is basically News.YC at the moment).
Sure, he has to keep the control over the things. The point is that a few bug fixes (the mkdir problem for example), simple conveniences (see arc.sh) and even trivial optimisations (arc< to name it) available in anarki are of interest even in the official release. I'm not talking about experimental stuff (infix numeric notation, vectors, standalone exe, maybe docstrings, experimental module systems, ...)
But I think the few fixes and conveniences should really be taken into consideration. I can't believe none of them are of interest.
They probably are of interest, but let's not forget he's running a company in his spare time, and 3 releases in about 3 weeks is a pretty good work rate.
Of course, as someone running Arc in Windows, I'd love it if a bit more stuff worked out of the box (e.g. the blog, which didn't work in Arc1 IIRC). That's why I'm probably going to switch to developing on Anarki and then testing it on vanilla Arc afterwards.
Note that I don't criticize Paul's attitude there. 3 releases in less than a month is much more than what I expected. He didn't release early, but at least he releases often :) I just meant a few things would deserve a little more consideration, at least in the next few weeks/months ?
I'm trying to write some Arc documentation, and the lack of consistency and orthogonality is rather vexing.
For instance, there's no (char "a") to create a character. (string "a" 'b #\c 1) combines all those into a string, but (sym "a" "b") doesn't work. There's also newstring to create a string.
(table) creates an empty table, not a table of its arguments. If you want to convert arguments into a table, you use the inexplicably named "obj". The positive function works on any random type (string, table, whatever) except for a complex number. And coerce pseudo-succeeds for some things: (coerce (table) 'int) returns a table.
And don't get me started on operations that
work on lists, vs operations that work on lists or strings, vs operations that work on lists, strings, or tables - it seems pretty random.
yes it is. i didn't realize that table was different in anarki. well, there is always listtab, but seriously, table should work like the anarki version.
This what is broken in Arc right now - essentially we can't fix anything of this scale (or arguably anything non-trivial). If we do there will be merge nightmares when PG releases the next official version (and every subsequent release). All we can do is mention problems on the forum and hope he notices and changes things in the next official release.
I believe this would be solved if we shared a repository system (git) with PG in which we could sumbit patches which he would hopefully approve and merge in. Or not approve. Or delegate the sifting out the good patches to someone who knows what they're doing / shares the proper vision of arc.
I don't think that would fix it, as PG would probably refuse most of the patches anyway. It's not like this forum has a lot of traffic. Patches are unlikely to get lost in the flood (12 articles in the last 24 hours, and PG last commented 18 hours ago).
The two ways to get changes into Arc, as far as I can see, are to find a bug or write some real-world code that proves your suggestion is a good one. With so little real-world code around, that means very few changes will make it.
On the other hand, the last release was all about merging News.YC so there's no surprise that it lacks new features. Who knows, perhaps the next one will incorporate half the stuff from Anarki? We have very few data points from which to draw a conclusion.
Don't be disheartened, brother. It seems to me Mr. Graham gave us all a first cut to get exactly this kind of feedback, but the core language isn't yet fully baked, and so we should acknowledge that we're at the very beginning of a long journey. I'd be surprised if Linus Torvalds was merging in kernel patches from anyone besides himself in 1992.
When I looked at benchmarking earlier (http://arclanguage.org/item?id=2455) I discovered that the performance hits were very different from what I was expecting. (I.e. in my case, it wasn't the function call overhead, but the < operator of all things.) My point is that if you optimize Arc, make sure you measure carefully, rather than assume you know where the performance goes. (I also found that performance is one of those things you're not supposed to discuss, a la http://www.paulgraham.com/say.html)
In my brief examination of the Arc internals, I didn't see any obvious optimizations. The ac-niltree/ac-denil stuff seems like there should be a better way. The conversion between nil and #f (e.g. ar-false? in your code above) seems like excessive overhead. But I don't see any better alternative.
I have to be coding pretty fast and furious in CL but it has happened a few times over the years. Nice warning or error (I forget) from the compiler, tho.
