4 ms·
Lisp... doesn't really have syntax. S-expressions have syntax: parens, whitespace, symbols, comments. S-expressions are for data. Lisp is a subset of the sex
by arh68 12y ago
Lisp... doesn't really have syntax. S-expressions have syntax: parens, whitespace, symbols, comments. S-expressions are for data. Lisp is a subset of the sexps.
Lisp adds just one rule: a Lisp program is an sexp whose root node is a function symbol.
Naturally, since sexps nest, Lisp programs can nest.
The author demonstrates nested computation with bash's $( .. ) syntax. Lisp, by the nature of the sexps, is nested computations. I think the author almost hits the nail on the head here:
> Our two basic rules — program-name-first and $()-for-composition — allowed us to explicitly specify the order of evaluation, so there was no need to do any fancy parsing beyond what the shell already provides.
Sexps provide nesting/composition. Lisp just means program-name-first.
- lispm 12y ago> Lisp adds just one rule: a Lisp program is an sexp whose root node is a function symbol. Now you explain these three examples. All have a symbol at the start of the list. * (let foo bar) ; in: LET FOO ; (LET FOO ; BAR) ; ; caught ERROR: ; Malformed LET bindings: FOO. ; ; compilation unit finished ; caught 1 ERROR condition * (lambda a b) ; in: LAMBDA A ; (LAMBDA A B) ; ; caught ERROR: ; The lambda expression has a missing or non-list lambda list: ; (LAMBDA A B) * (defun foo (a) (+ a 10) (declare (fixnum a)) ) ; in: DEFUN FOO ; (DECLARE (FIXNUM A)) ; ; caught WARNING: ; There is no function named DECLARE. References to DECLARE in some contexts ; (like starts of blocks) have special meaning, but here it would have to be a ; function, and that shouldn't be right. Obviously the SYNTAX for LET, LAMBDA, DEFUN, ... is more complex than what you think. Looks like there is Lisp code where it is not sufficient to have a symbol at the start of an s-expression. There seem to be more constraints to the allowed s-expressions. For example the syntax for LET is: let ({var | (var [init-form])}*) declaration* form*
- arh68 12y agoYeah you're right, it's not turtles/functions all the way down. At some point, your functions are defined in terms of special forms. Your special forms will either be natively supported or they'll be written with a defmacro in terms of native special forms. The definitions can't be circular, of course: if defmacro was used to define if, then if cannot be used in the definition of defmacro. So my "rule" isn't really a hard rule. Macros/forms are the exception. But it seems more intuitive for me to think in terms of functions whenever possible, then to bend the rule when macros get involved.
- lispm 12y agoNo, Lisp has a set of built-in special forms with their specific syntax. In many Lisps (incl. Common Lisp), there is no way to write new special forms for the user. Macros are not for implementing special forms. > Macros/forms are the exception. Common Lisp has around 30 special forms and many more macros. Some with a special complex syntax, like LOOP. Programming Lisp with only function call syntax is practically impossible. LAMBDA, DEFUN, ... are already having additional syntax.
- arh68 12y agoI'm being loose with my terminology. I guess that was a mistake. Look, I don't even know what we're arguing over. Here's some words from CLtL2: 5.1.3. Special Forms ... An implementation is free to implement as a macro any construct described herein as a special form. Conversely, an implementation is free to implement as a special form any construct described herein as a macro if an equivalent macro definition is also provided. The practical consequence is that the predicates macro-function and special-form-p may both be true of the same symbol. It is recommended that a program-analyzing program process a form that is a list whose car is a symbol as follows: 1) If the program has particular knowledge about the symbol, process the form using special-purpose code. All of the symbols listed in table 5-1 should fall into this category. 2) Otherwise, if macro-function is true of the symbol, apply either macroexpand or macroexpand-1, as appropriate, to the entire form and then start over. 3) Otherwise, assume it is a function call.
- lispm 12y agoOkay, I'll explain that in detail: > Yeah you're right, it's not turtles/functions all the way down. At some point, your functions are defined in terms of special forms. Functions are defined in terms of special operators, built-in functions, user-level functions, built-in macros, user-level macros and data. > Your special forms will either be natively supported or they'll be written with a defmacro in terms of native special forms. DEFMACRO can't define special operators. It can only define macros. Common Lisp lacks the facility to define special operators. > The definitions can't be circular, of course: if defmacro was used to define if, IF is a built-in special operator. No macro. > then if cannot be used in the definition of defmacro. Generally it could. Macros can be recursive, for example. > So my "rule" isn't really a hard rule. Macros/forms are the exception. But it seems more intuitive for me to think in terms of functions whenever possible, then to bend the rule when macros get involved. Macros and special forms are everywhere in Lisp.
- cwp 12y ago> Lisp... doesn't really have syntax. Yes, it really does. Let me finish that chain of reasoning for you: S-expressions have syntax. Lisp is a subset of the sexps. Therefore, Lisp has syntax. QED Yes, Lisp has very simple syntax. Yes, it's neat that eval can be implemented in a few dozen lines of Lisp. But as a practical matter Lisp is a programming language like any other. This sort of mysticism does not encourage people to learn Lisp or help the ideas behind Lisp become more mainstream.
- AnimalMuppet 12y agoI believe that arh68's point was that Lisp doesn't have a syntax that is something different than the syntax of S-expressions. You're actually agreeing, but you're quibbling over the way it was stated.