Suppose I have:

   let y = f(2, 3)

And I add a start parenthesis like this:

   let y = f((2, 3)

There is no longer a valid tree and it is not obvious at that point where, I, the end-user, want the parenthesis construct to end.

Well the demo is live, it's linked right there and you could try it.

I did, and after typing in the left-parens inside the already existing left-parens, tylr gave me a right-parens in the "backpack", the space above where I was typing, and then didn't let me move outside of the enclosing parens pair (ie, I had to "put down" the matching right-parens to either enclose the 2, or the 2,3 pair). If instead I put in the left-parens before the already existing one, tylr automatically added the right-parens after the existing right-parens (which makes sense, it's the only legal place for the left-parens I just added to be matched).

But again, you could just try it out.

That's kind of cool. It would also be nice if hitting ( after selecting an expression would wrap it in ()s, if it is syntactically correct to do so. That's the first thing I tried.

Yup, these kinds of things are definitely on the agenda as we integrate the core ideas here into Hazel. We kept things minimal in Tylr to focus on the core ideas with minimal "magic".

I did and I couldn’t really understand what it was doing.

If it works like Emacs paredit, the default for just hitting `(` would be

  let y = f()(2, 3)

but there should be a different command to do (`alt-(` in paredit)

  let y = f((2, 3))

There should of course also be "slurp" and "barf" commands to add or remove items from the parentheses if you do the wrong thing first (or want to wrap multiple things in the parentheses)

And also "boof" and "crap" commands for moving items in and out of the the other side of the parens.

I put the parenthesis one step further to the right - so you would get:

   let y = f(()2, 3)

Which possibly wouldn't parse.

That would depend on the language. Paredit is mainly made for Lisp where that would be legal (aside from the comma between 2 and 3). In some other languages that could also be allowed for casts.

(It possibly wouldn't parse in a language with C-style syntax.)

Indeed, that problem (ambiguity about where to put matching delimiters) is what motivated tylr. The solution is: when the location of the closing parentheses isn't unique, as in your example, tylr puts it in the "backpack" above the cursor and enters "restructuring mode", letting you select where it should go (within the valid region).

Reasonable question given the usual approach to structure editors, which have users directly modify the AST. tylr adopts a more indirect approach, where your program is presented in an alternate (modal) tile-based syntax with its own syntax-directed editing. The point of this indirection is to give you more text-editor-like flexibility, but unlike text tylr makes sure you can always (in the default mode) transform your program from the tile-based syntax to the abstract syntax.

It might help to think of restructuring mode, the mode automatically entered upon constructing `(`, as a transactional editing mode in which you specify your AST-to-AST transformation.