6 ms·

Tylr: A tiny tile-based editor

115 points by harporoeder 4y ago

111hfurfud 4y ago
- 111hfurfud 4y ago
smitty1e 4y ago
The upper-right ? leads to a Twitter thread with more detail: https://twitter.com/dm_0ney/status/1414742742530498566?s=20 https://twitter.com/dm_0ney/status/1414742742530498566?s=20
- mananaysiempre 4y ago
  This is extremely cool, and it would also be interesting to work out the grammar formalism implied by this description (tile end shapes and sorts, “bidelimited” constructs). It’s likely more restrictive than just a context-free grammar (a mixfix precedence parser?), but that’s not necessarily a problem. ETA: More relared work at Michigan apparently goes by the name Hazel[1]. There was a recorded talk[2] at LIVE 2021. The textual version has been removed[3] from the repo for some reason(?) but remains on the website[4]. The authors suggest the relevant class of languages is “visibly pushdown”[5]. Also looks like a match made in heaven for an Explain Shell[6]-alike. [1] https://hazel.org/ https://hazel.org/, https://web.eecs.umich.edu/~comar/ https://web.eecs.umich.edu/~comar/ [2] https://2021.splashcon.org/details/live-2021-papers/4/Restructuring-Structure-Editing https://2021.splashcon.org/details/live-2021-papers/4/Restru..., https://liveprog.org/live-2021/Restructuring-Structure-Editing.mp4 https://liveprog.org/live-2021/Restructuring-Structure-Editi... [3] https://github.com/hazelgrove/tylr/commit/1db7a2b2a2ed263183cdaef30a005114f4aa83d7 https://github.com/hazelgrove/tylr/commit/1db7a2b2a2ed263183... [4] https://tylr.fun/essay/ https://tylr.fun/essay/ [5] https://www.csa.iisc.ac.in/~deepakd/atc-common/vpa-stoc04.pdf https://www.csa.iisc.ac.in/~deepakd/atc-common/vpa-stoc04.pd... [6] https://explainshell.com/ https://explainshell.com/, https://news.ycombinator.com/item?id=6296634 https://news.ycombinator.com/item?id=6296634
hombre_fatal 4y ago
Really cool UI with downright impressive polish. Unfortunately I don't understand the language. But man, the UI looks and feels great.
giraffe_lady 4y ago
Iiiinteresting. It reminds me of a hillel wayne thread from a while back that I remember poorly and can't find but will try to paraphrase. It was like "programming languages and workflows are built around the state of having written code rather than writing code." I think the example was how in most languages you can remove a few chars or a symbol and put it in a 100% invalid state where none of the tools will work at all. A few seconds ago you had a bunch of type information, jump-to-definition, auto formatting etc, now you have a compiler error instead. It really stuck with me because it described an experience so common I don't even really notice it anymore but really. What would it be like to work in a language that considered "non-functional" states still "valid" and tried to express what they knew about the gaps? This is a very different idea but I feel like it's approaching some of the same concepts, in a way.
- pjz 4y ago
  I agree it's kind of odd that our dev process is essentially a sea of broken states with intermittent workingness (if you count by states, I mean). Version control commits are an attempt to hilight/preserve those working states. Limiting deltas to working-only states would, I think, result in something akin to MIT's 'Scratch' language, where kids put together puzzle pieces - a program can only be wrong at a semantic level, never at a source code level. OTOH, refactoring power tools available in modern IDEs are a bit of a counter-argument in that they allow code transforms that don't usually make much of a semantic difference (eg. 'inline this', 'extract this as a variable', etc) But as you say, that's "written code" not "writing code". For writing code, I think the closest current IDE feature to tylr would maybe be syntax hilighting. It'd be cool to maybe have some kind of 'expression hilighting' mode, and maybe an 'expression editor' mode with actions like tylr supports.
  - kqr 4y ago
    I mean, the closest I know to avoiding this is something like writing lisp with smartparen. This ensures the code is always syntactically valid, but it doesn't prevent you from partially typed function names like "filte". However, I think that's a good thing. The alternative to partially typing out functions would be selecting them from a list or automatically having the editor fill in the most likely match from before the first letter is typed. Both the latter would, if interrupted, convey less information than the partially typed out name. Phrased differently: writing code will always be a matter of narrowing down the full namespace to the appropriate function. Partially typing it provides the human about the most information on where things are going, even if it's not as friendly on compilers. So yeah, we could have compilers fill in the missing information to create a compiler-valid state from partial information, but what does that give us? A wildly incorrect program that's harder to fix? Programming is writing code for humans that computers occasionally read, not the other way around. With today's focus on tooling, I feel like we have forgotten this.
janjones 4y ago
I like the idea of editing AST directly instead of just plain text. JetBrains MPS[1] is an editor based on the same principle (but much more mature). Also, the Unison language stores its code only as AST, not text[2]. [1] https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/ [2] https://jaredforsyth.com/posts/whats-cool-about-unison/#Code-is-stored-as-a-structured-type-checked-tree-in-a-database-not-as-text-in-files https://jaredforsyth.com/posts/whats-cool-about-unison/#Code...
- cmrdporcupine 4y ago
  I keep hoping JetBrains will fold some of the interesting ideas in MPS into their more mainstream editors.
- jhgb 4y ago
  I guess people do keep reinventing Interlisp-D every decade.
  - ianai 4y ago
    Apparently this lives on as Medley https://interlisp.org/ https://interlisp.org/ . Was modifying the AST part of the GUI explicitly?
  - cmrdporcupine 4y ago
    Lisp has the property that the 'AST' is effectively 1:1 with the program code. In Algol-descended languages like C, Java etc, the expression tree can look quite structurally different from the program due to precedence rules etc. I think a tree-style editor for a more conventional PL would have to apply some transformations on the AST for display purposes, for programmer comfort.
    - jhgb 4y ago
      There's not really a lot of difference between Algol descendants and Lisp in this case if you look at problem as one of building a projectional editor.
- 4y ago
disconcision 4y ago
previous discussion: https://news.ycombinator.com/item?id=27926758 https://news.ycombinator.com/item?id=27926758
andrewl 4y ago
It made me think of Lamdu[1] a bit. I’m glad to see people thinking and building in this area. [1] http://www.lamdu.org/ http://www.lamdu.org/
dataangel 4y ago
totally broken on mobile (Android), can't see a thing
- belkarx 4y ago
  The author warns that it isn't mobile friendly in the explanatory Twitter thread

115 points by harporoeder 4y ago

111hfurfud 4y ago

The upper-right ? leads to a Twitter thread with more detail: https://twitter.com/dm_0ney/status/1414742742530498566?s=20 https://twitter.com/dm_0ney/status/1414742742530498566?s=20

mananaysiempre 4y ago
This is extremely cool, and it would also be interesting to work out the grammar formalism implied by this description (tile end shapes and sorts, “bidelimited” constructs). It’s likely more restrictive than just a context-free grammar (a mixfix precedence parser?), but that’s not necessarily a problem. ETA: More relared work at Michigan apparently goes by the name Hazel[1]. There was a recorded talk[2] at LIVE 2021. The textual version has been removed[3] from the repo for some reason(?) but remains on the website[4]. The authors suggest the relevant class of languages is “visibly pushdown”[5]. Also looks like a match made in heaven for an Explain Shell[6]-alike. [1] https://hazel.org/ https://hazel.org/, https://web.eecs.umich.edu/~comar/ https://web.eecs.umich.edu/~comar/ [2] https://2021.splashcon.org/details/live-2021-papers/4/Restructuring-Structure-Editing https://2021.splashcon.org/details/live-2021-papers/4/Restru..., https://liveprog.org/live-2021/Restructuring-Structure-Editing.mp4 https://liveprog.org/live-2021/Restructuring-Structure-Editi... [3] https://github.com/hazelgrove/tylr/commit/1db7a2b2a2ed263183cdaef30a005114f4aa83d7 https://github.com/hazelgrove/tylr/commit/1db7a2b2a2ed263183... [4] https://tylr.fun/essay/ https://tylr.fun/essay/ [5] https://www.csa.iisc.ac.in/~deepakd/atc-common/vpa-stoc04.pdf https://www.csa.iisc.ac.in/~deepakd/atc-common/vpa-stoc04.pd... [6] https://explainshell.com/ https://explainshell.com/, https://news.ycombinator.com/item?id=6296634 https://news.ycombinator.com/item?id=6296634

hombre_fatal 4y ago

