Here's what's keeping me with Python: my code reads like pseudocode,
and I love that. When I come back to Python code I haven't seen in
months, it takes me all of five seconds to grok it again.

So has anyone seen this?

http://www.dwheeler.com/readable/readable-s-expressions.html

Short version: significant whitespace (indentation can replace parens),
"func(param1 param2)" calls, infix notation (which is good for math
code), and it still parses regular s-expressions correctly. Because it
transforms "sweet-expressions" to s-expressions, macros still work.
Example:

defun factorial (n)
   if (n <= 1)
       1
       n * factorial(n - 1)

(which even I can parse :D) is translated to:

(defun factorial (n)
   (if (<= n 1)
       1
       (* n (factorial (- n 1)))))

(which I can still parse, but with more trouble). Or this:

(2 + mystuff(7 + x) * -(henry) - correction(a b c d) + 2 - pi() - x)

which is translated to this:

(- (+ (- (+ 2 (* (mystuff (+ 7 x)) (- henry)))
         (correction a b c d)) 2) (pi) x)

He's almost got me convinced.

I understand that experienced Lispers use indentation to understand
code more than parenthesis anyway. This creates a situation (rather
like in C-like languages) where the language syntax *doesn't inherently
communicate with the coder very well*, and coder has to add redundant
formatting to make it clear. Then, like in IDEs for C-like languages,
the editors support this to make programming less painful. So why not
take the Python route and make formatting syntactically significant?
The only difference is that Python requires it, "sweet-expressions"
don't.

My main question is whether there are any downsides at all to this
approach.

http://www.opendylan.org/

hth, kenny

--
Cells: http://common-lisp.net/project/cells/

I am asking this because it typically takes a week or two (or sometimes
a few more) until you get used to Lisp syntax. Afterwards, with more
experience, it's typically not an issue anymore. (Although it could
simply be that those for whom this is then still an issue switch to
other languages.)

On the other hand, I also think that adding one ore more surface
syntaxes doesn't solve a fundamental problem, and I don't expect that a
considerably large number of Lispers will take up this idea because of
that. After all, it's _just_ syntax. In other words, there aren't any
downsides, but there also aren't any essential upsides.

Pascal

I disagree very much with the "just" in front of the "syntax" in your
post. Syntax is *extremely* important. We're not writing programs just
for the compiler, we're writing them for our future selves and other
people. If all programmers thought like compilers, we'd have no
problem. But the fact that even hard-core Lispers need to indent the
heck out of their code and learn to literally ignore a significant
portion of the syntax (the parens) indicates that something may be
lacking in the syntax. C programmers indent, sure, but they don't have
to learn to ignore.

Not that I intend to start a flame-war or anything. I know, I'm getting
close. If that happens, I fully expect the great Paul Graham to jump in
and defend me. :D Apparently, Arc's indentation will have syntactic
meaning.

By the way, thanks for writing your "Highly Opinionated Guide." It's
the only document I've found so far that provides a good summary of
Lisp's advantages over other dynamically-typed languages. Your summary
of macros was especially helpful.

Also, thanks for answering my question.

Lisp programming has several different dimensions. One is
the manipulation of external (text-based) code and data. Programmers
need to write/read/manipulate code. Lisp is optimized to
allow tools to support you during working with external text-based
code.

Lisp allows the editor to query the Lisp system while you type code.
The running Lisp system knows all about your code (where it is defined,
the documentation, the arglists, the types, the contents, the callers,
...).

Lisp allows the editor to query the Lisp system while you read code.
You can jump to definitions, inspect values, try out examples, ...

Lisp also supports you manipulating your code. Every expression has
a very simple to find start and end. You can use simple structure-based
editing (see paredit), which has little mental overhead once learned
(it is a bit like learning to ride a bicycle). It allows you to
manipulate
your code based on list structure (select, transpose, group, extract,
copy, ...).

So, you have an editor/language combination which supports you
manipulating your code and you have a Lisp system which is
available during editing for various queries.

Then comes the interactive experience. You are working with an editor,
which is connected to a Lisp system (for example via SLIME if your
editor is Emacs). Alternatively you will use an editor-based Listener.
Then you can start thinking of code as data. You will
write some code/data in the editor/listener and the Lisp system
reads them and you can apply functions that manipulate that code.
A simple example is a macro expansion. Your editor buffer
has some code and you want to macro expand it. The editor
takes the code, the Lisp system reads it, generates data structures,
macro expands them, returns new code and your editor displays
it (possibly pretty printed).

