David Piepgrass — There is no sound in the video. Here's the prior thread: https://futureofcoding.slack.com/archives/CCL5VVBAN/p1598502207080100

David Piepgrass To add to this: at the time I was exploring text editing and "outliner-adjacent" interfaces because I was starting to do more long-form writing for my job. I settled on working in Roam for now but I can see myself going back to this idea some day soon. Over the last few months I've been just building small "experimental" interfaces like this that I think could eventually evolve into a single cohesive system (or be "spun out" as general concepts like this). I really should start doing two minute week posts though...

David Piepgrass the final/full version is here if you’re interested https://arxiv.org/abs/2011.06171

Breck Yunits this is seriously cool work. congrats

Thanks Breck Yunits , your explanation helps a bit but also raises more questions. It makes perfect sense to have a grid in which each cell is the root of a tree, but I have no idea of how this would be expressed in textual tree notation. Is there a formal grammar somewhere?

Someone recently started a Kotlin library (https://github.com/justjake/ktree)

And someone a Go library (https://github.com/dpapathanasiou/go-tree-notation)

there is a "spec" here: https://github.com/treenotation/faq.treenotation.org/blob/master/spec.txt

But that could use a refresh to clarify and simplify it

Then is a Sandbox here (https://jtree.treenotation.org/sandbox/) where you can see a JSON serialization of the basic data structure

There are a few technical terms. "Grid Notation" is just a spreadsheet (and CSV and TSV could be are close to a serialization of grid notation)

You just new a column separate and row separator for that

Then when you add a 3rd special rule, an indent creates a parent/child relationship, you get tree notation

But you still don't have any types

or structures other than trees and

lists of words

So on top of those you can create

Tree Languages. Here is a Grammar

Language (simply called "Grammar")

Grammar is written in itself (https://jtree.treenotation.org/designer/#standard%20grammar)

Then there are a few higher level languages in there written in Grammar

So plenty of room to create higher level standards....an issue coming up now with people building tree libraries in other host languages is what would some standard "high level languages" look like.

No idea! Will have to wait to see what emerges

Thanks a lot Breck Yunits, I am making progress. The spec also helps a lot, but it also raises more questions. The TreeNode interface is clear enough as a building block for trees, but what about grids? I think that's the problem I have since the beginning: is a grid just an interpretation of a particular tree structure, as in the frequent representation of a 2D arrays as rows of 1D arrays? Or is a grid a distinct data structure from a tree? Put differently, in terms of syntax: is grid notation just syntactic sugar for a frequently used kind of tree, or syntax for a different data type? Again put differently: can a grid have semantics different from any tree-based semantics?

Good questions! Really helpful to see where the gaps are.

At the high level I view the big idea as "2-D Languages". (Well, 3-D

as well, but let's just limit ourselves to 2-D for the moment.)

I think of things all around me in the world as 2-D languages.

A Highway Sign for instance.

Once we get into the digital realm, with our current hardware

stack we do have to collapse things into 1-D, and that's

where "Grid Notation" and "Tree Notation" come in. Any document

could be parsed as either a Grid Structure or a Tree Structure. If

there are no nested nodes, then the structures would basically be the

same. If there are nested nodes, then in Tree Notation you would

parse child trees, whereas in Grid Notation the empty edge nodes

would just be parsed as empty cells. I rarely use pure "Grid Notation", but

I do sometimes use something in the middle, where sometimes I allow

nested trees and sometimes I don't. But really it's probably

better to just always use Tree Notation. Because even when I start a

lang small and think "I'm never going to need scopes with this

dumb config language", a few months later I'm always like "damn, scopes

would have been better and I shoudl have just used tree notation"

Honestly maybe it's confusing things more

than helping to talk about "Grid Notation" and "Tree Notation".

I just thought there's a nice pattern at work here:

Add 1 special symbol and you get a 1-d "List notation" that supports lists of words.

Add 1 more special symbol and you get a 2-d "grid notation" that supports lists of lists of words.

Add 1 more special symbol and you get a 3-d "tree notation" that supports recursive lists of lists of lists of words.

The COVID data explorer has been incredibly informative - I keep going back to it to look at new trends, to share views of the data with others and to smirk upon seeing that yes, Canada's COVID response remains so much better than the U.S.'s. I only wish it had more fine-grained information, e.g. breakdown by U.S. state - it's been in the news that Blue states had a larger economic downturn under COVID, but did they also do a better job controlling COVID? If OurWorldInData can't tell me, I don't know where else to turn!

Last time I read about "tree notation", it wasn't very compelling because you didn't explain some key things:

• If it's a "tree notation" then it should express trees, but instead it appears to be two dimensional, i.e. it expresses a grid, not a tree. If it's really a "tree notation" then how do you express a tree?
• If the cells are space-delimited, how do you express a space character inside a cell?
• How do you distinguish various data types from each other, e.g. how is the string 123 different from the number 123?

Edit: apologies to the extent I repeated ground already covered above... by the way, I looked at the "Sandbox" but it doesn't help much to answer these questions because (1) it doesn't include samples (except one), (2) there seem to be substantially different interpretations of the same tree notation, hence three different JSON conversions, which isn't terribly enlightening, (3) there is no reverse conversion from JSON (or XML) to Tree Notation.

Thanks David Piepgrass!

The next branch of OWID has

a new data TS/JS transformation

table lib under the hood so you can

do any kinds of data transformations

you want. We call it CoreTable

(https://github.com/owid/owid-grapher/tree/next/coreTable)

After we started that, Jeff Heer's lab

launched Arquero, which is an

awesome similar lib as well (https://observablehq.com/collection/@uwdata/arquero)

So once that goes live being able to

do any data transformation you want,

like state to state comparisons, or even

state to country compairions, or custom

on the fly groups, will bepossible

You'll also be able to do things

like group by policy response, etc

If it's a "tree notation" then it should express trees, but instead it appears to be two dimensional, i.e. it expresses a grid, not a tree. If it's really a "tree notation" then how do you express a tree?A single indent (similar to Python), creates a new child node

of the parent node

If the cells are space-delimited, how do you express a space character inside a cell?There are 3 special symbols. Generally

the node break/row break is always new line.

In the JTree lib the cell and edge symbols are a space.

But you can set those to whatever you want.

In OWID we use a tab instead, for better interop

with spreadsheet programs

There is no such thing as an "escape character"

We follow a different strategy. Basically you

choose your special symbols, and then you define

your higher level languages, so that you never

run into situations where you would have ambiguity

That isn't an obvious thing, and it takes a lot

of work to figure out all the edge cases, but it works.

Trust me have been trying to disprove that for 10 years

but it holds true

How do you distinguish various data types from each other, e.g. how is the string 123 different from the number 123?At the tree notation level there is no concept

of numbers. Those come at a higher "Tree

Language" level

there will likely be standard higher level

Tree Languages that coalesce

So, to be clear, it's impossible for a cell to hold "a string" (unrestricted character set), but you can have "a tree language" which would then define escape characters?

Correct, a

"cell" could not hold any of the special characters

In some web apps using tree notation,

you may see a pattern like this in the

query string: "?cellSymbol=~&doc=message~hello world"

in that case, it's saying to use "~" as the cell break

and then " " is a valid character in a cell

But then there are many more strategies

The basic approach though is to never have

the notion of escape characters

At the Tree Notation level

Andrew Carr thanks for reading ! I'm working on a workflow demo and will record one as soon as humanly possible 🙂

Tree-sitter is awesome... I was thinking that at some point I would try to figure out how I can take advantage of the tree-sitter parsers in order to translate almost any language into Loyc trees.

I'm not sure if I had seen Babelfish before, but I am immediately confused when I look at their "https://github.com/bblfsh/documentation/blob/master/uast/representation-v2.md" because the core concept it appears to be almost identical to JSON, so I can't guess what the UAST of Foo(2+2) might be. The Loyc tree of Foo(2+2) is, of course, normally expressed simply as Foo(2+2) which is a call to Foo with one argument, and a call to '+ with two arguments.

I also saw tree-hugger at some point - ahh yes I clapped for https://medium.com/codist-ai/introducing-tree-hugger-source-code-mining-for-human-b5fcd31bef55 - but I'm not sure if I can or should utilize it in some way, given that my codebase is stuck on .NET for the time being.

Yes tree-hugger does not support .NET as of yet. However, a contribution is more than welcome 🙂

Well, I'm afraid that despite devoting all my time to Loyc recently, I remain several years behind schedule. It is probable that I will write a Loyc tree library for Python before I get around to doing something involving tree-hugger + .NET.

A couple of days ago I sketched out something called BLES, which is a syntax for Loyc trees designed as an extension of JSON (and subset of LES2). In these grammar diagrams, the things BLES has in common with JSON are shown in black, while changes are shown in blue. It looks about twice as complex as JSON, but probably about one-quarter as complex as C. So this is something I could port to other languages more quickly than other versions of LES. There's also a https://github.com/qwertie/ecsharp/issues/104 but I'm not sure if that's useful to anyone.

Json encoding can be useful. There are nice tools to save and query JSON data

And sometimes they can really useful. For an example, although I like tree-sitter but I wanted to build tree-hugger on top of it, simply because I was tired to write and debug s-exp all the time and was looking for a mature higher level API to help me doing that

And here it is launching a separate process to provide the “editor” for one of the files:

This is awesome. How far can the composition go? Could you run an entire desktop this way?

I don’t know. You’d have performance problems if you started with my code (in fact, before I disabled Issues on Github, the first issue was, “this uses 100% of my CPU!”), but one of the best things about the protocol is that it has a straightforward mechanism for negotiating additional features, which in the extreme could be things like, “just write your updates directly to the GPU, please.”

"Unix pipes for graphics" is something I've thought about a dozen times in my life. This may well be The Way!

That's the idea I'm playing with most for now. But just playing… I haven't thought much about this, so I can't say I'm doing more than exploring the medium. If you or anyone has a principled approach in mind but haven't had the time to try it, now's the time to incept me. 🙂

The thing I love about this is that you can build a (de)composable Gui out of heterogenous pieces. Like, there's no reason any of this has to be written in the same language, or use the same frameworks so long as it acts as a vnc server. It also seems like it would be feasible to wrap non-vnc applications (or maybe just windows) in a vnc compatibility layer to sort of transclude them in. Correct me please, if any of that is a misunderstanding.

Yeah!! http://alltom.com/pages/futureofcoding/#collaboration.

I like the simplicity of it, but I wonder if it's limiting in some cases. How would inline links, bold or italic markup look like?

I'm not sure!

Haven't thought too hard about those ones yet

Any ideas?

Ah sorry I forgot that's a solved problem

markdown

 Someone can define a markdown

 node type and then you can just use markdown

 like you normally would *embed* _markdown_.

emojiDown

 And this whole sentence would be bold if you added

 your own mini language, "emojiDown", which

 defined your own node types❗

Your Readme doesn't say how you support spans (bold, italic, and inline links) which are crucial parts of Markdown. Also,

• I'd much rather start list items with a dash

• I found it hard to remember at first whether it was text or (text)[link] or [text][link] in Markdown, but now I'm used to it and it's fine. If Markdown had universally used [text][link], it would have been easier to remember ([text][id] is allowed where [id] refers to a link provided later in the document, but Markdown could have dealt with this ambiguity by assuming anything that contains a slash is a link, or by assuming that if no link is provided later on, the id itself is a link.)

• Similarly I would have preferred to use /slash for italics/ instead of this... But again, that ship has sailed.

Maybe Markdown's biggest issue is ambiguity, like, If I write "apple and *banana and* cherry", did I just create a code block around "apple and *banana", or did I create a piece of boldface text around "banana` and"? But again this is a question of how spans are delimited, which your readme does not address.

Thanks for the feedback!

Questions regarding inline have

come up a lot. Just started an

FAQ with a more in-depth answer to

the inline question:

https://github.com/treenotation/dumbdown/blob/master/README.md#faq

I saw the HN thread for this, and the comparison to markdown confuses a lot of people. Perhaps a better pitch is as syntax sugar for html/xml.

nice! add support for namespaces on keywords so I can "import" a namespace that doesn't clash with others 🙂

by support I mean specifying that a keyword can be a word or two words separated by some special character (/ or : for example)

in case you want to take some inspiration: https://haml.info/

the class thing could be interesting: admonition.danger.small

Haha. HAML was the genesis of this idea many years ago (https://faq.treenotation.org/#how-was-tree-notation-discovered)

Tree Notation grammars naturally concatenate

You can literally copy/paste any N grammars together,

and just need to change 1 or 2 lines of code to

design how they fit together

But you are spot on in jumping right to namespaces.

That's the key aspect of this idea.

5:14 I'm not sure what you mean by "the probes of the platforms interfere with each other", since the system apparently seems happy to allow two objects to occupy the same space at the same time.

I would say that the video would be easier to understand if I knew more about the basic principles of the system, like which laws of physics (if any) it follows, and what each component is capable of doing. And yeah, Chris's feedback is good.

In any case it's very cool that you can implement a sorting algorithm in this manner.

Regarding "on fire" and "burning" - synonym detection is useful not just here but in traditional IDEs as well, e.g. if I type "Length" I want it to find "Size" and "Count" underneath anything that is actually called "Length" (this is the most useful, of course, when nothing named Length is found).

This feature would be useful both at the language level - one should be able to define a function together with synonyms (old and deprecated names together with merely alternate names) that map to the canonical name - and also at the IDE level, where machine learning or a simple thesaurus could find related names. Oh, and the IDE could also refer to the documentation for search results, and use API popularity to help choose the order of results.

The "query API" is is just a bunch of methods filter and props. With these source triples:

 :me

  rdf:type schema:Person;

  schema:name "Emmanuel Oga";

  schema:familyName "Oga";

  schema:givenName "Emmanuel";

  schema:jobTitle "Software Engineer";

  schema:knowsLanguage "en-US", "es-ES".

I can find my name like this:

val name = qs.filter(s = ":me").props("schema:name") // -> returns "Emmanuel Oga"

For persistence I may experiment with https://github.com/lmdbjava/lmdbjava/. I have no idea what the numbers are gonna be like with its B+Tree on a SDD 🙂.

I'm just getting into graph databases atm, this looks great