Tayssir John Gabbour <tayss_temp2@yahoo.com> wrote:
+---------------
| If you want to experiment with infix notation, you might search around
| for packages like the following, which offers infix-within-Lisp: ...
| But you may not find "formal proofs", as you requested earlier. That's
| a level of evidence not found in even the hardest sciences, as they
| rely on evidence rather than proof. And this is a UI issue; I can
| intellectually find situations where I'd consider infix "better." But
| that doesn't mean I'd want to absolutely pervade Lisp with it.
+---------------
Well said! IMHO, it is indeed mostly "a UI issue". Google for past
articles I've posted here [and in c.l.scheme, before that] -- keywords
"OPFR", "P'Lite", "Parentheses-Light Scheme", "parenthephobia" --
for some of my experiences with trying to make {Scheme,Lisp}-based
programs with command-line interfaces more accessible to parenthephobes.
Even though I *wrote* "P'Lite Scheme" [an infix reader/preprocessor,
with syntax a cross between Tcl & ML(!)], and for several years
supported a user community of about a dozen engineers who used it
for user-mode debugging of various new hardware devices, in the end
I personally found myself always reverting to native {Scheme,Lisp}
sexpr-based REPLs. [This was quite easy to do in P'Lite, since a
"\(" was the "escape into Scheme" marker.]
Well, there *is* one exception to that: While I mostly use standard
REPLs for most of my current CL hacking (mainly CMUCL), I *do* find
that the "OPFR" ["Outer-Parentheses-Free REPL"] interface feels more
"natural" when doing user-mode hardware debugging, and it's *MUCH*
better tolerated by my co-workers than a fully-parenthesized REPL
would be, even though *only* the outer/top-level pair of parens are
suppressed. Go figure.
-Rob
p.s. Oh, and for the curious-but-Google-lazy, here's how a standard
REPL compares with OPFR. First, normal CMUCL [with some hardware-
support libararies loaded, for functions like D32, and the "0x"
readmacro (to make cut/paste from C easier)]:
cmu> (+ 1 2)
3
cmu> (expt 2 100)
1267650600228229401496703205376
cmu> (loop for i below 5 collect (cons i (expt 2 i)))
((0 . 1) (1 . 2) (2 . 4) (3 . 8) (4 . 16))
cmu> (d32 (+ adc 0x80) 0x80 0x80)
0x80: 0x00040625 0x000000fc 0x00000000 0x00000000
0x90: 0x00000000 0x00000000 0x00000000 0x00000000
0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
0xb0: 0x00000000 0x00000000 0x00000000 0xf0000530
0xc0: 0x00000625 0x7426a0c1 0x00000000 0x00000000
0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
0xf0: 0x00000000 0x00000000 0x00000000 0x7543e014
cmu>
And now exactly the same thing, but using the OPFR REPL:
hwtool> + 1 2
3
hwtool> expt 2 100
1267650600228229401496703205376
hwtool> loop for i below 5 collect (cons i (expt 2 i))
((0 . 1) (1 . 2) (2 . 4) (3 . 8) (4 . 16))
hwtool> d32 (+ adc 0x80) 0x80 0x80
0x80: 0x00040625 0x000000fc 0x00000000 0x00000000
0x90: 0x00000000 0x00000000 0x00000000 0x00000000
0xa0: 0x00000000 0x00000000 0x00000000 0x00000000
0xb0: 0x00000000 0x00000000 0x00000000 0xf0000530
0xc0: 0x00000625 0x7426a0c1 0x00000000 0x00000000
0xd0: 0x00000000 0x00000000 0x00000000 0x00000000
0xe0: 0x00000000 0x00000000 0x00000000 0x00000000
0xf0: 0x00000000 0x00000000 0x00000000 0x7543e014
hwtool>
Not much difference you say? True, but it makes a surprising
amount of difference in usability, nevertheless. Since the
vast majority of the "commands" in the HWTOOL app normally
take only atomic args [the first arg of D32 above is an exception],
most of the time users never need to see/use prefix notation.
p.p.s. Oh, and because I sometimes forget which REPL I'm using,
OPFR allows normal prefix notation, too: ;-} ;-}
hwtool> * 2 (1+ 4)
10
hwtool> (* 2 (1+ 4))
10
hwtool>
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607