You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a very interesting feature that is awesome to have. In Jupyter, one can use the interact function to generate widgets as sliders, checkboxes, textboxes and dropdowns. These are quite cool because we can create a "Display input" typeclass, to map each input to a type:
class (Showa, Reada) =>DisplayInputawheredisplayInput::a->_instanceDisplayInputIntwhere-- Same for Float, Double, ...
displayInput =<code to display a slider>instanceDisplayInputBoolwhere
displayInput =<code to display a checkbox>instanceFromStringa=>DisplayInputawhere
displayInput =<code to display a text input>instanceDisplayInputMySumTypewhere
displayInput = dropdown [ <all the MySumType constructors (must be of kind `::*`, whichbasicallymeansthatitissomethinglikeanenum)> ]
dataMySumType=Option1
| Option2
| Option3deriving (Read, Show)
How this would work?
I had an interesting talk with Simon Thompson, and this idea came out:
We setup a websocket/endpoint that is listening in some other port. We will add a script tag inside our display (when it gets generated), and that script tag has some code to send messages through the websocket/endpoint. Then these displayInputs simply are HTML elements with onclick or other attributes that just call the function defined in the script tag we created before.
In the Haskell side, the websocket/endpoint will wait until, and we, somehow, will pass a Map to our Compilation module, where, before compilation, the different variables will be substituted by the values we selected in our widgets, but we will save the previous code. The code gets compiled, rendering is executed and then we substitute the code back, so our markdown editor still has the code we've written.
Thinking about this better, it introduces some stuff that doesn't seem reasonable from a user's perspective, if they want to use the module they've generated in haskell.do in a project:
They have to depend in a module that is already outside of the scope, of their project (displaying stuff)
The code gets modified in compile time, and it gets back to it's previous state, but still they have the rendered code with some other value.
Another idea that comes to mind is use some annotation like Liquid Haskell uses, inside comments:
Maybe we could have something like:
{-@ displayInput @-}
myValue::Int
myValue =10
In this way, we don't force the user to depend on the DisplayInput module, and we just define the value at the moment. In this case, it will start in 10, but as soon as the user moves the slider, it will just change the value of the variable and it will leave the value like that, which is very useful if you are fine-tuning parameters, for example, say, in a neural network.
The text was updated successfully, but these errors were encountered:
After proposing this, I think it it more flexible for us to use just normal functions/typeclasses, because, it is more extensible in the end. Maybe there could be something like a "cleanup" button?
I think typeclasses are the way to go, allowing users to extend the class with their own instance (potentially using one of the reactive frameworks like react flux) is way preferable to generic inputs.
(This would also make haskell-do an interactive visualization development environment: you could potentially take a haskell-do project and stick it onto an existing endpoint on some server and have a functioning data-driven webapp.)
I don't know enough about the internals of haskell-do: why wouldn't you just pass any defined display instances to GHCJS on compile and embed the bundled html/js/websocket pipe in the frontend wherever eval is called?
This is a very interesting feature that is awesome to have. In Jupyter, one can use the
interact
function to generate widgets as sliders, checkboxes, textboxes and dropdowns. These are quite cool because we can create a "Display input" typeclass, to map each input to a type:How this would work?
I had an interesting talk with Simon Thompson, and this idea came out:
We setup a websocket/endpoint that is listening in some other port. We will add a
script
tag inside our display (when it gets generated), and that script tag has some code to send messages through the websocket/endpoint. Then thesedisplayInput
s simply are HTML elements withonclick
or other attributes that just call the function defined in thescript
tag we created before.In the Haskell side, the websocket/endpoint will wait until, and we, somehow, will pass a
Map
to ourCompilation
module, where, before compilation, the different variables will be substituted by the values we selected in our widgets, but we will save the previous code. The code gets compiled, rendering is executed and then we substitute the code back, so our markdown editor still has the code we've written.Thinking about this better, it introduces some stuff that doesn't seem reasonable from a user's perspective, if they want to use the module they've generated in haskell.do in a project:
Another idea that comes to mind is use some annotation like Liquid Haskell uses, inside comments:
Maybe we could have something like:
In this way, we don't force the user to depend on the
DisplayInput
module, and we just define the value at the moment. In this case, it will start in 10, but as soon as the user moves the slider, it will just change the value of the variable and it will leave the value like that, which is very useful if you are fine-tuning parameters, for example, say, in a neural network.The text was updated successfully, but these errors were encountered: