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.
> 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?
>> 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.
> 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.
S-expressions are both an internal representation and an external textual format. Lists will be parsed into cons cell trees.
See the longer example below. There is nothing which prevents me working with structures/records and arrays as s-expression based text.
There is also nothing which prevents us from providing alternative displays of those, which are not printed as text, but as mixed text and graphics, or graphics only.
In text I would typically give the data symbol names, but in a graphic display I might display them as images.
Symbolics did add a presentation-based user interface for their Lisp Machine operating system with the release of Genera 7.0 in 1987, where the I/O can be done over rich streams and where the system remembers the complete correspondence between graphical display things and the underlying data. Thus the user interacts with various representations (called presentations) of the data. For example, if one has a list of musical notes, you could interact with them as symbolic notes, or as a graphical display of notes.
Typically I would store larger images outside of text files (either in binary Lisp files called fasls or in special image files), but for some purposes it might be okay. For example if my application needs some icons I can store them directly in textual code as s-expressions.
Note also that some Lisp applications use textual s-expressions with serialized data, but those files are not supposed to be edited with a text editor, but with some other tools.
There is also no reason that Lisp could not use Unicode (or other encodings) in s-expressions...
> 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.
> 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))
>> 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.
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.