You can also write some sketch of some code, read it
into the Lisp system and use the Lisp
system to manipulate it until it has the form you like.
Pretty print the result and place it in your editor buffer.

The whole tool chain is highly optimized around Lisp syntax,
Lisp datastructures and the various tools to read/write/manipulate
these datastructures.

More advanced systems can also parse Lisp data directly from
editor buffers (like you want to display a class graph, the
editor prompts you for a class and all class names in your
editor buffers are mouse sensitive). Or tools like McCLIM
allow you to have mouse sensitive Lisp read-eval-print-loops.

Back to your question. What is the cost of ignoring the Lisp culture
around the syntax? You will have difficulty to use the tool chain.

But then, the syntax is just the first hurdle. Be prepared for more
hurdles. Probably higher ones.

defun factorial (n)
if (n <= 1)
1
n * factorial(n - 1)

Not any better than:

(defun factorial (x)
(if (<= n 1)
1
(* n (factorial (1- n)))))

The main difference is that it is borderline trivial to auto-indent
the second one with your editor.

Let's try another test:

defun factorial (x) if (n <= 1) 1 n * factorial(n - 1)

This is hard to read and also shows another weakness: explicit
grouping, and therefore no precedence rules to remember.  If you take
out the parentheses, you have to memorize precedence rules.
Precedence rules are one of the chief things that make it easy to
write unreadable C and Perl.

By contrast:

(defun factorial (x) (if (<= n 1) 1 (* n (factorial (1- n)))))

This is more readable and, in the event you have trouble reading it,
can still be auto-indented.

So you'll have to perdon us, if after FIFTY YEARS people keep looking
half a hour at lisp and keep suggesting to modify the syntax:

- we've got better things to do,

- we've solved the problem once for all with reader macros and macros
  that allow you to modify the syntax in your program.

I'd just add that IMO, this question should be solved at the editor
level: everytime you load a source file in an editor, the editor
should apply any syntax, indenting and colorizing the programmer
prefers. (And therefore the source files should keep a consistent
form: S-expressions, and the use of reader macros should be avoided).

--
__Pascal Bourguignon__                     http://www.informatimago.com/

http://groups.google.com/group/comp.lang.lisp/msg/a827235ce7466a92

--
__Pascal Bourguignon__                     http://www.informatimago.com/

If you panic and try to struggle it'll get much worse; just go along with
the main ride or bail out until you're ready.

Yep; get over it as quick as possible and hold on for the rest of ride
because there will be some crazy changes. This is just the first one of
many bumps so you've better brace yourself!

Good luck and have fun .. :)

As in ProGraph (q.v.), perhaps?  ;-}

+---------------
| On the other hand, I also think that adding one ore more surface
| syntaxes doesn't solve a fundamental problem, and I don't expect
| that a considerably large number of Lispers will take up this idea
| because of that. After all, it's _just_ syntax. In other words, there
| aren't any downsides, but there also aren't any essential upsides.
+---------------

Actually, I would say that, based on my experience with alternative
surface syntaxes for Scheme/Lisp [Google for my name and "P'Lite"
or "OPFR"], there *are* downsides for "Lispers", especially for
writing sizeable programs. I myself have abandoned each of the
surface syntaxes I've come up with for *programming*, because
they (1) got in the way, and (2) were *not* as readable when I
came back to the code weeks, months, or years later. Normal Lisp
[or Scheme] code, on the other hand, is "timeless". IMHO.

That said, I continue to advocate the use of a "mild" parentheses-
light surface syntax [OPFR] for *interactive* (command-line style
or REPL-like) use, especially for non-Lisper users, for a variety
of more-or-less dedicated "tool" programs.

The "hwtool" pattern that I seem to keep re-implementing[1] over
and over at each new job is a prime case in point. It seems to be
something of a sweet spot in design/use space, with the following
salient features:

1. When run from the shell without arguments, you get a command-line
   prompt with a REPL; given arguments, the rest of the line is taken
   as a single input command-line, then it exits.

2. The input [either REPL or shell command] is parsed by "OPFR",
   an "Outer-Parentheses-Free Repl" (q.v.). That is, to a first
   approximation [ignoring details like continuation lines],
   OPFR:OPFR-READ takes an input line string, wraps "(" & ")"
   around it, and calls READ-FROM-STRING, then does the usual EVAL,
   print [including multiple values], and loop.

3. To make life easier for Lisp-aware users [including me],
   any input that begins with "(" is assumed to be a CL s-expr,
   and normal CL:READ is called to read it.

4. For hardware debugging [its main use], the usual panoply
   of PEEK, POKE, DUMP, etc., utility functions is provided.

