3 ms·

> The ability to create syntax comes at a cost and the existence of so many other programming languages shows one thing very clearly: not everyone is willing to

> The ability to create syntax comes at a cost and the existence of so many other programming languages shows one thing very clearly: not everyone is willing to pay that cost. The cost of Lisp is that the syntax is all the same. So a conditional looks the same as an assignment statement, looks the same as a function call, looks the same as a plus operator. Lisp syntax is bad, because many humans find it easier to scan source code if different constructs use different syntax (whether that is just because it is what they are used to, I don't know). But Lisp syntax is also good, because it allows macros. You could get round this problem by having two levels of a language, one with C-like syntax which compiles to Lisp-like syntax (which may itself be compiled). So this: if (a>b) c := foo(d); Might compile to this: (if (> a b) (:= c (foo d)))

jules 17y ago
Sexps are better than strings because they are more structured. It would be even better to represent code with separate data types for every construct instead of the relatively unstructured sexps.
- stcredzero 17y ago
  Just having a special delimiter for code blocks helps tremendously. If you stop there, and don't add more syntax, you're just about at Smalltalk.
- lispm 17y ago
  s-expressions are an external syntax. You can create any data structure you want from them, given the right reader. S-expressions are not INTERNAL to Lisp, only external. Thus s-expressions are defined on characters. Comparing s-expressions to strings makes no sense. The representation of code is a different issue. You could read an s-expression and represent it internally as a string.
lispm 17y ago
No, Lisp syntax is not all the same. 'if' has the syntax if test-form then-form [else-form] 'cond' has the syntax cond {clause}* => result* clause::= (test-form form*) 'case' has the syntax case keyform {normal-clause}* [otherwise-clause] => result* normal-clause::= (keys form*) otherwise-clause::= ({otherwise | t} form*) LOOP has a full page of syntax. http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm#loop http://www.lispworks.com/documentation/HyperSpec/Body/m_loop... What you think has 'no' syntax, is the syntax for s-expressions. S expressions are relatively trivial, but not every s-expression is a valid Lisp form. S-expressions are a syntax for DATA. The syntax of Lisp, the programming language, is described on top of s-expressions. Syntax is concerned with the structure of valid expressions of a language. So you have an additional layer of syntax which describes, on top of s-expressions, the syntax of Lisp. There is some basic syntax: * data like numbers, strings are valid Lisp programs * function calls are valid Lisp programs. Function calls have a non-trivial syntax with rest, optional and keyword args, lambda functions, ... * special forms like CATCH, FLET, IF, QUOTE, SETQ, ... all have their defined syntax * macro calls, here the macro has to implement the syntax specified in the standard. users can do with their macros what they want. For example (if (foo-p) (this) (that) (these)) is a syntax error, though it is a valid S-expression. Similar (loop for i below 10 (print i)) is also wrong. Correct would be for example (loop for i below 10 do (print i)) So, what you may want is to remove the data syntax (s-expressions) from Lisp and replace it with some other layer of syntax that is not based on prefix parentheses-heavy s-expressions. There are lots of languages that have different syntactical approaches. Lisp has its own, which makes it slightly unusual (the syntax is used to support the code-is-data paradigm), less popular, but also makes sure that it will find its users - those users who want a language with a flexible syntax (one that can be extended by the developer) on top of a simple data syntax.
gruseom 17y ago
People have been doing this for as long as Lisp has existed; the idea "we'll just use these s-expressions until we figure out the real syntax" goes back to the very beginning. If this were really a major issue, something would have been figured out by now. Instead, it's an idea that has great appeal to dilettantes but has never caught on with practitioners. Surely there is a reason for that?
lmkg 17y ago
I don't have much experience reading Lisp, but I think that some structures do stand out. The difference is that you look at the shape of code chunks rather than special characters on a line. For example, LET blocks with lots of assignments stand out to me because of the chunk of pairs at the top. DO blocks look similar but the increment functions separate them. LOOP stands out for having a lot of symbols and not many parentheses. Aside from that, some lisps have tendencies (although not requirements) that symbols with common uses have special characters to stand out more. For example, foo for dynamic variables, +foo+ for globals, foo! for destructive operations (in scheme), foo? for predicates (scheme + clojure), and = for assignment (in arc). The choice of what to emphasize is different, but it was a conscious choice on the part of the language creators.

jules 17y ago

Sexps are better than strings because they are more structured. It would be even better to represent code with separate data types for every construct instead of the relatively unstructured sexps.

stcredzero 17y ago
Just having a special delimiter for code blocks helps tremendously. If you stop there, and don't add more syntax, you're just about at Smalltalk.
lispm 17y ago
s-expressions are an external syntax. You can create any data structure you want from them, given the right reader. S-expressions are not INTERNAL to Lisp, only external. Thus s-expressions are defined on characters. Comparing s-expressions to strings makes no sense. The representation of code is a different issue. You could read an s-expression and represent it internally as a string.

lispm 17y ago

No, Lisp syntax is not all the same. 'if' has the syntax if test-form then-form [else-form] 'cond' has the syntax cond {clause}* => result* clause::= (test-form form*) 'case' has the syntax case keyform {normal-clause}* [otherwise-clause] => result* normal-clause::= (keys form*) otherwise-clause::= ({otherwise | t} form*) LOOP has a full page of syntax. http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm#loop http://www.lispworks.com/documentation/HyperSpec/Body/m_loop... What you think has 'no' syntax, is the syntax for s-expressions. S expressions are relatively trivial, but not every s-expression is a valid Lisp form. S-expressions are a syntax for DATA. The syntax of Lisp, the programming language, is described on top of s-expressions. Syntax is concerned with the structure of valid expressions of a language. So you have an additional layer of syntax which describes, on top of s-expressions, the syntax of Lisp. There is some basic syntax: * data like numbers, strings are valid Lisp programs * function calls are valid Lisp programs. Function calls have a non-trivial syntax with rest, optional and keyword args, lambda functions, ... * special forms like CATCH, FLET, IF, QUOTE, SETQ, ... all have their defined syntax * macro calls, here the macro has to implement the syntax specified in the standard. users can do with their macros what they want. For example (if (foo-p) (this) (that) (these)) is a syntax error, though it is a valid S-expression. Similar (loop for i below 10 (print i)) is also wrong. Correct would be for example (loop for i below 10 do (print i)) So, what you may want is to remove the data syntax (s-expressions) from Lisp and replace it with some other layer of syntax that is not based on prefix parentheses-heavy s-expressions. There are lots of languages that have different syntactical approaches. Lisp has its own, which makes it slightly unusual (the syntax is used to support the code-is-data paradigm), less popular, but also makes sure that it will find its users - those users who want a language with a flexible syntax (one that can be extended by the developer) on top of a simple data syntax.

gruseom 17y ago

People have been doing this for as long as Lisp has existed; the idea "we'll just use these s-expressions until we figure out the real syntax" goes back to the very beginning. If this were really a major issue, something would have been figured out by now. Instead, it's an idea that has great appeal to dilettantes but has never caught on with practitioners. Surely there is a reason for that?

lmkg 17y ago

I don't have much experience reading Lisp, but I think that some structures do stand out. The difference is that you look at the shape of code chunks rather than special characters on a line. For example, LET blocks with lots of assignments stand out to me because of the chunk of pairs at the top. DO blocks look similar but the increment functions separate them. LOOP stands out for having a lot of symbols and not many parentheses. Aside from that, some lisps have tendencies (although not requirements) that symbols with common uses have special characters to stand out more. For example, foo for dynamic variables, +foo+ for globals, foo! for destructive operations (in scheme), foo? for predicates (scheme + clojure), and = for assignment (in arc). The choice of what to emphasize is different, but it was a conscious choice on the part of the language creators.