3 ms·

> These are all things that can be done with (a) rich editor(s) with access to the ast - see things like Colorforth and most Sure, see what I wrote. It just le

by lispm 9y ago

> These are all things that can be done with (a) rich editor(s) with access to the ast - see things like Colorforth and most Sure, see what I wrote. It just less easy/basic to use. > Smalltalks Quite a bit complex and much more different to use. Just compare Xerox' Interlisp-D with their Smalltalk 80. Smalltalk 80 usage is very different from Interlisp-D. > I also think most of these points fall into the "code is data" ide That was my point. Lisp s-expressions are used in Lisp not just because one can implement macros with them. > The fact that you have to choose between not being able to represent text (ascii) and a variable length encoding, also makes s-expressions less appealing today, than it once was. It's not clear to me what you mean with that. Can you give an example?

e12e 9y ago
>> I also think most of these points fall into the "code is data" ide[a] > That was my point. Lisp s-expressions are used in Lisp not just because one can implement macros with them. Right, and I held up macros as an example of manipulating the ast. I may be wrong, but for many types of data, you would not typically use s-expressions - other than as an intermediary representation - your sql is "compiled" to binary datastructures, as are your images - and the machine won't be "running" s-expressions directly either. I think acknowledging the complex nature of our systems can be a benefit - and insisting on a simplistic abstraction can do the users (programmers) a disservice. >> The fact that you have to choose between not being able to represent text (ascii) and a variable length encoding, also makes s-expressions less appealing today, than it once was. > It's not clear to me what you mean with that. Can you give an example? Ascii can't represent international text - but is a simple encoding to work with. We've pretty much landed on a complex (by necessity) representation: variable length Unicode with support for different reading directions. While a the high-level the parsing rules are similar "give me the parenthesis-like grapheme, parse numbers based on various local representations" - Unicode s-expressions aren't really simple any more - they are opaque binary streams that need parsing into reasonable abstract syntax tree-structures. Even utf32 doesn't really change this. And I think languages like nim (or even to a degree python) show that such structures can be made pleasant, intuitive and powerful to work with. And doesn't limit us arbitrarily to simple symbolic data (eg the unpleasantness to work with a megapixel bitmap represented as s-expressions) - and helps lift our minds from "we can/should force everything to be text", to we should be able to work with our code and data in many representations, accepting the underlying tree structure - and (subjectively, obviously) I think that on the program/dsl/logic side, s-expressions are less human-friendly than something more like python. It's one important reason why many of us don't prefer s-expressions for pseudo code.
- deleted 9y ago
  - 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.

by lispm 9y ago

e12e 9y ago

>> I also think most of these points fall into the "code is data" ide[a] > That was my point. Lisp s-expressions are used in Lisp not just because one can implement macros with them. Right, and I held up macros as an example of manipulating the ast. I may be wrong, but for many types of data, you would not typically use s-expressions - other than as an intermediary representation - your sql is "compiled" to binary datastructures, as are your images - and the machine won't be "running" s-expressions directly either. I think acknowledging the complex nature of our systems can be a benefit - and insisting on a simplistic abstraction can do the users (programmers) a disservice. >> The fact that you have to choose between not being able to represent text (ascii) and a variable length encoding, also makes s-expressions less appealing today, than it once was. > It's not clear to me what you mean with that. Can you give an example? Ascii can't represent international text - but is a simple encoding to work with. We've pretty much landed on a complex (by necessity) representation: variable length Unicode with support for different reading directions. While a the high-level the parsing rules are similar "give me the parenthesis-like grapheme, parse numbers based on various local representations" - Unicode s-expressions aren't really simple any more - they are opaque binary streams that need parsing into reasonable abstract syntax tree-structures. Even utf32 doesn't really change this. And I think languages like nim (or even to a degree python) show that such structures can be made pleasant, intuitive and powerful to work with. And doesn't limit us arbitrarily to simple symbolic data (eg the unpleasantness to work with a megapixel bitmap represented as s-expressions) - and helps lift our minds from "we can/should force everything to be text", to we should be able to work with our code and data in many representations, accepting the underlying tree structure - and (subjectively, obviously) I think that on the program/dsl/logic side, s-expressions are less human-friendly than something more like python. It's one important reason why many of us don't prefer s-expressions for pseudo code.

deleted 9y ago
- 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.