4 ms·

I get what you're saying, but that's a pretty extreme view. Parenthesis are obviously syntax, even if they look similar to the notation used to represent ASTs i

I get what you're saying, but that's a pretty extreme view. Parenthesis are obviously syntax, even if they look similar to the notation used to represent ASTs in other languages. They are minimal syntax, but they're still syntax (also, lisps have `"@' and sometimes {}[]). Just because this is the internet, I'll also disagree with your second point. Lisp programmers use white space and macros to make programs more readable. Despite this, lisp's adoption trails many less powerful languages that offer more intuitive syntax. Since lisp's metaprogramming facilities allow it to effectively simulate pretty much every other style of programming, the only explanation that I can come up with for this situation is that intuitive syntax matters a lot (at least for language adoption).

seanmcdirmid 9y ago
Macros aren't so much syntax as they are semantics (inlined for performance, but we can still think of them as special procedure calls). Lisp has been relatively successful in its various forms, it should get some credit.
- lispm 9y ago
  Macros serve lots of purposes. One is providing convenient syntax. (loop for i from 10 below 100 step 3 when (evenp i) collect i) Above is using the LOOP macro, which implements a lot of syntax for various ways to LOOP. The syntax description is actually quite long: See the EBNF description of the LOOP macro in the standard: http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm#loop http://www.lispworks.com/documentation/HyperSpec/Body/m_loop... There are other syntactic forms which use more parentheses. For example the DEFCLASS macro. The basic EBNF syntax for DEFCLASS is: defclass class-name ({superclass-name}*) ({slot-specifier}*) [[class-option]] slot-specifier::= slot-name | (slot-name [[slot-option]]) slot-name::= symbol slot-option::= {:reader reader-function-name}* | {:writer writer-function-name}* | {:accessor reader-function-name}* | {:allocation allocation-type} | {:initarg initarg-name}* | {:initform form} | {:type type-specifier} | {:documentation string} function-name::= {symbol | (setf symbol)} class-option::= (:default-initargs . initarg-list) | (:documentation string) | (:metaclass class-name) The DEFCLASS macro implementation will check some of that automatically, but much of the syntax has to be check by the macro in the implementation code. > we can still think of them as special procedure calls That's not a good idea. It's misleading.
TeMPOraL 9y ago
> the only explanation that I can come up with for this situation is that intuitive syntax matters a lot (at least for language adoption) Where intuitive is, as always, defined as "things I've seen before". Which makes the argument boil down to "popular things are similar to other popular things". Currently the two most popular types of syntax are C-like (C++, Java, C#, JavaScript, etc.) and Python-like (Ruby, Elixir, etc.). Prolog suffered from the AI Winter similarly to Lisp, and thus Prolog-like languages (e.g. Erlang) still get complains about their "arcane syntax", just like Lisps.

seanmcdirmid 9y ago

Macros aren't so much syntax as they are semantics (inlined for performance, but we can still think of them as special procedure calls). Lisp has been relatively successful in its various forms, it should get some credit.

lispm 9y ago
Macros serve lots of purposes. One is providing convenient syntax. (loop for i from 10 below 100 step 3 when (evenp i) collect i) Above is using the LOOP macro, which implements a lot of syntax for various ways to LOOP. The syntax description is actually quite long: See the EBNF description of the LOOP macro in the standard: http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm#loop http://www.lispworks.com/documentation/HyperSpec/Body/m_loop... There are other syntactic forms which use more parentheses. For example the DEFCLASS macro. The basic EBNF syntax for DEFCLASS is: defclass class-name ({superclass-name}*) ({slot-specifier}*) [[class-option]] slot-specifier::= slot-name | (slot-name [[slot-option]]) slot-name::= symbol slot-option::= {:reader reader-function-name}* | {:writer writer-function-name}* | {:accessor reader-function-name}* | {:allocation allocation-type} | {:initarg initarg-name}* | {:initform form} | {:type type-specifier} | {:documentation string} function-name::= {symbol | (setf symbol)} class-option::= (:default-initargs . initarg-list) | (:documentation string) | (:metaclass class-name) The DEFCLASS macro implementation will check some of that automatically, but much of the syntax has to be check by the macro in the implementation code. > we can still think of them as special procedure calls That's not a good idea. It's misleading.

TeMPOraL 9y ago

> the only explanation that I can come up with for this situation is that intuitive syntax matters a lot (at least for language adoption) Where intuitive is, as always, defined as "things I've seen before". Which makes the argument boil down to "popular things are similar to other popular things". Currently the two most popular types of syntax are C-like (C++, Java, C#, JavaScript, etc.) and Python-like (Ruby, Elixir, etc.). Prolog suffered from the AI Winter similarly to Lisp, and thus Prolog-like languages (e.g. Erlang) still get complains about their "arcane syntax", just like Lisps.