4 ms·

> while what you really need need for what? > is a good way to manipulate the ast (for good/easy macro support). S-expressions were not initially used in Lis

by lispm 9y ago

> while what you really need need for what? > is a good way to manipulate the ast (for good/easy macro support). S-expressions were not initially used in Lisp because of macros. Actually the early Lisp had no macros, but s-expressions. They were used as a syntax and representation for lists and tree-like data. s-expressions were first used as a data representation and people had to use it, because programs were represented as s-expressions. The programs were written as m-expressions in some algebraic notation, but had to be translated to s-expressions to be executed by Lisp. The expectation was that s-expressions were only an implementation detail and programmers were then using some other syntax for their programs. There were some larger efforts to design a successor to Lisp 1.5 (called Lisp 2) with such a syntax and have that as the default/main Lisp dialect. Eventually this project was cancelled. http://www.softwarepreservation.org/projects/LISP/lisp2_family/ http://www.softwarepreservation.org/projects/LISP/lisp2_fami... The advantages of s-expressions in the context of Lisp were/are: * not dependent on line-based data entry and not sensitive to whitespace * one could easily feed code as s-expressions to a interpreter, this could be a Lisp interpreter, or an interpreter for some other language using s-expressions. * the parsing/scanning/printing/formatting of s-expressions is reusable in different contexts. this can be done with or without knowing the contents of s-expressions. One can easily format s-expressions based on general rules, but one can also write special purpose code formatter for Lisp. Lisp has this built-in with the pretty-printer. * generally writing code transformations (not just Lisp macros) is a bit easier with richer data structures than strings. For example write a bunch of rules using s-expression and transform/interpret them. Thus different interpreters/compilers can be easily written, not just a Lisp interpreter/compiler. * interactive manipulation of s-expressions and s-expression-based code is relatively easy. This helps a lot with REPL-style programming. Marking (sub-)expressions, transposing them, replacing/moving them, then gets relatively easy. You'll get a poor-man's syntax directed editing very easy. If you want in an IDE make a Java-expression available broken up into its subexpressions, one has to use a much more complicated parser, which then has very detailed knowledge about the language - which is both and good. With s-expressions you still get some structure editing, while on that level there is very little commitment about the syntax of the actual contents (is it a Lisp program? Is it a bunch of rules for a firewall? is it a list of diagnosis rules?). Syntax-directed editing is available in many tools, but rarely is it as interactive and basic as in Lisp with s-expression syntax, which is also very robust against accidentally reformatting (omitted newlines, added whitespace, ...). Enter an s-expression and its always easy to reconstruct the visual structure. Since (sub-)expressions are delimited left and right with characters ( and ), it's always clear where it starts and ends when displayed or read. With a syntax with less visual structure or one which needs to be reconstructed with a parser, this is much more difficult and less intuitive to use.

e12e 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 Smalltalks. The latter is of course the canonical example, where representing an array of numbers as a spreadsheet-like widget becomes natural and integrated. I also think most of these points fall into the "code is data" idea - and where text manipulation (reformatting, pretty printing) is somehow seen as free/easy - as opposed to working with an ast. My point is that s-expressions might be more simplistic, but not really that much simpler, than having access to the ast. 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.
- 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.

by lispm 9y ago

e12e 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 Smalltalks. The latter is of course the canonical example, where representing an array of numbers as a spreadsheet-like widget becomes natural and integrated. I also think most of these points fall into the "code is data" idea - and where text manipulation (reformatting, pretty printing) is somehow seen as free/easy - as opposed to working with an ast. My point is that s-expressions might be more simplistic, but not really that much simpler, than having access to the ast. 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.

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.