Joe Marshall <eval.apply@gmail.com> wrote:
+---------------
| According to my timepiece, we should be hearing about how horrible
| the parenthesis are and how much more `natural' infix notation is...
+---------------

Myself, I'm happy with parens, but periodically I find myself needing
to make some little CL hack or other that I've written available to
be used by non-Lispers [usually at work], and then *WHAMMO!*, the
whole "paren thing" rears its ugly head once again. Once upon a time
I actually developed an infix dialect of Scheme [well, really just
some syntactic sugar in the reader], and it was used with some success
for a while. [Search Google Groups for "rpw3 plite scheme" for more
details/examples.]  These days I'm using Common Lisp, though, and a
similar hack isn't quite as easy.

But an earlier, much less featureful hack *is* easy in CL, and it
turns out to solve almost all of the parenthephobia issues, at least
the ones I tend to run into. I called it "OPFR", for "Outer-Parentheses-
Free REPL". [Yes, yes, I need to put it up on my server. Long past time,
actually. (*blush*)]

OPFR provides a simple command-line read-eval-print loop (REPL).
The simplicity and utility of OPFR derives from the observation
that most people who are uncomfortable using normal Lisp s-exprs
are actually surprisingly accepting of an s-expr-based interface
*provided* that they are not required to manually type the outer
pair of parentheses on the "command line", *even if* any sub-expr-
essions are still in pure Lisp s-expr form!! This effect is even
stronger when the majority of the functions in the application are
provided as distinct functions or macros, so that users only seldom
require the typing of sub-expressions. [I've also found that having
a "deflex" or "def" macro for defining top-level lexical variables
is very helpful; the following assumes that's been enabled.]

This short example compares the syntaxes. First, normal Common Lisp:

    > (+ 1 2)
    3
    > (def x 34)
    X
    > (def y 25)
    Y
    > (expt x y)
    193630125104980427932766033374162714624
    > (expt x (- y 12))
    81138303245565435904
    > (mod ** 9)
    7
    > 

Now, exactly the same sequence of operations using OPFR syntax:

    opfr> + 1 2
    3
    opfr> def x 34
    X
    opfr> def y 25
    Y
    opfr> expt x y
    193630125104980427932766033374162714624
    opfr> expt x (- y 12)
    81138303245565435904
    > mod ** 9
    7
    opfr> 

The average Lisp programmer will see no significant advantage to the
OPFR syntax (and some disadvantages, such as the need to resolve the
ambiguity of a naked symbol[1]), especially since sub-expressions must
still be fully-parenthesized as in the last example above. Nevertheless,
experience with real users over more than a decade has shown that the
acceptance of the OPFR syntax to the average user is *enormously*
greater than the "pure" Lisp s-expr. Go figure.


-Rob

[1] For compatibility with Tcl and other interfaces the user might
    be used to, OPFR calls a naked symbol as a "command" function if
    it's FBOUNDP, else it's treated as a variable whose value is to
    be printed. Conversely, if the user types a form *with* the outer
    parens supplied [as is all too frequent by accident when Lisp users
    type at an OPFR!], it strips the "extra" level of parens. This
    almost always "does the right thing".

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607