Historical Counterparts? about ohayo

[breck7]

I don't have any notes on Lush so may be the first time I've seen it but I think but it seems to be mostly similar to standard Lisp notation with parens.

YAML uses a bit of whitespace for structure but also uses a fair amount of visible syntax and adds too much to the base layer IMO.

Rebol is definitely an influence--I believe strongly in dialecting (what I call Tree Languages).

I'm unfamiliar with Klone. Do you have a link? Are you referring to this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.545.601&rep=rep1&type=pdf? If so very interesting, but is there a notation somewhere?

Egil's SRFI-49 is the closest thing that I've seen to Tree Notation. I was unaware of SRFI-49 until a few months ago, but was very excited to see it. I think it's fair to say Egil's program in 49 is the first true program I've seen in a Tree Language. There are some differences between his specification and mine, but they are 80%+ the same. I think 101 and other syntaxes moved away from the conceptual soundness of 49 (and Tree Notation).

The first paper is quite weak on data. It's really more of an announcement of the general theory.

The second paper is an early draft which I hope to expand out as the compiler-compiler and grammar notation evolve.

My basic thesis is this: I believe our current languages, all using BNF grammars, are filled with noise (unnecessary syntax characters), and more than that, harmful noise (the complex syntax makes parsing and building static tools harder than it should be and makes communication harder across languages). I think we don't need any syntax characters -> no parens, no brackets, no quotes, no colons, et cetera. And in the long run we'd be better off without them. I think the rules of Tree Notation (words, lines/nodes, edges), are all we need.

So I'm trying to design and build non-BNF, Tree Notation based languages and tools that serve as alternatives to BNF languages.

It is still not quite obvious how it will all work. I've learned there are many bad ways to design a Tree Language just as there are many bad ways to design a BNF language. But slowly better patterns are emerging and the tooling is improving. We now have a grammar notation, compiler-compiler, and strongly typed languages--things we didn't have a few months ago, and all added without adding any syntax characters.

So there is a lot of progress but still some technical and design challenges to overcome.

[lojikil]

So Lush is the precedent to Clojure, Klone, and other lisps with deeply-nested data structures that also feature reader syntax in the default installation. The interesting thing about Lush is that data structures self-eval (like in clojure); there were some earlier Lisps that did this for a limited range of data structures, but Lush was the first to support it across structures (as far as I can tell).

Wrt Klone, it's an array-based lisp from france (iirc). There is very little documentation on it, but it had some interesting performance features. I'm thinking about lisps with alternative storage mechanisms; most lispers know that cons-cells are 1-ary trees, that's where I'm going with this, if you follow.

I think this is an intriguing notion; SRFI-10, Common Lisp #. syntax, and Rebol being obvious interesting notations. As a heavy schemer, I've written quite a bit with sweet expressions (another form of SRFI-49), and honestly they can also become awkward with large programs, due to a lack of visual breakup of syntax.

Honestly, if I may suggest something, look at what colorForth did with mixing color/syntactic highlighting with a language that minimizes symbols. It's one of the few attempts at "less syntax, more information!" I've seen that actually worked as intended for larger programs. I think it puts more onus on the tool designer than you're looking to do, but it also put less on the user (in this case, a developer). Also, as I mentioned in the first post, TreeSheets & his newer language Restructor may also be useful guidance. Term rewriting languages such as Refal may also be of some guidance here, tho obviously they don't minimize syntax, but they could provide a neat method of graph rewriting.

Also, have you looked at N3 and Turtle?

[breck7]

Ah, thanks for the context about Lush.

most lispers know that cons-cells are 1-ary trees, that's where I'm going with this, if you follow.

I believe I follow. In effect all Tree Programs can also be looked at as I-Expressions (which are just S-Expressions with indent sensitive syntax instead of parens).

As a heavy schemer, I've written quite a bit with sweet expressions (another form of SRFI-49), and honestly they can also become awkward with large programs, due to a lack of visual breakup of syntax.

