5 ms·

> S-expressions are both an internal representation and an external textual format. Lists will be parsed into cons cell trees. But at that point - the "interna

by e12e 9y ago

> S-expressions are both an internal representation and an external textual format. Lists will be parsed into cons cell trees. But at that point - the "internal" and "external" s-expressions are no tighter coupled than say Smalltalk syntax and binary representation. And I think (again, subjective) that s-expressions as a user-facing, textual syntax, might be good for some subset of problems - but I don't really see the benefit of forcing all users to work at the level of a compiler internal representation - the simplicity is somewhat artificial and superficial. I guess I think we can do much better than "smart typewriter" as a way to interact with executable data.

lispm 9y ago
> But at that point - the "internal" and "external" s-expressions are no tighter coupled than say Smalltalk syntax and binary representation. Less. S-expressions are not a representation for Lisp syntax. They are a data format. Lisp syntax is defined on top of s-expressions. We can enter an s-expression and Lisp will execute it. Here it is actually an interpreter, which walks the s-expression structure according to the evaluation rules. CL-USER 47 > ((lambda (a b) (+ (expt a 2) (expt a 2))) 10 (* 20 3)) 200 We can also compute the same expression: CL-USER 48 > (list (list 'lambda '(a b) '(+ (expt a 2) (expt a 2))) 10 (list '* (* 10 2) (+ 1 2))) ((LAMBDA (A B) (+ (EXPT A 2) (EXPT A 2))) 10 (* 20 3)) We can then let Lisp run that computed expression. Note that I refer to the expression over a variable (Lisp sets * to the last value) . It is data, not text. CL-USER 49 > (eval *) 200 > s-expressions as a user-facing, textual syntax Lisp does not use s-expressions as a user-facing, textual syntax. It uses s-expressions as a user-facing textual representation for a data syntax. The Lisp syntax is defined as a data syntax. For example the function call form is: function args* Thus we can compute lists which have a function name at the first place and the correct number of arguments follow: CL-USER 55 > (describe (list 'member ''pi ''(pi 3.14))) (MEMBER (QUOTE PI) (QUOTE (PI 3.14))) is a LIST 0 MEMBER 1 (QUOTE PI) 2 (QUOTE (PI 3.14)) The same data can be evaluated CL-USER 56 > (eval (list 'member ''pi ''(pi 3.14))) (PI 3.14) We can also enter it as text: CL-USER 57 > (MEMBER (QUOTE PI) (QUOTE (PI 3.14))) (PI 3.14) You simply can't compute code like that in Smalltalk. > I guess I think we can do much better than "smart typewriter" as a way to interact with executable data. The interface provided by Lisp is way different from Smalltalk and opens up a fully new perspective: computing of code.
- e12e 9y ago
  >> I guess I think we can do much better than "smart typewriter" as a way to interact with executable data. > The interface provided by Lisp is way different from Smalltalk and opens up a fully new perspective: computing of code. I suppose my point is that the s-expressions are an illusion - it's been a powerful tool to let people see you can, as you say "compute code", which I see as a proxy for "compute logic" (where "code" is a string, and logic is executable). Perhaps we'll have to agree to disagree - but I think the surface syntax allow "logic" to masquerade as "text representation" - while really being opaque binary streams - and that little is gained by holding on to them on general principle. Not nothing; they certainly remain a useful representation - but like lisp shows with prefix and infix notation (quote and dot/pair) - there's really not that to be gained by such ungainly syntax.
  - lispm 9y ago
    What we gain is easy, powerful and fluid manipulation of data and code in something like a ReadEvalPrintLoop.

by e12e 9y ago

lispm 9y ago

> But at that point - the "internal" and "external" s-expressions are no tighter coupled than say Smalltalk syntax and binary representation. Less. S-expressions are not a representation for Lisp syntax. They are a data format. Lisp syntax is defined on top of s-expressions. We can enter an s-expression and Lisp will execute it. Here it is actually an interpreter, which walks the s-expression structure according to the evaluation rules. CL-USER 47 > ((lambda (a b) (+ (expt a 2) (expt a 2))) 10 (* 20 3)) 200 We can also compute the same expression: CL-USER 48 > (list (list 'lambda '(a b) '(+ (expt a 2) (expt a 2))) 10 (list '* (* 10 2) (+ 1 2))) ((LAMBDA (A B) (+ (EXPT A 2) (EXPT A 2))) 10 (* 20 3)) We can then let Lisp run that computed expression. Note that I refer to the expression over a variable (Lisp sets * to the last value) . It is data, not text. CL-USER 49 > (eval *) 200 > s-expressions as a user-facing, textual syntax Lisp does not use s-expressions as a user-facing, textual syntax. It uses s-expressions as a user-facing textual representation for a data syntax. The Lisp syntax is defined as a data syntax. For example the function call form is: function args* Thus we can compute lists which have a function name at the first place and the correct number of arguments follow: CL-USER 55 > (describe (list 'member ''pi ''(pi 3.14))) (MEMBER (QUOTE PI) (QUOTE (PI 3.14))) is a LIST 0 MEMBER 1 (QUOTE PI) 2 (QUOTE (PI 3.14)) The same data can be evaluated CL-USER 56 > (eval (list 'member ''pi ''(pi 3.14))) (PI 3.14) We can also enter it as text: CL-USER 57 > (MEMBER (QUOTE PI) (QUOTE (PI 3.14))) (PI 3.14) You simply can't compute code like that in Smalltalk. > I guess I think we can do much better than "smart typewriter" as a way to interact with executable data. The interface provided by Lisp is way different from Smalltalk and opens up a fully new perspective: computing of code.

e12e 9y ago
>> I guess I think we can do much better than "smart typewriter" as a way to interact with executable data. > The interface provided by Lisp is way different from Smalltalk and opens up a fully new perspective: computing of code. I suppose my point is that the s-expressions are an illusion - it's been a powerful tool to let people see you can, as you say "compute code", which I see as a proxy for "compute logic" (where "code" is a string, and logic is executable). Perhaps we'll have to agree to disagree - but I think the surface syntax allow "logic" to masquerade as "text representation" - while really being opaque binary streams - and that little is gained by holding on to them on general principle. Not nothing; they certainly remain a useful representation - but like lisp shows with prefix and infix notation (quote and dot/pair) - there's really not that to be gained by such ungainly syntax.
- lispm 9y ago
  What we gain is easy, powerful and fluid manipulation of data and code in something like a ReadEvalPrintLoop.