|
|
|
|
|
by kazinator
2458 days ago
|
|
Note that deciphering type tag info in a Lisp value can be called "parsing". Cases occur: for some values we have to chase a pointer into a heap to get more type info. A Lisp function call does "parsing". (foo 1 2 3) has to figure out dynamically whether a (lambda (&rest args)) is being called or (lambda (a b c)) or (lambda (a b &optional c (d 42)) or whatever. The #S(employee id 1 salary 95000) object also isn't an employee record without context and interpretation. > it needs to know where declarations are and where the code body ist The syntax can be subject to a fairly trivial canonicalizing pass, after which all these things are at fixed positions: (let ((a 3) b) (foo a)) ---canon--> (let ((a 3) (b)) (declare) (foo a))
Now the variables are all pairs to which we can blindly apply car and cadr, the declarations are at caddr and the body forms at cdddr. |
|
No. You are still operating on the level of s-expressions, a data format. The type-tag of LET is SYMBOL.
Here we have some Lisp code in the form of an s-expression:
All above LET have the same type tag, but in terms of syntax they have a different purpose in the form above: we have special operators, variable declarations, variable usage, data objects. I can't just car/cdr down the lists and call TYPE-OF. This always returns SYMBOL for LET.On the level of a syntax tree we would want to know what it is in terms of syntactic categories: variable, operator, data object, function, macro, etc. Lisp source code has no representation for that and we need to determine that by parsing the code.