I’m trying to solve the long standing problem of things being represented in their own looks in the Kary Language. There are some prior art into making things like this; namely:

Now the work I have done on AnnotationsKit show that there are different forms of Layout. The work in Nota Language and Arendelle Language also show different things all of which are incoherent in the design of a language like this. So Imagine this:

Imagine if you could combine so much that actually the slider could go inside of the radical notation. Basically you could have had it because based on its return type it could be there and work. Now this is possible to make with the experience I have in making Nota Language and AnnotationsKit; but what should we do about the other cases of things that need more than a tree?

But what if I need to have a function? I guess that can happen in the old sense of having things like f(x) = ⎷x ] This would be easy to make.

But what if I needed to have connections? And higher order elements? How do we go about making things that are to edit the notation itself or create its components? I have also explored this in DesignTalk where by selecting an element the change UI would have appeared:

Now I imagine the same thing to be true for the UI elements there:

But then you would have something like a representation view of a data. How do you build that? How even do you go about making a code like this?

This is the part that has taken me much time to think about. How must the language work if it is visual?

Parts of the answer comes from Nota Language and part of it from Glamorous Toolkit. The problem is like this:

• Nota Language’s answer to this primitive but effective: Classic Polymorphism. We take the parsed AST of a textual representation and make it into two separate views: A representation and a computation.

The beautiful thing in Nota Language is how the two things talk to each other. I don’t know how that can be beautifully put together. The other candidate is the Glamorous Toolkit. The interesting thing about this system is that it is alive and everything gets to have its own view. This best understood — in my view — as the polymorphism of having .toString() in other languages. But then remember that it can also be handling more than one representation with its <GtView> things.

• In both of these systems; we have a factory format that representation must be derived from an AST of a textual representation. How do we arrive at a system where the representation itself creates new representation?

• This is done incredibly well inside of the Audulus Programming Language — an amazing piece of art — where the existence of the basic elements permits grouping of nodes into a new interface. The problem of this that the UI of Audulus software is made with placement of its children; whereas we require.