I, too, appreciate the ? for predicates, but that is just because that is how I learned Scheme to begin with. Imagine my horror to have to deal with #'zerop when I got to CL after years with my precious zero? predicate. Arc's lack of punctuation is better than excessive punctuation at least.
From what I've seen so far it looks like pg is staying away from using ? in predicates. In most cases it just makes the name longer. However, I saw this factorial function (rec zero 1 * 1-) in pg's Succinctness is Power essay and thought this (rec 0? 1 * -1) would be an interesting alternative. But then you lose the consistency of all your pedicates not having ?.
The question in my mind is "Why don't the extra character(s) justify the semantic implication?"
Yes, having to type ? or ! is an extra character, and over the course of large applications can add up to dozens of extra characters. Still, I'd argue that these extra characters are truly overshadowed by the language semantics that such characters would embody. One of Arc's goals is certainly to be an easy-to-learn Scheme implementation that people can "just use", and semantics of this sort are the kind that generally make the learning process smoother (at least in my own experience).
"Here again we are saved by our axiom that the user is a good programmer. We assume the user doesn't need operators to be called multiple-value-bind or invoke-restart-interactively to remember what they do."
That seems as clear a disagreement with your assertion as any.
Even if we accept this premise, it applies only to the core language and (de facto) standard libraries (for which we can assume familiarity). As soon as the language is defined in therms of it's implementation it also serves as a coding guideline and this is where the problem lies.
The difference between something like `multiple-value-bind` and `is?` -- especially in the given context -- isn't quite comparable to what Paul's speaking about there, I think. Adding an '?' to `is`, and an '!' to `map` is hardly at all comparable to making the function's name hideously long.
I'm going to have to wait and see on this. I'm sure I'll get used to it. Right now, the bigger difference for me is the lack of #'s everywhere. I agree that doing away with the dual-namespace nature of common lisp is a good thing, but I had never realized how much it affects my reading of code.
I'm guessing in the long run, I won't miss #'zerop but it certainly does look strange at the moment.
