4 ms·

> There've been so many attempts at removing the parentheses from Lisp The best previous attempt IMO was Egil Möller's I-expressions in 2003 (https://srfi.sche

by breck 7y ago

> There've been so many attempts at removing the parentheses from Lisp The best previous attempt IMO was Egil Möller's I-expressions in 2003 (https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html). These Sweet-Expressions in the OP I think were a regression on I-Expressions. My attempt (~2013-present) is called Tree Notation. http://treenotation.org/ http://treenotation.org/. This is the first time that we've got S-Expressions without parentheses and are using that for tremendous benefit (better concatenation, easy ad hoc parsers, visual programming and program synthesis being some of the main benefits). Here are a few sample languages: http://treenotation.org/sandbox/build/ http://treenotation.org/sandbox/build/ > but they've never taken off. It's going to happen finally with Tree Notation. We're starting to see strong network effects at last. The missing ingredient was strong tooling/design/and tools that leverage the lack of parentheses to huge benefit.

singularity2001 7y ago
Beautiful. OP claims to be backwards compatible with Clisp, that's not a goal of yours, right? So a list in treenotation would be written: list a 1 2 3 4 ? Could become a bit verbose at times, or does treenotation have a mechanism for tables like data={ header:['brand','make','price], rows:[ ['mercedes','X1',1000] , ['porsche','Z7',2000], ] } are triples always parsed like this: ? description A package (description (A package)) vs ((description A) package) Does treenotation differentiate between strings and data/ints?
- breck 7y ago
  > OP claims to be backwards compatible with Clisp, that's not a goal of yours, right? Correct, not a goal of mine. If someone wanted to create a Tree Language that compiles to CLisp, they could define it in our Grammar Language (http://treenotation.org/sandbox/build/ http://treenotation.org/sandbox/build/ -- you write your grammar on the left, and source code in your new language on the right). > So a list in treenotation would be written: list a 1 2 3 4 The base spec for Tree Notation is very simple. YI = "\n" // New lines separate nodes XI = " " // Increasing indent to denote parent/child relationship interface TreeNode { parent: &TreeNode children: TreeNode[] line: string } In practice, we generally break "line" into "words: string[]". So you can represent atoms in a list as either words or nodes, depending on how you design your Tree Language. > Could become a bit verbose at times, or does treenotation have a mechanism for tables like Sort of. We have a software coming out called TreeBase that is a plain text, git backed database that stores records in Tree Notation. In there we have Tree Languages for dealing with SSV/TSV/CSV/etc tables. I'm not 100% happy with the current implementation--going to be putting pattern matching into our Tree Grammar Language which might solve it--but I bet within a month or two we'll have a great solution for that with strong type checking, etc. > Does treenotation differentiate between strings and data/ints? The base Tree notation is very simple, as the spec above shows. But we created a Tree Language, built upon Tree Notation, wherein you write grammars to create new languages. In those grammar files you can define ints, strings, arrays, etc. The link above has examples with all of those.
didibus 7y ago
What's the difference with pareinfer? https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ It seems mostly similar, except you hide the parenthesis inference.
- breck 7y ago
  It's a neat idea, and pareinfer just looks beautiful, but why even infer them at all if you don't need them? My long term plan is to get a lot of resources dedicated to this initiative, and even though I think it's possible you could accomplish the same thing with S-Expressions, I think it's simpler and cheaper by a significant amount to just drop the parens. I think the number of folks who are comfortable with parens (I'd count myself in that category) is a lot smaller than the folks who don't like parens or don't have a preference.
  - didibus 7y ago
    I think the advantage is backwards compatibility. I use pareinfer with Clojure and Emacs Lisp for example, though generally I'm more a fan of paredit. I did think of making an Emacs plugin that could hide the parens when using pareinfer. They'd still be in the code, say for others who choose to use a different editing style, but hidden to me. Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. I've also personally found the parens sometimes help with readability, indent can be hard to tell where the block starts and ends sometimes in deep nested scenarios which is more common in immutable expression only languages. Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. Pareinfer suffer from this issue as well. But I'm biased, I like the parens and love S-expressions. I'm one of those who started like everyone else hating them, trying to look for alternatives, but one month later of using Clojure at work it all changed, my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I even find myself writing other language with S-expressions by accident. I often put the parenthesis before the method by accident now when going back to Java for example.
    - 7y ago

by breck 7y ago

singularity2001 7y ago

Beautiful. OP claims to be backwards compatible with Clisp, that's not a goal of yours, right? So a list in treenotation would be written: list a 1 2 3 4 ? Could become a bit verbose at times, or does treenotation have a mechanism for tables like data={ header:['brand','make','price], rows:[ ['mercedes','X1',1000] , ['porsche','Z7',2000], ] } are triples always parsed like this: ? description A package (description (A package)) vs ((description A) package) Does treenotation differentiate between strings and data/ints?

breck 7y ago
> OP claims to be backwards compatible with Clisp, that's not a goal of yours, right? Correct, not a goal of mine. If someone wanted to create a Tree Language that compiles to CLisp, they could define it in our Grammar Language (http://treenotation.org/sandbox/build/ http://treenotation.org/sandbox/build/ -- you write your grammar on the left, and source code in your new language on the right). > So a list in treenotation would be written: list a 1 2 3 4 The base spec for Tree Notation is very simple. YI = "\n" // New lines separate nodes XI = " " // Increasing indent to denote parent/child relationship interface TreeNode { parent: &TreeNode children: TreeNode[] line: string } In practice, we generally break "line" into "words: string[]". So you can represent atoms in a list as either words or nodes, depending on how you design your Tree Language. > Could become a bit verbose at times, or does treenotation have a mechanism for tables like Sort of. We have a software coming out called TreeBase that is a plain text, git backed database that stores records in Tree Notation. In there we have Tree Languages for dealing with SSV/TSV/CSV/etc tables. I'm not 100% happy with the current implementation--going to be putting pattern matching into our Tree Grammar Language which might solve it--but I bet within a month or two we'll have a great solution for that with strong type checking, etc. > Does treenotation differentiate between strings and data/ints? The base Tree notation is very simple, as the spec above shows. But we created a Tree Language, built upon Tree Notation, wherein you write grammars to create new languages. In those grammar files you can define ints, strings, arrays, etc. The link above has examples with all of those.

didibus 7y ago

What's the difference with pareinfer? https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ It seems mostly similar, except you hide the parenthesis inference.

breck 7y ago
It's a neat idea, and pareinfer just looks beautiful, but why even infer them at all if you don't need them? My long term plan is to get a lot of resources dedicated to this initiative, and even though I think it's possible you could accomplish the same thing with S-Expressions, I think it's simpler and cheaper by a significant amount to just drop the parens. I think the number of folks who are comfortable with parens (I'd count myself in that category) is a lot smaller than the folks who don't like parens or don't have a preference.
- didibus 7y ago
  I think the advantage is backwards compatibility. I use pareinfer with Clojure and Emacs Lisp for example, though generally I'm more a fan of paredit. I did think of making an Emacs plugin that could hide the parens when using pareinfer. They'd still be in the code, say for others who choose to use a different editing style, but hidden to me. Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. I've also personally found the parens sometimes help with readability, indent can be hard to tell where the block starts and ends sometimes in deep nested scenarios which is more common in immutable expression only languages. Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. Pareinfer suffer from this issue as well. But I'm biased, I like the parens and love S-expressions. I'm one of those who started like everyone else hating them, trying to look for alternatives, but one month later of using Clojure at work it all changed, my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I even find myself writing other language with S-expressions by accident. I often put the parenthesis before the method by accident now when going back to Java for example.
  - 7y ago