Two Thoughts on Lisp Syntax.

;                     1. Lisp has syntax
; It is frequently said that Lisp has no syntax. It is simplification:
; there is a syntax, just it is relatively simple and uniform,
; compared to other languages. For example, look at these two
; expressions:
                         (setq x 3 y 4)
                       (setq (x 3) (y 4))
; It is easy to imagine that these two expressions have same semantics,
; and that difference is purely syntactic. Even if we use some formal
; definition of syntax. For example, Wikipedia defines syntax as
;      "set of rules that defines the combinations of symbols
;       that are considered to be correctly structured programs
;       in that language."
;                    2. Which syntax is better?
; If code is written by programmer, then it is slightly easier
; to use (setq x 3 y 4) form. But if code is generated by program,
; then form (setq (x 3) (y 4)) is more suitable. For example, the
; function that extract variables from the setq expression in the
; form (setq x 3 y 4) might look like

   (define (setq-places s)
           (let((counter 0)
                (result '()))
               (dolist(i s)
                  (inc counter)
                  (when (even? counter)
                        (push i result -1))) ; push on the right side

; It is very simple, but verbose code. If I have luck and my Lisp
; supports some  suitable functions, it might be even simpler. However,
; it appears that it is always simpler to extract the variables
; from the form (setq (x 3) (y 4)):

        (define (setq-places s)
                (map first (rest s)))

; So, I'd say that overall, form (setq (x 3) (y 4)) is better.



  1. though, this form (setq (x 3) (y 4)) kinda breaks a semantic inconsistency with the rest of lisp, because in general the first syntactical element in (a b c d ...) is a operator.

    in the (setq (x 3) (y 4)) case, the x and y isn't operator. I can't think of a similar example in lisp right now.

  2. a typo i made above.

    should be: ... kinda breaks a syntax-semantic correspondence consistency, ...

  3. never mind. Actually you have some examples in your code above.