Good references, thanks. I took a fresh look at CGOL and was again impressed.
> Because Lisp is not about 'parens',
Exactly, so why keep them around?
When you ditch the parens, things become easier. You no longer start your programs with a syntax error. You no longer even have syntax errors. Program concatenation is easier. Dictation of programs is easier: you speak "add 2 3" instead of "open parens add 2 3 close parens". Program synthesis is easier....
> A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group
All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.
Because Lisp source code is written in a data-structure using nested lists and nested lists are written as s-expressions with parentheses. The same Lisp code can be executed by an s-expression-based interpreter.
> When you ditch the parens
Again, the parens are not what Lisp is about, it is the nested lists as source code: internally and externally. It just happens that the lists are written with ( and ).
What you propose is essentially not just getting rid of 'parens', but dropping the source code idea based on explicit list representation.
> , things become easier.
Code generation, manipulation and transformation becomes harder.
> You no longer even have syntax errors.
How so?
> Program concatenation is easier.
How so? Lisp actually makes many forms of source code transformations easy.
> All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.
But then we no longer have the 'Lisp code is explicitly written in a list-based data structure' idea, which is very powerful and still relatively simple.
Language with syntax based on textual representations already exist many and there is a place for a programming language which works slightly differently.
It's possible to drop the explicit s-expression syntax, as has been demonstrated many times over history, but then the has a different look and feel. It becomes something different then and loses basic Lisp features or makes them considerable harder to use.
One can say 'why keep the wheels around'? We can do that, but either the car won't drive very well or one would transform it into something else: a boat, a plane, a sled, .. It would lose its 'car nature'.
> What you propose is essentially not just getting rid of 'parens', but dropping the source code idea based on explicit list representation.
No, I keep the nested list representation of data (as does I-Expressions: https://srfi.schemers.org/srfi-49/srfi-49.html), you just ditch the enclosing parens in favor of whitespace (or, to be more precise, in favor of 3 syntactic tokens: atomBreakSymbol, nodeBreakSymbol and edgeSymbol; by convention space/" ", newline/"\n", and space/" ").
>> You no longer even have syntax errors.
>How so?
See for yourself: https://jtree.treenotation.org/designer/. Try to generate a syntax error, it's impossible. For the same reason you don't have syntax errors at the binary notation. I think this is a very, very important hint that there is something important going on here that ties into something in nature (I don't know what that is but seems like there is a fancy prize to the person who can explain that in mathy terms). However, using the openParenSymbol and closeParenSymbol style of delimiters, you do have syntax errors--unbalanced parens.
>> Program concatenation is easier.
> How so?
This one is mildly easier, but comes up all the time. We have a Tree Language called Grammar for building other Tree Languages (and yes, Grammar itself has an implementation in Grammar). We have a Tree Language called Hakon that compiles to CSS. And we have one called Stump that compiles to HTML. Want to build a new language called "TreeML" that has both? Just `cat hakon.grammar > treeml.grammar; cat stump.grammar >> treeml.grammar` and you are just about done (just concat your new root node). You don't have to worry about adjusting any parens at the tails. A minor improvement, but lots of little things like that add up.
> but then the has a different look and feel. It becomes something different
This might be true. It seems you are taking the stand that Tree Notation is something different than Lisp (which I actually lean to agreeing with), while most lispers have given me the flippant response "congratulations! you've reinvented lisp/s-expressions". I think both arguments have merit. We will see where it goes and perhaps although the differences with parens S-Expressions are slight, perhaps there will always be a separate niche for parens lisp.
That's not an EXPLICIT list representation, where the nesting is notated by explicit characters.
It's also harder to use in interactive interfaces like REPLs, debuggers, etc., where Lisp lists don't need to have vertical layout.
> you do have syntax errors--unbalanced parens.
if you use a structure editor for Lisp you don't have unbalanced parentheses. In editors with support for s-expressions, unbalanced parentheses are basically not an issue.
> cat hakon.grammar
Yeah, Lisp works very differently. It does not use grammars like that. Lisp uses procedures in readtables to read s-expressions. Parsing the code is then done by the evaluator traversing the source or by the compiler traversing the source, with an integrated source code transformation phase (macro expansion).
We load a bunch of macros into Lisp and they then are available incrementally.
There are syntax-based structure editors (for example they were in Interlisp-D), but they always have limits, since macros can do arbitrary source transformations on s-expressions and those are not based on grammars.
You are really looking for a very different language experience. Lisp with s-expressions works very different from what you propose.
That's why I say: it's not about dropping parentheses, you propose to get rid of some of the core parts of Lisp (how programs are represented, parsed, etc.) and give it a different user interface. That's fine, but it is no longer Lisp like we know it.
Other syntaxes and IDEs for those have been done several times in Lisp-based language implementation. For example the Sk8 multimedia development tool from Apple had implemented something like AppleScript on top of Lisp. The multimedia applications were implemented in an AppleScript like language (actually it was kind of the first AppleScript implementation) with an IDE for that - implemented in Lisp.
The original dream of Lisp was to have algol-like M-Expressions and use s-expressions only for data inside M-expressions. But the internals of Lisp were implemented with s-expressions and M-expressions were manually translated into s-expressions. Breaking into a Lisp execution and looking into the interpreter state then revealed the s-expression representation of code to the developer.
> That's fine, but it is no longer Lisp like we know it.
I think this is fine, and now I can direct future commenters who tell me we've just "reinvented lisp" to your thread.
Really helpful links, and I am looking forward to watching that youtube video later this week when I have a moment. Thanks so much for all the information.
> Because Lisp is not about 'parens',
Exactly, so why keep them around?
When you ditch the parens, things become easier. You no longer start your programs with a syntax error. You no longer even have syntax errors. Program concatenation is easier. Dictation of programs is easier: you speak "add 2 3" instead of "open parens add 2 3 close parens". Program synthesis is easier....
> A Lisp without s-expression-based syntax is not a main Lisp and will form a new language group
All I'm saying is put S-Expressions into normalized form (indented cleanly), drop the parens, and voila, everything can still work, and you've reduced things to their simplest form.