My thought is that the confusion is most people are taught that lisp has no syntax. And that they should avoid the reader macro at all costs. Few, then, actually dive into large programs in lisp to see how real programs actually look.
In this example, though, what was the advantage of the special syntax? (I'm assuming there was one. Just a lot of these parallel hash tables written in literal form?)
Which is wrong. It's just that Lisp syntax looks and works a bit different. Especially there is a data syntax for s-expressions and the syntax for the programming language Lisp is defined on top of s-expressions.
> And that they should avoid the reader macro at all costs.
Common Lisp itself uses read macros for its implementation. Applications use them in various ways.
> In this example, though, what was the advantage of the special syntax?
Xappings were a central data structure in Connection Machine Lisp, thus it's not unusual that it had a printed representation.
Agreed on your points. Especially that it has syntax. But look at the linked post upthread. I said "no" syntax, but that was me being admittedly lazy. Quote there was "Lisp is a language with little syntax". Which has me wondering why it has that general view with everyone.
For the representation.. So this was not simply a literal syntax, but a serialization one. Which makes sense. And I can see why the serialization syntax is easily usable as a literal one.
GCC's C parser is a 550 kilobyte file that is almost 19000 lines long. The C++ one is over 1.1 megabytes long, and close to 39,000 lines. Github refuses to display it as code, only raw.
Since many/most Lisp macros implement syntax, there can be a lot of syntax in Lisp, too. The parsing of the syntax is distributed over the macro definitions, sometimes with some help of the general macro mechanism.
See for example the syntax which is implemented by macros like LOOP or ITERATE. The LOOP syntax is documented in the ANSI CL spec...
Macros do not have to deal with syntax at the level of "how does this sequence of tokens reshape into a tree". (Not usually; exceptions are easily contrived and exist in the wild.)
Usually, the syntax is already parsed when it comes into a macro.
E,g:
(sentence-macro subject object verb)
sentence-macro doesn't have guess what part of the utterance is the object and which is the verb. The verb is the third argument, and that is that. This is the case whether it is a single word, or a phrase.
Though this is still syntax, it is parsed syntax.
When we say that Lisp has no syntax, it means that it dosen't have that silly, counterproductive stuff naively imitated from natural languages which represents the tree in a way that requires mind-bending work to recover.
You should probably check out the LOOP macro sometime. Examples include:
(loop for i from 0 to 10
for j from 10 downto 0
collect (cons i j))
That is a fully legit expression. So, if you consider LOOP contrived, then you have a point. It is a very useful and a very powerful macro, though. Not sure why it wouldn't count.
LOOP does speak to what you can do with macros. Obviously, a macro can interpret its arguments however it wants. You can implement a language that requires GLR (or worse).
LOOP is also not universally loved in the Lisp world. It's fine if you don't need to extend it. Not only is it inherently inextensible (for no good reason), but it's hostile to wrapping. If you write a MYLOOP macro which passes most of its arguments to LOOP and adds a few clauses of its own (translated to LOOP syntax), you have to parse the LOOP syntax to see where your clauses are and in which order in relation to the standard ones. (Unless you do something hacky or ugly, like recognize your extensions by some delimiters, without regard for the surrounding syntax, so that they don't actually blend in.)
LOOP is the only high level control construct I've ever seen anywhere in which you can achieve nonportable behaviors: because of the construct itself, not because of nonportable expressions plugged into it.
The treatment of clause symbols as character strings, so that CL:FOR and MYPACKAGE:FOR can both head off a for clause is a design smell. LOOP should have been designed to use symbols in the CL package, so that if someone wants to use APPENDING, they nicely import that symbol or pick it up via :use.
LOOP asks you to use different syntax for walking a vector and list, when the rest of Lisp has a sequences library that lets you use common functions for both. Supporting the specialized syntax is fine (just like the library also has list and vector specific things), but the lack of a generic sequence iterating clause shows a discord with the rest of the language. It didn't require much imagination to have, say a FOR x OVER <list-string-or-vec>.
We can have a perfectly good Lisp dialect without any sort of mini-language parsing macro like LOOP. It illustrates what you can do with macros, not what is usually done with macros. Macros usually leverage their tree structure and destructuring not to do any parsing work, and focus on the transformation and its semantics.
I mostly agree without, except that custom destructuring and code walking do not imply parsing.
Destructuring is just how we access the tree (already parsed object). Sometimes the tree isn too complicated for the simple destructuirng performed by destructuring macro lambda lists, so we have to do things like walk substructures and apply DESTRUCTURING-BIND or use some pattern matching library or whatever. Example: just because I I have some MAPCAR over a list of variable-init pairs (qualifies as "custom destructuring") doesn't mean I'm parsing syntax that hasn't been parsed. I'm just destructuring a syntax tree that hasn't been destructured. Destructuring isn't parsing. Destructuring is not even mentioned in papers and textbooks on compilers; it falls into the bucket of somehow walking the tree, which falls under semantic analysis.
Code walking is ultimately done to the expansion of every macro. COMPILE and EVAL perform code walking. No textbook on compilers will refer to code walks over an AST as part of the parsing stage.
Of course the point is valid that Lisp macros sometimes take a flat list of items and apply recursive phrase structure rules to recover a tree (or small subtree, as the case may be). This is rare, and basically a last resort device; if you're doing that, you're writinig some sort of "big deal" macro. Instances of it are rare in Common Lisp, and I don't suspect it is done frequently in Lisp programs. It's great that wan do that. It's also great that because of the way the langauge works, we can accomplish a lot without having to do that.
Speaking of ITERATE, its parsing of clauses is trivial, because it uses Lispy syntax. Dealing with (for var = expr) versus (for var initially expr then expr) versus (for var first expr then expr) is "quasi parsing". OK, we have a FOR. What isn the third item? Switch on a bunch of cases: =, INITIALLY, FIRST, .... If it's unrecognized, then signal an error. In each of these cases, certain things are fixed by position in the syntax already. This is "parsing" only in the sense that Unix people refer to simple trivial line argument processing as "parsing". (Only a few utils do actual parsing or a recursive grammar, examples being find and tcpdump.)
> Macros do not have to deal with syntax at the level of "how does this sequence of tokens reshape into a tree"
That's not syntax. Syntax is concerned whether a sequence of words are valid expressions in a language and determines syntactic categories for these. You can lookup a better definition of syntax, I'm too lazy.
These are all DEFUN forms. Some are valid Lisp, some are not.
(defun foo () ()) is valid
(defun () foo ()) is invalid
(defun () () foo) is invalid
(defun (foo) () foo) is invalid
(defun foo () foo) is valid
(defun () foo foo) is invalid
(defun foo foo ()) is invalid
(defun (setf foo) (setf foo) foo) is valid
(defun foo (setf foo) (setf foo)) is invalid
(defun (setf foo) foo (setf foo)) is invalid
Just by changing the order of subforms in a macro form we can produce valid Lisp and invalid Lisp forms.
(defmacro defun (name args &body forms) ...)
Does not tell you that. You need to implement that logic in the macro somewhere.
> sentence-macro doesn't have guess what part of the utterance is the object and which is the verb. The verb is the third argument, and that is that.
Macros implement more complex syntax. Check the ANSI CL specification and its EBNF syntax declarations some time.
> When we say that Lisp has no syntax
Then it's just wrong and misleading.
Take the DEFUN macro:
the EBNF (extended backus naur form) syntax definition for DEFUN is:
The macro has to check that. It better rejects invalid expressions. It also has to look at the elements of the form to destructure them in the right way, so that it can process them and create a new valid form.
The Lisp implementation provides for the implementation of DEFUN as much as:
(defmacro defun (spec args &body body ...) ...)
The macro language does not allow further specifications of the name the arglist or the body in the macro interface. All it gets are spec, args and body. Now the macro has to implement the syntax for spec, args and body.
Questions the macro has to answer:
* is the function name a symbol or a list of the form (setf foo)
* is the arglist a valid lambda-list? Now check the EBNF syntax for lambda lists with whole/optional/key/rest options with default values and what have you.
* now it has to parse the body:
* is the declaration valid? Now check the EBNF syntax for declarations to see what needs to be done.
* is the documentation a string at the right position?
* is the body a sequence of forms? Now check the EBNF syntax for FORM.
This all has to be backed into the DEFUN macro somehow or checked from there.
And not all implementations are good at it.
Various syntax errors:
The name is not valid:
CL-USER 14 > (defun (foo bar) baz (list))
Error: (FOO BAR) is neither of type SYMBOL nor a list of the form (SETF SYMBOL).
1 (abort) Return to level 0.
2 Return to top loop level 0.
If you think that's bad, just representing C++, not even parsing it, in Clang, takes 61K lines of headers!
If you look at these files it's mostly declarations and one-line functions. It's not even doing anything. The lexers and parsers are a whole other story, certainly greater than 19K lines combined.
But that is a different claim, isn't it? I would expect that the general parser for a CL implementation is also quite large.
My question is why does the teaching often go that there is practically no syntax for lisp. Now, it is often followed quickly with "in lisp, you can write your own language."
But then, those two thoughts are hard to justify next to each other. Again, just see this thread. The complaint is that there is not enough syntax in lisp. The argument appearing that you have to have another language to express some ideas. And again, I'm not even disagreeing with this claim. Just trying to understand why it has the foothold that it does. That you drop to lisp if you want to use no syntax.
Just checked an old clisp-2.32 source tree I have laying around on an old hard drive. The raw line count in the src/ directory over all .d and .lisp files is 212K. Compiler, CLOS, all in there. The io.d module (preprocessed C source) which contains the reader and printer, plus some other cruft, is 10K.
Lisp was using [] and {} before in a lot of software.
For example this is a data structure in Connection Machine Lisp called Xapping, basically a parallel hash table:
Straight from the 80s.Scheme was using [] also many years before in the standard, programs and books.