4 ms·

One thing one my wish list of things that will probably never happen is an extensible EMACs, Jupyter hybrid with a full on highly extensible dependently typed p

One thing one my wish list of things that will probably never happen is an extensible EMACs, Jupyter hybrid with a full on highly extensible dependently typed programming language. By keeping the specification of the components as abstract as possible, one could reinterpret the same code to give a completely different and customizable user experience. Probably with a lens based GUI toolkit for interactive widgets. I have no idea if it is possible, and maybe I should be the change I want to see in the world. EDIT: I realize now this doesn't quite follow the conversation, but I wanted to get the thought out somewhere.

K0SM0S 6y ago
OK, I'll bite that sandwich. Can you expand some of these points? I fail to understand (I need an ELI5, first principles) I think I get the premise, EMACs/Jupyter hybrid with ext. prog. lang. (+1 for typed). > By keeping the specification of the components as abstract as possible, one could reinterpret the same code to give a completely different and customizable user experience. Custom UX is my pet peeve, has been forever since the 1990s. I have intuitions but no clear understanding of what you mean here. Does that essentially mean decoupling model/view, a more modular or stateless metaphor? > Probably with a lens based GUI toolkit for interactive widgets. lens? (impossibly hard for me to Google what that generic word refers to, I just tried) ———— I'd like to 'get' to the essence of the paradigm you're suggesting. What the 'magic' is, its endgame, what it 'feels' or looks like.
- edjrage 6y ago
  Maybe they're referring to this? https://en.wikibooks.org/wiki/Haskell/Lenses_and_functional_references https://en.wikibooks.org/wiki/Haskell/Lenses_and_functional_... As for the "abstract specification", I interpret it as decoupling the view from the model too, but maybe expressing how you can represent the model? Like "option" being representable by a dropdown or radius buttons. I don't know, I agree it's vague.
- reuben364 6y ago
  So there are sort of several ideas floating in my head. Keep in mind, these are very loose and I am talking way out of my league here. I said lenses, but the more general term is optics (still vague and unsearchable, I know). A certain representation of optics was popularized in Haskell by Edward Kmett partly as a way to solve the record access problem, but they are way more useful then that. Lenses, in a context of programming, can sort of be seen as a vast purely functional generalization of l-values. When you are manipulating affordances in a user interface, you can view it as manipulating part of larger state. That is something that fits very well into the framework of optics. A simple example would be a color picker using different color models. HSV and RGB are both views of the same object. A slider for each of hue, saturation, value, red, blue and green can be seen as a lens from color to a magnitude. By adjusting the slider, you change the state. Some parts of a user interface are dynamical systems, i.e. evolve over time based on state and locally available actions. One can imagine a platformer game with changing player position, or a media player with a slider. FRP delves into this, but I'm not too familiar with the literature. I am vaguely aware that lenses can be connected to dynamical systems, but I don't understand it at all. As far as reinterpreting code. In Haskell and typed functional programming in general, there is this tower of different abstractions you can use to describe different levels of reified computation (Functors, Applicatives, Arrows, Monads). You also get effects systems, which make it more tractable for the layman that doesn't want to read ω+1 monad tutorials. In these abstractions, one can make "free" constructions, which sort of have the flavor of making the thing as syntactic as possible while still following the laws that must be upheld by the abstraction. This makes it possible to write code separately from the way it is interpreted. I only have a vague feeling that these concepts will fit well together. Perhaps my head is too far in the clouds. EDIT: As far as model view separation, that it is. But the idea is to stratify it even further. You have your larger state of the whole application in which you can increasingly select parts of the whole and manipulate them. The lens part not only captures the translation from the model to the view, but also from actions on the view to the model.
  - reuben364 6y ago
    Replying because its too late to edit EDIT: I'm struggling to find the source connecting lenses to dynamical systems. I might have misremembered, and was pretty tired, so take that with a grain of salt.
nonbirithm 6y ago
How would Emacs with a typed programming language work with function redefinition? One of the benefits of the environment is I can change code very easily and see the changes quickly. But with types I'm not sure how you'd change the signature of a function and get it to recompile if it's already used elsewhere.
- reuben364 6y ago
  That's one thing I have been thinking about. I think Haskell and other statically typed functional programming languages would benefit from a more interactive REPL like experience for "non-pure" programming where you are sort of changing the wheels on a moving car. This has a very reactive flavor, so I think you could have a sort of functional reactive approach where your hot-swappable definitions are represented as behaviours over time. How to make that get out of your way until you actually want to swap things out, I have no clue. I think it will involve some sort of effect system, but I'm not sure if that will solve the problem.
  - reuben364 6y ago
    I realize now that you were talking about changing types, which I didn't factor in. I guess what would happen is you would cascade the hot swapping, reloading anything which depends on the function for which the type has changed.