Really cool UI with downright impressive polish. Unfortunately I don't understand the language. But man, the UI looks and feels great.

giraffe_lady 4y ago

Iiiinteresting. It reminds me of a hillel wayne thread from a while back that I remember poorly and can't find but will try to paraphrase. It was like "programming languages and workflows are built around the state of having written code rather than writing code." I think the example was how in most languages you can remove a few chars or a symbol and put it in a 100% invalid state where none of the tools will work at all. A few seconds ago you had a bunch of type information, jump-to-definition, auto formatting etc, now you have a compiler error instead. It really stuck with me because it described an experience so common I don't even really notice it anymore but really. What would it be like to work in a language that considered "non-functional" states still "valid" and tried to express what they knew about the gaps? This is a very different idea but I feel like it's approaching some of the same concepts, in a way.

pjz 4y ago
I agree it's kind of odd that our dev process is essentially a sea of broken states with intermittent workingness (if you count by states, I mean). Version control commits are an attempt to hilight/preserve those working states. Limiting deltas to working-only states would, I think, result in something akin to MIT's 'Scratch' language, where kids put together puzzle pieces - a program can only be wrong at a semantic level, never at a source code level. OTOH, refactoring power tools available in modern IDEs are a bit of a counter-argument in that they allow code transforms that don't usually make much of a semantic difference (eg. 'inline this', 'extract this as a variable', etc) But as you say, that's "written code" not "writing code". For writing code, I think the closest current IDE feature to tylr would maybe be syntax hilighting. It'd be cool to maybe have some kind of 'expression hilighting' mode, and maybe an 'expression editor' mode with actions like tylr supports.
- kqr 4y ago
  I mean, the closest I know to avoiding this is something like writing lisp with smartparen. This ensures the code is always syntactically valid, but it doesn't prevent you from partially typed function names like "filte". However, I think that's a good thing. The alternative to partially typing out functions would be selecting them from a list or automatically having the editor fill in the most likely match from before the first letter is typed. Both the latter would, if interrupted, convey less information than the partially typed out name. Phrased differently: writing code will always be a matter of narrowing down the full namespace to the appropriate function. Partially typing it provides the human about the most information on where things are going, even if it's not as friendly on compilers. So yeah, we could have compilers fill in the missing information to create a compiler-valid state from partial information, but what does that give us? A wildly incorrect program that's harder to fix? Programming is writing code for humans that computers occasionally read, not the other way around. With today's focus on tooling, I feel like we have forgotten this.

janjones 4y ago

I like the idea of editing AST directly instead of just plain text. JetBrains MPS[1] is an editor based on the same principle (but much more mature). Also, the Unison language stores its code only as AST, not text[2]. [1] https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/ [2] https://jaredforsyth.com/posts/whats-cool-about-unison/#Code-is-stored-as-a-structured-type-checked-tree-in-a-database-not-as-text-in-files https://jaredforsyth.com/posts/whats-cool-about-unison/#Code...

cmrdporcupine 4y ago
I keep hoping JetBrains will fold some of the interesting ideas in MPS into their more mainstream editors.
jhgb 4y ago
I guess people do keep reinventing Interlisp-D every decade.
- ianai 4y ago
  Apparently this lives on as Medley https://interlisp.org/ https://interlisp.org/ . Was modifying the AST part of the GUI explicitly?
- cmrdporcupine 4y ago
  Lisp has the property that the 'AST' is effectively 1:1 with the program code. In Algol-descended languages like C, Java etc, the expression tree can look quite structurally different from the program due to precedence rules etc. I think a tree-style editor for a more conventional PL would have to apply some transformations on the AST for display purposes, for programmer comfort.
  - jhgb 4y ago
    There's not really a lot of difference between Algol descendants and Lisp in this case if you look at problem as one of building a projectional editor.
4y ago

disconcision 4y ago

previous discussion: https://news.ycombinator.com/item?id=27926758 https://news.ycombinator.com/item?id=27926758

andrewl 4y ago

It made me think of Lamdu[1] a bit. I’m glad to see people thinking and building in this area. [1] http://www.lamdu.org/ http://www.lamdu.org/

dataangel 4y ago

totally broken on mobile (Android), can't see a thing

belkarx 4y ago
The author warns that it isn't mobile friendly in the explanatory Twitter thread