David A. Wheeler wrote:
Alan Manuel Gloria:
Hmm. Possible confusion between ()-as-s-expr versus
f()-as-swt-expr-function-call IMO.
Yes, but that's no different than any other language. In C and friends, f(3)
is not the same operator as (3 + 4). Unfortunately, it's not hard to do (3 +
4) when you meant to do {3 + 4}. A colorizing text editor can make those
blazingly clear, though.
My current thought is to allow f{3} instead of f(3), in case that worries you. But to be
honest, I don't really like the look of f{3}. My goal is to make the surface syntax
"comfortable", even to those who don't use Lisp day-in/day-out... because OTHER
people have to read my code, not just me :-). f(x) as a function-call is so standardized
that I can't find examples of anything other than f(g(x)) or f g x. Well, except Lisp
:-).
--- David A. Wheeler
I imagine you invited me onto this list for my perspective as a Lisp
outsider, so here it is. :)
I've been following these proposals, and been having a difficult time
keeping the decorations straight. My first reaction was "huh?" followed
by "oh!" and then "why?" I'm not going to claim to be the brightest bulb
in the universe, but I have dabbled in quite a few languages in my quest
for The Perfect Fit, and this confuses me more than most confusing
things I've seen so far.
People expect a language parser to use a consistent set of rules. (This
may be a strange idea to people who use their languages to write
languages, but there it is.) There are often differences in rules
between types of scopes (e.g. module vs. class vs. function), especially
in statically-typed languages, but overall the rules are more similar
between scope types than between languages.
With these recent proposals, there are arbitrary differences depending
on the whims of the programmer. That's much better than arbitrary
differences imposed by a parser, but it'll still make people's heads spin.
In my no-longer-professional opinion, you should leave the decorations
to the s-expressions. Give the sweet-expression folks One Way to Do It,
which is the full sweet suite, of course. Give them a quick way to drop
down to pure s-expressions if they need to. (Enclosing a list in {}
might work nicely. ;)) If anyone will want to selectively enable
language features, it won't be these people.
The s-expression folks *might*, but they've already developed the
requisite band-pass filter for reading Lisp code, so most won't see the
point of it anyway. You're an odd duck in your community, David, and I
mean that as a compliment.
----
One last thing: I agree with Dave Herman that your sweet-expression page
is well-written. I had no problem following most of it with just a
passing familiarity with Lisp and Scheme. (I had to look some things up,
but that's expected.) One thing I don't understand is the need for full
backward compatibility. Is it because readers are global, and you can't
switch them out per-file - or at least, you can't expect people to do that?
If that's the case, maybe the right thing to do would be some sort of
file-level block delimiter rather than expression-level enclosures. I'd
be perfectly happy with something like this:
*readable* (or some other non-syntactic marker)
defun factorial (n)
if (n <= 1) ; this is lovely, by the way
1
n * factorial(n - 1) ; or n * {factorial (- n 1)}
*unreadable* (or some less snarky non-syntactic marker :D)
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
And have it default to s-expressions for backward compatibility. Can
that work? Could it also work interactively?
Neil
