4 ms·

I'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. S

by arh68 12y ago

I'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 ago
Okay, 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.
- arh68 12y ago
  :D thank you for posting You seem to have laid it all out exactly, your attention to detail exceeding mine. What you've been saying is exactly how it works in Common Lisp. Again, I do appreciate you explaining the specifics here, so let me just ramble why I think you're right and I still think "Lisp has no syntax". I did not take a Compilers course, but I call em like I see em. proceed at your own boredom I guess my real problem is that I can't write down the line between syntax in Lisp and semantics. Many things are mere consequences of particular implementations, so I'll just list 3 scenarios. SBCL could, ostensibly, update IF to be a compiler macro (defined with, say, COND). Gasp, I know. Would that break any code? Or would it just break the ANSI standard? Speed aside, how much does it matter? SBCL could also change IF so the true & false parts are swapped. A criminally stupid move, sure. Then it's definitely not Common Lisp anymore. They'd've changed the calling convention. Note that the lexer wouldn't change at all, just the parser (pretend there's a separate lexer/parser, even though popular Lisps are all self-hosting). This seems to me a change in semantics, though I understand why one might argue it's a change in syntax. SBCL could also do a third stupid thing: change IF so the test-case is wrapped with square braces, like (if [> 2 3] x y). This would be a major change, of course, and it wouldn't be Common Lisp. But the reader could be rewritten to handle the new characters and all the source code could be changed. This would definitely change the syntax. Note that the lexer needs tweaking, but the parser remains exactly the same (you don't even need new tokens). If the syntax changes, the lexer changes. If the semantics change, the parser changes. The interface between the lexer and the parser is the List. Presumably, one could write a Lisp program in & a runtime for JSON lists instead of sexp lists, but I fail to see the benefit. Sexps are nearly the Ur-language for lists, unless you aren't trying to be a subset of ASCII (e.g. binary encodings). C-style arrays are no fun: ----main.lisp {"defun", "factorial", {"n"}, {"if", {">", "n", 0"}, {"*", "n", etc}, {etc}}} What a terrible syntax on such a beautiful semantics. Anyhow I've been thinking about Lisp a lot today, and now my brain is kinda tired, so I'm going to go take my dogs for a walk. Thanks for the thought-provoking discussion.. :)

by arh68 12y ago

lispm 12y ago

Okay, 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.

arh68 12y ago
:D thank you for posting You seem to have laid it all out exactly, your attention to detail exceeding mine. What you've been saying is exactly how it works in Common Lisp. Again, I do appreciate you explaining the specifics here, so let me just ramble why I think you're right and I still think "Lisp has no syntax". I did not take a Compilers course, but I call em like I see em. proceed at your own boredom I guess my real problem is that I can't write down the line between syntax in Lisp and semantics. Many things are mere consequences of particular implementations, so I'll just list 3 scenarios. SBCL could, ostensibly, update IF to be a compiler macro (defined with, say, COND). Gasp, I know. Would that break any code? Or would it just break the ANSI standard? Speed aside, how much does it matter? SBCL could also change IF so the true & false parts are swapped. A criminally stupid move, sure. Then it's definitely not Common Lisp anymore. They'd've changed the calling convention. Note that the lexer wouldn't change at all, just the parser (pretend there's a separate lexer/parser, even though popular Lisps are all self-hosting). This seems to me a change in semantics, though I understand why one might argue it's a change in syntax. SBCL could also do a third stupid thing: change IF so the test-case is wrapped with square braces, like (if [> 2 3] x y). This would be a major change, of course, and it wouldn't be Common Lisp. But the reader could be rewritten to handle the new characters and all the source code could be changed. This would definitely change the syntax. Note that the lexer needs tweaking, but the parser remains exactly the same (you don't even need new tokens). If the syntax changes, the lexer changes. If the semantics change, the parser changes. The interface between the lexer and the parser is the List. Presumably, one could write a Lisp program in & a runtime for JSON lists instead of sexp lists, but I fail to see the benefit. Sexps are nearly the Ur-language for lists, unless you aren't trying to be a subset of ASCII (e.g. binary encodings). C-style arrays are no fun: ----main.lisp {"defun", "factorial", {"n"}, {"if", {">", "n", 0"}, {"*", "n", etc}, {etc}}} What a terrible syntax on such a beautiful semantics. Anyhow I've been thinking about Lisp a lot today, and now my brain is kinda tired, so I'm going to go take my dogs for a walk. Thanks for the thought-provoking discussion.. :)