K0SM0S 6y ago

OK, I'll bite that sandwich. Can you expand some of these points? I fail to understand (I need an ELI5, first principles) I think I get the premise, EMACs/Jupyter hybrid with ext. prog. lang. (+1 for typed). > By keeping the specification of the components as abstract as possible, one could reinterpret the same code to give a completely different and customizable user experience. Custom UX is my pet peeve, has been forever since the 1990s. I have intuitions but no clear understanding of what you mean here. Does that essentially mean decoupling model/view, a more modular or stateless metaphor? > Probably with a lens based GUI toolkit for interactive widgets. lens? (impossibly hard for me to Google what that generic word refers to, I just tried) ———— I'd like to 'get' to the essence of the paradigm you're suggesting. What the 'magic' is, its endgame, what it 'feels' or looks like.

edjrage 6y ago
Maybe they're referring to this? https://en.wikibooks.org/wiki/Haskell/Lenses_and_functional_references https://en.wikibooks.org/wiki/Haskell/Lenses_and_functional_... As for the "abstract specification", I interpret it as decoupling the view from the model too, but maybe expressing how you can represent the model? Like "option" being representable by a dropdown or radius buttons. I don't know, I agree it's vague.
reuben364 6y ago
So there are sort of several ideas floating in my head. Keep in mind, these are very loose and I am talking way out of my league here. I said lenses, but the more general term is optics (still vague and unsearchable, I know). A certain representation of optics was popularized in Haskell by Edward Kmett partly as a way to solve the record access problem, but they are way more useful then that. Lenses, in a context of programming, can sort of be seen as a vast purely functional generalization of l-values. When you are manipulating affordances in a user interface, you can view it as manipulating part of larger state. That is something that fits very well into the framework of optics. A simple example would be a color picker using different color models. HSV and RGB are both views of the same object. A slider for each of hue, saturation, value, red, blue and green can be seen as a lens from color to a magnitude. By adjusting the slider, you change the state. Some parts of a user interface are dynamical systems, i.e. evolve over time based on state and locally available actions. One can imagine a platformer game with changing player position, or a media player with a slider. FRP delves into this, but I'm not too familiar with the literature. I am vaguely aware that lenses can be connected to dynamical systems, but I don't understand it at all. As far as reinterpreting code. In Haskell and typed functional programming in general, there is this tower of different abstractions you can use to describe different levels of reified computation (Functors, Applicatives, Arrows, Monads). You also get effects systems, which make it more tractable for the layman that doesn't want to read ω+1 monad tutorials. In these abstractions, one can make "free" constructions, which sort of have the flavor of making the thing as syntactic as possible while still following the laws that must be upheld by the abstraction. This makes it possible to write code separately from the way it is interpreted. I only have a vague feeling that these concepts will fit well together. Perhaps my head is too far in the clouds. EDIT: As far as model view separation, that it is. But the idea is to stratify it even further. You have your larger state of the whole application in which you can increasingly select parts of the whole and manipulate them. The lens part not only captures the translation from the model to the view, but also from actions on the view to the model.
- reuben364 6y ago
  Replying because its too late to edit EDIT: I'm struggling to find the source connecting lenses to dynamical systems. I might have misremembered, and was pretty tired, so take that with a grain of salt.

nonbirithm 6y ago

How would Emacs with a typed programming language work with function redefinition? One of the benefits of the environment is I can change code very easily and see the changes quickly. But with types I'm not sure how you'd change the signature of a function and get it to recompile if it's already used elsewhere.

reuben364 6y ago
That's one thing I have been thinking about. I think Haskell and other statically typed functional programming languages would benefit from a more interactive REPL like experience for "non-pure" programming where you are sort of changing the wheels on a moving car. This has a very reactive flavor, so I think you could have a sort of functional reactive approach where your hot-swappable definitions are represented as behaviours over time. How to make that get out of your way until you actually want to swap things out, I have no clue. I think it will involve some sort of effect system, but I'm not sure if that will solve the problem.
- reuben364 6y ago
  I realize now that you were talking about changing types, which I didn't factor in. I guess what would happen is you would cascade the hot swapping, reloading anything which depends on the function for which the type has changed.