The fundamental philosophy of Arc is that "hard to understand" is not an issue. It's a language for programmers who aren't afraid of learning hard things, and rarely have any trouble doing so. It's the anti-Java, if you like. So that's not really a good reason to discard the OP's idea.
It's basically saying: if any of my operands are nil, return nil; otherwise, return the final operand. So (and 1 2 3 4 5) should return 5, because none of those numbers is nil. But (and 1 2 nil 4 5) will return nil.
Incidentally, it only evaluates as far as it has to. (and (a) (b) (c)) will evaluate (a), then if the result is non-nil it will evaluate (b), then if the result of that is also non-nil it will evaluate (c) and return the answer to that last evaluation as the result of the whole expression.
This is different to a hypothetical bitwise and, which would evaluate at least until it reached zero, "and"ing the bits together as it goes. So (bitand 42 23), which is (bitand 101010 010111) in binary, would return 2, which is 000010 in binary. That's not what (and...) does.
I think people who really get stuck into Arc should be called ArcTicks.
But seriously: I read "arcist" with a "ss" sound instead of a "k" sound for the "c", and it sounded rude. Mind you, that's with an Australian accent.
Rummaging through /usr/share/dict/words: the Arc Forum can be the Arcade, and its regular posters Arcadians, with perhaps the top poster (in quality, not quantity) given the title Archimedes; backwards compatibility issues are archaisms; PG is the Archangel, or perhaps the Architect (Lisp is the red pill!); Arc programmers in general are Archaeologists; the growing collection of Arc websites form the Archipelago; type safety is discussed in a forum called the Archetype; old posts go into the Archive... The potential is endless!
I think it'll need a Foreign Function Interface to be fully self-hosted. Once it has that, it should be possible to do absolutely everything. I'd be interested to see PG's take on the perfect Arc-ish FFI system.
