To anybody dabbling as I do in syntax design, who may be looking for an extremely minimal representation for trees (even more minimal than S-exprs!) I would like to introduce my little project called Jevko: https://djedr.github.io/posts/jevko-2022-02-22.html
It is pure distilled treeness. Its grammar fits into one line, if compressed well:
This took me years of syntax golfing to figure out. I think it's turned out pretty nice. It's complete, formally defined, with a few simple parsers written, except it has no users. ;D
To relate back to the article, an interesting and AFAIK original feature of this syntax is that newlines or other whitespace are neither significant nor insignificant nor "possibly significant" in Jevko. I'd call it whitespace-agnostic. Various whitespace rules can be laid on top of it, producing for example a Lisp-like language with native multiword identifiers with spaces, e.g.:
For a long time I couldn't find the right name that would express the generic nature of it.
An earlier prototype was called TAO, as an acronym for Tree Annotation Operator (it had an extra feature called operators), and as a reference to the ancient Chinese concept, in essence nameless and by design hard to pin down -- this seemed to fit perfectly.
However there is about 2^42 cowznofski potrzebie things called TAO (kind of ironic, as the original idea was that the Tao would be distinct from the countless named things), so it turned out to be a bad name after all. So I decided to find a more unique one and here we are.
The amount of time spent thinking about this and the lengths I went to are better left untold.
I just want to tell you that Jevko is quite a fun little language you've built. I just threw together a parser for it in TypeScript (I'll upload it to Github eventually haha). It was super easy. I'm going to recommend it to my friends who aren't as excited about parsers and things as me for an introduction to parsing programming languages.
Indeed, it's close. Obviously mine and Breck's levels of appreciation for indentation/brackets are very different. ;) Although independent, the paths we have taken to arrive at these are somewhat similar (somewhere early in there are experiments with visual programming). As are the tools of thought (minimalism). We were thus taken to similar places.
Before I was aware of the existence of Tree Notation I put my syntax online at tree-annotation.org (now defunct), so even naming converged. I was initially very confused myself. :D
Ultimately I think that the existence of multiple incarnations of this idea suggests that there is (perhaps a very niche) need for a minimal syntax like this. Something like S-exps, but general-purpose. Trying to satisfy that need is the common cause.
The way I imagine it is that it would be supported across programming languages, like JSON. It could be an universal format for (tree) structured data. There is this piece of the Unix philosophy which says that text streams are the universal interface. That's true on a certain level. On another level not far below binary streams are the universal interface. On another level not far above... there was nothing universal until XML. But that was overkill, so JSON displaced it. But that's still overkill, so...
Or serialize game objects in your indie game. Or make it the interface of your experimental app. Or use it to shave off a few unnecessary characters off your data: https://jevko.github.io/compactness.html
Sure. This is translated straight out of SICP 3.5.1[0]:
(define (sum-primes a b)
(accumulate +
0
(filter prime? (enumerate-interval a b))))
If you have an S-exp parser built into your optical nerve (to paraphrase L. Torvalds), it will be indeed hard to parse.
The translation rules for an S-exp are roughly:
1. switch to square brackets
2. surround all symbols except the first in brackets
3. move the first symbol outside the opening bracket
4. replace dashes in symbols with spaces
5. leading and trailing whitespace doesn't count into a symbol.
That's basically it.
Besides that indentation and closing brackets are written C-style rather than Lisp-style.
Now the real confusion might begin if you have an S-exp with an S-exp as the first element like:
((fnr) 1 2)
This would translate to:
fnr[][[1][2]]
which is... interesting.
Anyway, this is just a theoretical example to demonstrate the whitespace-agnosticism. I have not implemented this particular language. But it's one way to arrange these trees into a Lisp-like language, if one was so inclined.
The cool thing is the simplicity and identifiers with spaces. Not cool, besides unfamiliarity, is the verbosity compared to regular S-exps (more brackets).
To anybody dabbling as I do in syntax design, who may be looking for an extremely minimal representation for trees (even more minimal than S-exprs!) I would like to introduce my little project called Jevko: https://djedr.github.io/posts/jevko-2022-02-22.html
It is pure distilled treeness. Its grammar fits into one line, if compressed well:
This took me years of syntax golfing to figure out. I think it's turned out pretty nice. It's complete, formally defined, with a few simple parsers written, except it has no users. ;DTo relate back to the article, an interesting and AFAIK original feature of this syntax is that newlines or other whitespace are neither significant nor insignificant nor "possibly significant" in Jevko. I'd call it whitespace-agnostic. Various whitespace rules can be laid on top of it, producing for example a Lisp-like language with native multiword identifiers with spaces, e.g.:
here "sum primes" and "enumerate interval" are two double-word identifiers. It's the only right_solution to the identifierWars, I-tell-you!