5. To make life easier for non-Lisper users [and for hardware
   debugging], a "0x" readmacro is enabled, and a "~/0x/" FORMAT
   function is provided to ease the writing of register dumps.

6. A large majority of things a user needs to do with the tool
   are pre-defined as functions, which therefore appear to the
   naive user as "commands" in the REPL.

7. The program sets a fairly large number of global lexical[1]
   convenience variables with values precomputed from the run-time
   environment, so that most of the time all of the "command"
   arguments a user needs are either one of the precomputed
   convenience variables or literal constants. This sharply
   lessens the need for typing actual Lisp arithmetic expressions
   as input.

A very small example:

    $ hwtool
    Hardware debug tool (CMUCL version)
    Warning: Non-root can't mmap "/dev/mem"
    hwtool> loop for i below 10 collect i

    (0 1 2 3 4 5 6 7 8 9)
    hwtool> deflex vec (vector 1 2 3 4 5)

    VEC
    hwtool> d32 vec
    0x48a0b908: 0x00000032 0x00000014 0x00000004 0x00000008
    0x48a0b918: 0x0000000c 0x00000010 0x00000014 0x00000000
    0x48a0b928: 0x48a08b3f 0x48a0b933 0x28f0000b 0x28f0000b
    0x48a0b938: 0x0000008c 0x28f0000b 0x48a0b93b 0x48a08d2b
    hwtool>

