table-w/keys is useful for counting. After creating the table in icemaze's exemple you can for instance do
(++ (h 'cars))
Even more useful, however, is to specify a default value for keys not yet in the table, so you can do the above without first initializing for the keys you intend to use. PG mentioned in Arc at 3 Weeks that lookup failure should return the global value * fail* , in which case you would be able to do
which returns a table where red is 1, blue is 2, green is 1, and no other keys exist. The example is kind of stupid, but the concept is quite powerful.
Good point about fill-table. I didn't think of how easy it is to give this function a newly created table. It still kind of feels like a shortcoming that (table) doesn't accept values like (list) does. And I don't want to define a different function to behave like this. If it's a good idea, it should be in the main table constructor. PG seems to have thought of this already because there's a comment in ac.arc with a definition that involves fill-table. I do, however, see that this would slightly bloat the constructor.
That's your community. Given how much you've been proselytizing, I assume you're involved with that project.
But Arc is not newLISP, and isn't trying to be. If you prefer to use newLISP, please do so -- and stop trying to get people to ignore Arc in favor of it.
And by the way, newLISP is by no means "mainstream".
I usually don't directly compare strings for (character-wise) equality; I search for substrings or regexes, parse out data of another type, or compare modulo case. Strings are just sequences to me; I don't have a reason to process them differently than any other kind of sequence, unless I'm working in C and have to use strings as a hacked-up replacement for symbols. That being said, other languages have chosen to make strings a "value type" (e.g., C++'s std::string).
Thanks for clarifying! From what I've read on CL over the past 3-4 years, EQ/EQL/EQUAL seems to be one of the outstanding issues. (People also complain about the lack of extensible sequences (though some implementations may offer this) and a few things about CLOS. Well, they complain about _everything_ but usually don't offer to fix anything ;-) .)
Parens are an issue -- you need to have all of them. Omitting some parens under some circumstances makes the code slightly shorter, but at the expense of partially hiding the structure of the code.
But here's the real problem: the reader has to understand the forms where parens can be omitted. If you write a macro that creates (def ...) forms, you can't elide the parens around it, because the reader doesn't know it can.
Well I agree that we should only omit parens where it's 100% unambiguous where the actual parens would be. There'd need to be a very small number of simple rules/exceptions (such as "every new level of indentation denotes an extra parenthesis unless ____").
A few years ago Paul Graham seemed to think this would work. However, it may be that he tried it and found that it would be too problematic. I'm hoping that he simply has been too busy to implement it so far.
Be cautious choosing Arc as a first lisp -- It's still in heavy development, so there may be unexpected sharp edges that we lisp veterans instinctivly avoid. You may prefer PLT Scheme (atop which Arc is written), as it's quite similar to Arc at the moment.
Actually, quite a few features Arc uses are taken from the underlying scheme -- like garbage collection, numbers, closures, basic I/O, strings, and so on. In that case, you'll need to count most of PLT Scheme, which dwarfs Arc's 3450 lines. So Arc isn't nearly self hosting yet. But it will be.
