[HN Gopher] Tylr: Demo of tile-based editing, a new kind of stru...
___________________________________________________________________
Tylr: Demo of tile-based editing, a new kind of structure editing
Author : polm23
Score : 198 points
Date : 2021-07-23 03:10 UTC (1 days ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| hprotagonist wrote:
| https://hazel.org has been on this beat for some time as well,
| and have the proofs to back it up.
|
| _Hazel is a live functional programming environment that is able
| to typecheck, manipulate, and even run incomplete programs, i.e.
| programs with holes. There are no meaningless editor states._
| cwackerfuss wrote:
| Looks like OP is building Hazel!
| cyrus_ wrote:
| Yup, tylr is a minimal prototype, ala Hazelnut, intended to
| be adapted and integrated into Hazel (happening now!)
| hprotagonist wrote:
| so he is!
| mdrachuk wrote:
| From Twitter: tylr is a tiny interactive exposition of _tile-
| based editing_, a new kind of structure editing that, like text,
| supports linear token-level editing workflows but, unlike text,
| ensures your manipulated tokens can always be parsed back into a
| valid syntax tree
| throwaway4good wrote:
| I don't quite understand this. Suppose I enter a start
| parenthesis - '(' - then what is it supposed to do / have as an
| AST?
| dm_0ney wrote:
| 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.
| throwaway4good wrote:
| 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.
| juki wrote:
| 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)
| DonHopkins wrote:
| And also "boof" and "crap" commands for moving items in
| and out of the the other side of the parens.
| throwaway4good wrote:
| I put the parenthesis one step further to the right - so
| you would get: let y = f(()2, 3)
|
| Which possibly wouldn't parse.
| throwaway4good wrote:
| (It possibly wouldn't parse in a language with C-style
| syntax.)
| juki wrote:
| 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.
| patrickyeon wrote:
| 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.
| throwaway4good wrote:
| I did and I couldn't really understand what it was doing.
| breuleux wrote:
| 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.
| cyrus_ wrote:
| 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".
| cyrus_ wrote:
| 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).
| ThePhysicist wrote:
| How is this novel compared to e.g. the Microsoft Equation Editor,
| which uses a hierarchical, cell-based approach for describing
| mathematical formulas? I guess this is a bit different since you
| can enter everything via the keyboard, while the MS editor
| requires you to select primitives from a menu.
|
| The UI looks very nice and minimalistic though, I really like it.
| lggy wrote:
| AFAIK the MS equation editor allows writing a subset of LaTeX
| tags for symbols, doesn't it?
| tonetheman wrote:
| What language is this? Or is it just a mathematic editor? Just
| wondering it is interest whatever language it is.
| anigbrowl wrote:
| Kinda neat, would prefer to have a page rather than just a line
| of code to move up and down. I can see it catching on, it's not
| just a big departure from current syntax highlighting/code
| completion. My IDE pre-matches various brackets and quotes as I
| type and gets it right most of the time.
| throwamon wrote:
| I like the visual style and the conceptualization, but is
| anything about it really new? Not trying to be dismissive, I just
| looked at some structural and projectional editors some time ago
| and this seems to have very similar ideas. JetBrains MPS and
| Lamdu[1] come to mind, but there are many others. There's also a
| subreddit[2] for this sort of thing.
|
| [1] https://www.youtube.com/watch?v=skhP6LcbRTs
|
| [2] https://reddit.com/r/nosyntax
| dm_0ney wrote:
| Yeah! For one thing, tylr makes it possible to make sub- and
| cross-structural selections, which isn't possible in other
| structure editors. Try typing `2 + 3 * 4` in MPS and selecting
| `* 4` or even `2 + 3`--you can't because they don't correspond
| to abstract syntactic terms. tylr understands these sorts of
| arbitrary range selections and makes sure you manipulate them
| in reasonable ways (eg see
| https://twitter.com/dm_0ney/status/1414742962442014720?s=20).
| bookofsand wrote:
| I'd love to hear more about MPS. I tried looking into it, but
| the 'getting started' tutorials involved tens of files with
| arcane (for a novice) logic, so I gave up.
| amitport wrote:
| more specifically, there is a list of such projects in:
| https://www.reddit.com/r/nosyntax/wiki/projects
| danwills wrote:
| This is the first time I've been totally prevented from
| reading something on Reddit by the pop-up, it used to let me
| through eventually! Now it seems to just ditch the url I
| wanted and goes to 'popular' instead! (Opera mobile Android)
| Why did they do that? Is (usage of) the app really that much
| more valuable to them?
| danwills wrote:
| Ah derp! Works great with "request desktop site" turned on.
| Tempest1981 wrote:
| https://old.reddit.com/r/nosyntax/wiki/projects
| jansan wrote:
| I would love to see this as an option in tools like regex101 .
| This could make debugging complex regular expressions much
| easier.
| danwills wrote:
| Yeah! something like this as a regex-writing helper could be
| super useful! And it could have uses such as a mini-
| editor/plugin within an appropriate larger editor framework?
| Cool idea!
| dmos62 wrote:
| I'm not familiar with this mathematical style, if you can call it
| that. I kept wanting to break the line.
| teleforce wrote:
| This is a very exciting development, similar in spirit to the
| proposal by Bret Victor for Learnable Programming [1].
|
| I'm also excited by the fact that from their website the CRDT for
| local-first collaborative editing and Jupyter like alternative
| are also in the pipeline [2].
|
| For those who are interested in the history of structure editor
| you can check the venerable Tioga editor in Xerox's Cedar
| programming environment [3],[4].
|
| [1]http://worrydream.com/LearnableProgramming/
|
| [2]https://hazel.org/
|
| [3]http://www.bitsavers.org/pdf/xerox/parc/cedar/Cedar_7.0/07_T..
| .
|
| [4]https://www.youtube.com/watch?v=z_dt7NG38V4
| code_biologist wrote:
| Reminds me of Paredit, an emacs mode for structural code editing
| and navigation for lisps. It keeps the parse tree valid even as
| you do crazy stuff.
|
| http://danmidwood.com/content/2014/11/21/animated-paredit.ht...
| dm_0ney wrote:
| Yeah slurping and barfing in Paredit are quite similar to basic
| restructuring operations in tylr, eg selecting a parenthesis
| and moving it somewhere else. Some differences:
|
| (1) In tylr you move the parenthesis itself, rather than making
| the parenthesized term slurp/barf its neighbors. This may seem
| like a minor difference for simple operations like this but I
| think it's an important primitive UI metaphor that makes the
| editing experience feel more direct/linear/text-like rather
| than you having to translate your editing goal into operations
| on the AST.
|
| (2) tylr generalizes beyond S-expressions to infix operator
| sequences and other multi-sorted syntactic forms (eg it
| understands you shouldn't be able to move expression forms in
| patterns).
|
| (3) tylr generalizes beyond parenthesis moving to near-
| arbitrary range selection moving, eg I could make the selection
| (specified by the square brackets)
|
| `( 1 + 2[) * (]3 + 4 )`
|
| and directly move it over to give
|
| `( 1[) * (]_ + 2 + 3 + 4 )`
|
| (where tylr has inserted a hole `_` to keep things well-formed)
| josteink wrote:
| Was looking for this exact comment.
|
| I'm honestly waiting for a tree-sitter (or LSP) based paredit-
| mode to show up, so that I can use it for all modes and
| languages, and not just LISP.
| hk__2 wrote:
| Paredit is really great, and has been adapted to other editors
| as well. Writing Clojure in IntelliJ with Cursive and Paredit
| mode is really pleasant.
| jhgb wrote:
| Yep, Paredit was my first thought as well.
___________________________________________________________________
(page generated 2021-07-24 23:01 UTC)