Shared publicly  - 
don't make me ANGRY!
Rat Xue's profile photoFabrice Popineau's profile photoXah Lee's profile photoLuis Souto Graña (spectrumgomas)'s profile photo
Rat Xue
I imagine you smile even when you are angry :o)(o;. 
Guess what ? :-)

"Of the past 3 decades, lispers, i mean expert lispers, have continuously complained and came up with ways to fix the lisp syntax problem. That's evidence right there that it is not a speculative problem."

I have rather seen expert lispers trying to explain that there is no problem with Lisp syntax. No expert lisper wants to "fix" it. I'd rather say that there are people who for various reasons don't feel comfortable with this syntax. But Common Lisp is one of those few languages where expressions of the language are their own abstract trees. This is what allows for macro-expansion, data-driven programming, DSLs, etc. and this is very intrinsic of the syntax. Remove the Lisp syntax and all of this is gone. This style of programming is very specific to Common Lisp. How many programming languages allow run-time code generation and compilation into machine code? Common Lisp comes as a whole, it is not a matter of religion.
Xah Lee
+Fabrice Popineau you wrote: 
“I have rather seen expert lispers trying to explain that there is no problem with Lisp syntax. No expert lisper wants to "fix" it.”

that's not true at all. There were CGOL, Dylan, just to name two. There are lots academic articles, indentation based formatting, and others. And even this or last year, there's new wave of such implementation (frequently mentioned in lisp or emacs blogs, forum, i'm sure you've seen it. (can't be bothered to google the name now.))

i've been in lisp community for a decade (i know, much less than you), but i know how you argue. (i'm also a lisper, a minor one, emacs lisper (but also Mathematica)). I've seen all the arguments…

the expert lisper includes top recognized lisper… am not going to take time to find nice collection of quotes and names …. Been doing this for a decade. I don't think you'll agree, or conceded to a point.

btw, the Scheme Lisp turned Racket lisp, also support () [] {} brackets. (was it you who told me this recently here?) So, even that, can be considered a fix to lisp monotonic paren problem. Of course, i've seen Common Lisper's reaction of that: blasphemy!
Xah Lee
+Fabrice Popineau 
“This is what allows for macro-expansion, data-driven programming, DSLs, etc.”

true, but in context, bullshit. 
Lisp syntax isn't regular. See
〈Programing Language: Fundamental Problems of Lisp〉
Mathematica syntax is 100% regular. So is XML much more regular than lisp. XML has developed various syntax transformation technologies. Mathematica has a syntax transformation layer, transparent to user, yet one can code in pure nested way if he wants.

but also, aside the point, is that Mathematica pattern matching is a magnitude more powerful than lisp macros. This can be said of any term-rewriting system. A term-rewriting system, is basically a proper macro system.

I know you are a Common Lisp expert. But i've done argument on these issues with common lispers in past decade. So, perhaps the conclusion is simply we agree to disagree.
Rat Xue
When did you first become aware this made you angry? 
I don't say that it is not possible to do the same kind of things with other syntaxes. Only that CL syntax is the simplest way to achieve it.
In some ways, C++ templates achieve at compilation time the same kind of things CL macros do (albeit C++ can't generate code at run-time). C++ template syntax is a lot heavier than CL syntax.
I know about Dylan. You also have the same kind of AST handling in OCaml.  Even in C# I think (recently). However, it always comes at the price of a greater syntax complexity. CL is 1994, and since then no language pushed introspection and intercession that far. So CL must have had something right from the beginning. From my experience, the importance of syntax is far underestimated. (Hey: look at TeX syntax ;-) ) 
"the Scheme Lisp turned Racket lisp, also support () [] {} brackets."
It is not me but I've read it too here.
You also have Clojure.
From my point of view, syntax handling can be greatly eased by the right editor. I have seen  people trying to teach Lisp with Eclipse. It was a nightmare for students. Either use the right tool (LispWorks personal edition) or use another programming language.
But for learning, you need to have a good experience, not a bad one.
I will come back on this once again, because,  I think we don't disagree: I would rather say we don't understand each other. I even wonder if I do not miss something somewhere.
So I will rephrase why I see Lisp syntax an essential part of the language that you don't find in other programming languages.
Lisp is one of the few languages where you don't need to write a parser nor to write specific data structures to parse its own programs.
You can write the following:
(defun foo (x y)
  (+ x y))

(foo 3 4)
;;; -> 7

;;; Replace the '+ by a '*
(setf (car 
       (nth 4 (function-lambda-expression (function foo)))
;;; -> *

(foo 3 4)
;;; -> 12

I claim you can't do this (and all that it implies: defining code at runtime) with the vast majority of programming languages. If you start with a language with a C-like syntax, it would require data structures to handle the various kind of constructs: expressions, loops, etc.. Here is an example of what MS did with Roslyn for VB and C#:
and you'll see that it is far from simple.
So yes the syntax of Lisp is uncommon (some would say awkward) but changing it will likely break this feature of Lisp.  Not all programs (nor all programmers) do use it.
Xah Lee
+Fabrice Popineau yes. What you wrote i read many times in past decade. Thanks for the comment. I understand that aspect well. Here's something that might be interesting

one can do what you described in Mathematica or XML.

Again, in M, it has syntax just like lisp, purely nested structure (but yet it's 100% regular). However, it has a transformation layer, transparent to user.

user can code in the pure nested form like lisp, or in traditional form. The transformation is purely mechanical, systematic, and automatic/transparent to user.

M is a lang similar or a family of lisp.

Now, the above is not about pattern matching. But M has pattern matching. This is where it is relevant to lisp macros. With pattern matching as in M, it's a term re-writing system, so as has mentioned, it's a order magnitude more powerful than lisp macros. (imagine, every line of lisp is a macro. That's basically what M is.)

in summery, there are 2 ideas here.
(1) a purely nested and regular syntax, such as lisp, xml, Mathematica, can do syntax transformation on the fly. This point you mentioned in your last post.

(2) a systematic pattern matching system, along with the idea of regular syntax above, beats any sort of macro system in Lisp. This is also demonstrated in XML and its various transformation technologies.

Now, the above 2 points isn't exactly the point of this thread, about lisp syntax and cult nature. The funny thing is (no disrespect to you), when it comes to syntax, lispers only see their advantages, just like perl will insist their advantages, and ignore any other info.

the point i pointed out in the article is that, lispers insists how their synatx is certain data is program, or macros, yet refuse, completely ignore, XML and the much superior Mathematica, based on similar principle. And, when one points out that lisp syntax is less regular than M or XML, they say it's not important.
Well, we should set up some kind of wiki page with examples of how things are done in different languages. I have only used M for doing a bit of maths, not programming.  So I should probably investigate it. How would you construct a function on-the fly in M and then execute it?

XML is hardly a programming language : it has no set of instructions per se. Ok, it is completely reflexive : you can represent an XML tree in XML (luckily, and albeit it has deficiencies like the handling of entities and stuff).

Rewriting is only about processing, it has nothing to do with the fact that some code can modify itself.
The equivalent in Lisp of pattern matching found in functional languages is probably destructuring-bind.

And again, I don't see how Lisp syntax is less regular than ... well anything. For me it is only very elementary.
Xah Lee
+Fabrice Popineau i wrote a essay here
that might be interesting.

it gives detail about M syntax, how it does transformation, in the context of lisp and xml.

lisp syntax not 100% regular, namely, not every expression is of the form (f …). Example:
# comment
(a . b)
`( , ,@ etc)
in my view, if it is 100% regular, lisp would have been much more powerful, perhaps also naturally developed the M-expression layer M has, and automatic code formatting.

i detailed them here, hope you find it interesting
Thanks for the resources. I'll try to make myself more fluent with M syntax.

About Lisp macro-characters: they do not belong to Lisp syntax. This is precisely their purpose: convert some input into Lisp syntax. Lisp don't need them. [This is where there might be some misunderstanding between us]
'a is (quote a)
`(a ,b) is (list (quote a) b)
And the . for lists is definitely needed because of the definition of lists (that is car, cdr, cons). Every list (a b c) is actually (a b c . nil) .
The Lisp syntax is as basic as open and close parenthesis, spaces and the dot for lists.
Xah Lee
+Fabrice Popineau i see. I haven't studied or used much of lisp reader. Thanks. I know about list and cons well though.
Add a comment...