Since I don't have any poke-able hardware registers handy at
the moment, let's reach in and mess with the internals of VEC.
[Don't try this at home unless you and your GC are best of friends!]

    hwtool> w32 0x48a0b918 0x28  ; Decimal 10, as a CMUCL fixnum
    hwtool> d32 vec
    0x48a0b908: 0x00000032 0x00000014 0x00000004 0x00000008
    0x48a0b918: 0x00000028 0x00000010 0x00000014 0x00000000
    0x48a0b928: 0x48a08b3f 0x48a0b933 0x28f0000b 0x28f0000b
    0x48a0b938: 0x0000008c 0x28f0000b 0x48a0b93b 0x48a08d2b
    hwtool> vec

    #(1 2 10 4 5)
    hwtool> w32 0x48a0b920 (lisp-obj #\A)  ; Chars are immeds.

    hwtool> d32 vec
    0x48a0b908: 0x00000032 0x00000014 0x00000004 0x00000008
    0x48a0b918: 0x00000028 0x00000010 0x000041a6 0x00000041
    0x48a0b928: 0x48a08b3f 0x48a0b933 0x28f0000b 0x28f0000b
    0x48a0b938: 0x0000008c 0x28f0000b 0x48a0b93b 0x48a08d2b
    hwtool> vec

    #(1 2 10 4 #\A)
    hwtool>

As I have written before, this appears to be just enough masking
of the "Lispiness" to make such programs be quite acceptable to
general technical users (e.g., hardware engineers, C programmers).

-Rob

[1] Re-inventing, to avoid IP contamination from the PPoE.

[2] Using the now-common DEFINE-SYMBOL-MACRO hack.

/Jon

However, the fact that there is a considerable number of people who
prefer Lisp syntax, even strongly so, shows that it has its merits.

The problem with additional syntax is that by definition, you lose the
regularity of the syntax. The more you add, the worse it gets. And this
impedes with syntactic extensibility. The more syntax there already is,
the harder it is to add new syntax that fits well with the rest of a
language.

So what you get in syntactically richer languages is maybe a slight
advantage in the learning phase because of some level of familiarity of
the syntax, but a strong disadvantage in the malleability of the code
representation. In Lisp, you can make the code look like related
concepts from a given problem domain. You can't do that (so well) in
other languages. So either the languages already fit your problem
domain, or they don't in which case you have a discrepancy between the
problem and they way you have to express a solution.

You may want to take a deeper look at Dylan, which was an attempt at a
compromise. The syntax is somewhat richer than Lisp syntax, but still
relatively regular. You might want to take a look at Jonathan Bachrach's
work on "Dylan Procedural Macros" and the "Java Syntactic Extender" in
this context - see http://people.csail.mit.edu/jrb/

Pascal

"[I am] becoming interested in Common Lisp. Why? I want the functional
goodness and the MACROS, that's why."

The whole point of Lisp -- the thing that makes Lisp Lisp and not any
other language -- is the amazing discovery that both the programmer and
the computer can in fact read and write THE SAME CODE!

If we did what you propose -- if we gave Lisp some sort of random
surface syntax. (Python is an especially random example of this --
using, of all things, whitespace and lineturns (!!) as syntax) which
was read differently by the programmer and the computer, then all the
magic of Lisp, esp. Macros, which you claim to be the thing that
brought you to Lisp, would suddenly vanish in a puff of syntax.

You don't understand this yet, but you will if you keep at it, and esp.
when you get to macros.

Now, closely related to this, your second point:

"And as an aside, I'd love to have Python's array (list) and dictionary
(hash table) syntax. I'd switch to Lisp and convert my entire codebase
TODAY if I had that."

You do have that; They are called hash tables and the only differences
are that you have to declare them before using them, and they have a
slightly more long-winded syntax than python's. Here's a challenge for
your first experiment in macros: You want python-style dictionaries. By
the magic of Lisp syntax and macros, you can in fact, have them!
Remember in thinking through this: Don't fight the syntax! If you try
to have both python dicts AND python syntax, you'll lose, and you'll
lose macros and you might as well go back to Python. But you'll know
that you've learned to think in Lisp when you can see that this, and
anything else you want, you can have; the only limitation is your
imagination! A small price to pay, I'd say, for having to say (+ 1 2)
instead of 1+2....

(defun python-dictionary-reader-macro (stream brace)
  (declare (ignore brace))
  (literal-hash-table (read-delimited-list #\} stream t )))

(set-macro-character #\{ (function python-dictionary-reader-macro))

(gethash "to" { "for" "four" "to" "two" })
--> "two" ;
    T

You could work harder to allow : and , inside {}, but it's not worth
it, they're just noise.

#[key1 "value1" key2 "value2"] to construct,
#100[key1 "value1"] to construct with a specified hash table size, and
[hashtab key1] to retrieve (this is setf-able)

And it's this simple:

(set-dispatch-macro-character #\# #\[
  #'(lambda (stream subchar arg)
      (declare (ignore subchar))
      (let ((list (read-delimited-list #\] stream t))
            (keys '())
            (values '())
            (hashtab (gensym)))
        (do ((key list (cddr key))
             (value (cdr list) (cddr value)))
            ((null key))
          (when (not (symbolp (car key)))
            (error "Keys must be symbols"))
          (push (car key) keys)
          (push (car value) values))
        (setf keys (nreverse keys))
        (setf values (nreverse values))
        `(let ((,hashtab ,(if arg
                              `(make-hash-table :test #'equalp :size ,arg)
                              '(make-hash-table :test #'equalp))))
           ,@(mapcar #'(lambda (key value)
                         `(setf (gethash ',key ,hashtab) ,value))
                     keys
                     values)
           ,hashtab))))

(set-macro-character #\[
  #'(lambda (stream char)
      (declare (ignore char))
      (let ((list (read-delimited-list #\] stream t)))
        (when (/= (length list) 2)
          (error "Invalid number of arguments to []"))
        (when (not (symbolp (cadr list)))
          (error "Key must be a symbol"))
        `(gethash ',(cadr list) ,(car list)))))

Neil Toronto ha escrito:

What you (both) have demonstrated is the power or reader macros in
defining new syntax, but I don't think that new syntax (in the sense of
reader macros) is either necessary nor particularly appropriate in the
context of the present discussion. I had mind mind something at the
same time hack-wise simpler, yet coneptually more complex: Not just
letter one type: {for bar baz frob} -- forget the braces etc. Rather,
what I had in mind (Neil puzzling through himself) was what the central
concept(s) is(are) of dictionaries and how, using standard Lisp macros,
one could get the >concepts<, not just the baces and brackets. Of
course, the concepts are almost already there (as I pointed out) in
Lisp (in the guise of hash tables, mostly), and I don't think that he
wants -- or shouldn't want -- what you have offered, which is the
syntax. Rather, he wants (or should want) hash-tables to be as
convenient as dictionaries. The only things really limiting this in
Lisp are the need to declare them, and the ability to use
comprehensions (i.e., slicing expressions aka comprehensions aka
generators) as the targets of setting operations. (Some would say that
generators are themselves a conceptual advantage of Python, but these
are trivally obtainable using, or if you like, macofying in of Lisp
generators, and there are already lisp packages that do this!)

http://user.it.uu.se/~svenolof/Collect/

kt

--
Cells: http://common-lisp.net/project/cells/

:)

Did I say "user"? PWUAHAHHAHAHAHHAAH.... I meant self-important
dilettante. "Hey, guys! Just found Lisp! Love it! Here is how we can fix
it...your thoughts?" PWUAUUAUAUAUAHAHAHAHH... I slay myself.

kenny

--
Cells: http://common-lisp.net/project/cells/