This is very interesting to me, thanks. I am not sure how Tree Languages will scale so will be interesting to look at larger code bases in Sweet Expressions or I-Expressions. Do you have any links to some projects with lots of files written in Sweet Expressions? I tried a search on GitHub(https://github.com/search?utf8=%E2%9C%93&q=or+extension%3Asscm&type=Code) but only was able to find a dozen or so files. I also reached out to David to see if he might have some links. That also gave me the idea to ask Emil if he had links to an I-Expressions corpus (as for I-Expressions I couldn't find a file extension).

I reread the Sweet Expressions docs and glad I did. Very delightful. I have struggled a lot with infix notation and how to add it in a way that requires no extra syntax. Rereading the Sweet Expressions docs gave me a new idea to try. Something along the lines of this:

program:
x = 2 + 4 + 8

grammar:
assignment
 @parameters op* int*

I've developed the practice of having at most 1 list (all words of the same type) per line, and feel any more than that will lead to multiple trees of variable length per line (which breaks a lot of otherwise safe assumptions for tool developers). That seemed to rule out infix. However the Sweet Expressions docs re-inspired me to take another look (they made a good case for the usability of infix) and I think there may be a way to do it that works well with 1 list, where instead of a list of words it's a list of tuples (of 2 types). But then of course it still doesn't solve the operator precedence problems or grouping...But I digress.

Honestly, if I may suggest something, look at what colorForth did with mixing color/syntactic highlighting with a language that minimizes symbols. It's one of the few attempts at "less syntax, more information!" I've seen that actually worked as intended for larger programs. I think it puts more onus on the tool designer than you're looking to do, but it also put less on the user (in this case, a developer)

This is definitely the path I am going. You can see color highlighting now on http://ohayo.computer (Use shift+t to toggle the theme, I haven't yet gotten around to actually making the colors all readable for every theme). Or here's a screenshot (the language in the screenshot is terrible btw, but it was an early Tree Language) to give an idea. Each word in a Tree Program has a type (well, currently I have a lot of "anys", but eventually should have more specific types in most languages) and types are different colored fonts.

But color alone isn't the only UI aid that can be added. I like the term "Projectional Editing" (https://martinfowler.com/bliki/ProjectionalEditing.html). Perhaps it might even help if an editor showed brackets and quotes, without them actually being present in the source code. A main principle of Tree Notation is to not add anything to the actual base notation in order that parsing any Tree Program will always be easy (so will always be easy for tool developers).

I had looked at TreeSheets before but I unfortunately never downloaded it until today. Very cool! Creating a new document in TreeSheets is exactly like how I write Tree Programs on paper (I write words in cells on graph paper). But it has the nice ability to grow the cells when you run out of room (on graph paper I just have to make do). Navigating a document is also fast and data entry is very fast. Thanks for mentioning it again. Perhaps I'll look at the source and see about adding import/export of Tree Notation documents, as they would map nicely to this UI.

I have looked at Refal before but not Restructor.

I had not looked at n3 or Turtle. IMO I have no idea why they would add all those horrible syntax characters as they are completely unnecessary :).

Very help information and interesting references. Thanks!

[lojikil]

I believe I follow. In effect all Tree Programs can also be looked at as I-Expressions (which are just S-Expressions with indent sensitive syntax instead of parens).

Sure, or like D-Expressions in Dylan, which at times & depending on the Dylan system supported both Algol-like & S-Expression-like syntaxes.

Do you have any links to some projects with lots of files written in Sweet Expressions?

They were widely panned by the Scheme community, and as far as I'm aware not much was really written in them. I will say that SRFI-110 has an experience report that you might find useful.

I've developed the practice of having at most 1 list (all words of the same type) per line, and feel any more than that will lead to multiple trees of variable length per line

I'd probably do this ala Rebol dialects, like an infix-expression dialect and a pre-fix expression dialect. Can parse trees produce & consume parse trees (as in, are Tree-expressions homoiconic)? If so, either answer is relatively straight forward, just add a syntax-rules or whatever that consumes it.

This is definitely the path I am going. You can see color highlighting now on

Ah, I see. I didn't know if the compiler/lexer attached semantic significance to it or not. Is it a multi-namespace language? It could be interesting to see how something is used in various positions and how they are colored as such.

I like the term "Projectional Editing"

Yep, it's an interesting idea, also stops bikeshedding on indentation formatting & the like.

Perhaps I'll look at the source and see about adding import/export of Tree Notation documents, as they would map nicely to this UI.

I think your projectional editing would be great here; mix & match visual representations, and how they are linearized on disk is not really important, like how Smalltalk worked.

I had not looked at n3 or Turtle. IMO I have no idea why they would add all those horrible syntax characters as they are completely unnecessary :).

Well… some of us have written large programs in XML syntax (one of my largest is a Schematron to XSL compiler written in XSLT), so Turtle is certainly a lot smaller than writing XML by hand. Personally, I prefer FLWOR expressions from XQuery, which also have an XQueryX XML representation.

Very help information and interesting references. Thanks!

for sure, I'm happy to. I think as I've gotten older I've had less care about how something is represented and more that everyone can consume it in a representation that they prefer...