search

breck7 / scrollsdk

The code for Particles and Parsers, which Scroll is built on.
https://sdk.scroll.pub
383 stars 17 forks source link

Add the most compelling demos of why TreeNotation is better than Lisp to Readme, not the trivial examples #22

Closed breck7 closed 5 years ago

breck7 commented 5 years ago

Ideally we'd have 3 gifs, one for each of these scenarios.

jmiskovic commented 5 years ago

I'm a bit confused even by this trivial example of lisp code.

*
 + 1 1
 + 2 2

In this example the * element is extracted from s-expression and promoted to tree root. My understanding of s-expressions is that all elements (atoms or other s-expressions) inside any s-expressions are treated equally. This should be necessary property of homo-iconic syntax.

To me it seems that only lisp interpreter should be responsible for recognizing first element as function and other elements as parameters. If you are already doing this in input source notation I feel you will run into use cases the tree notation won't be able to support.

For example, a macro takes code as input and generates code as output. When code is presented to programmer in this way, (s)he would have to be aware that first element of expression is actually the parent of other elements. This is not ideal for good interworking with existing lisp implementations.

The other issue is that the * operation is done with explicit child elements, while + operations have elements inline. Wouldn't it be more consistent and easier for manipulation if all s-expressions were made to be explicit?

breck7 commented 5 years ago

In this example the * element is extracted from s-expression and promoted to tree root.

Thank you for mentioning this. I don't think we've been clear about the terms here. The tree root is actually anonymous. The * is the first child of the Tree root.

The other issue is that the * operation is done with explicit child elements, while + operations have elements inline. Wouldn't it be more consistent and easier for manipulation if all s-expressions were made to be explicit?

This is a very good observation. In practice of designing Tree Languages, I have definitely seen the case where you want to only allow inline content or only allow child content (for nodeTypes that take a block of text, definitely only take child content. Makes life much easier for compiler writer). However, there are a few cases where it is very nice to allow inline content AND child content.

The Stump demo language for example, allows you to do things like putting attributes as children and content inline:

h1 hello world
textarea some value
 readonly

It's up to the Tree Language designer. In this Lispy sort of example, I allow either.

breck7 commented 5 years ago

This new issue is the place for better examples:

https://github.com/treenotation/jtree/issues/60