I have an example of something like this but it's broken due to some bugs in the Array code. I'll try to rewrite it with list and semi release it - I've been doing some widget stuff myself and I think that I have some useful commentary. I'll try to make sure I don't repeat previous discussion but in essence, yes, it becomes really difficult to encapsulate widget abstractions that deal with collections of widgets and/or nested widgets.
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks, that gives me a good place to start!
However, I don't like that class of solution very much. I want fine grained decomposition of system state into different events and behaviors, like what I get for free when the layout structure is fixed - I don't want to be forced into using a monolithic state type and monolithic state update function. That's ugly and not modular, composable, etc.
So, is it possible to do better in Elm?
Paul
--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/dyvDKdCXZ6A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
I actually like how Elm doesn't let you "cheat", that you have to be perfectly clear about the state of the program and what constitutes and event. Granted this likely won't scale .... I'm aware of using functions as events, first discovered (?) by Max New here ... I refrained from going that route since it's more complicated, and I thought it would make a better point to show that the task could be done without using the biggest gun in the arsenal. The challenge was more about dynamically created event handlers, made possible by the revisions to Graphics.Input a few months ago ... that said I do like the event-as-function methodology, since it (1) makes it much easier to extend than a datatype (2) unites all the logic in a particular case, rather than spreading it over a many signals which are merged (implicitly in the case of Graphics.Input) and then case analysis in the transition function (foldp's function argument). The transition function is merely function application; all the logic of how an event changes the state is pushed to event signals themselves. ... I'll give this another look over in a day or two for rendering improvements and small style concerns, and then refactor into the event signal model.
--
Thanks for the replies everyone, this gives me a lot to think about. One idea that occurs to me to improve the modularity of using a single state type is to use a Lens into the state, so that different parts of the code can be aware of only the portion of the state they care about (this combinator is called zoom in Control.Lens and has an absurdly general type, but the basic idea is pretty simple, it's zoom : Lens s0 s -> State s a -> State s0 a). I'll play around with this and report back.
Max, I'd like to see that improved code when you get the chance!
Evan, do you have an early draft of that paper, or an informal writeup somewhere? It sounds tantalizing, but I need more detail than what you just gave. :)
> I also expect most early users will be embedding anyway. No industrial user will sit down and decides "I want to throw all of my code away and rewrite it entirely in Elm" so we have time to sort this out.
IMO, I think nailing down a good story for this sort of dynamism is pretty important, even in the short term. Reason is that there's also a class of users (like myself) that are starting new projects and are considering Elm. An existing project can just incrementally rewrite some pages that play well to Elm's current strengths, but new projects are making more 'all or nothing' tech decisions between various possible client side options. It's important therefore that new projects be able to answer the question 'Is Elm expressive enough for these use cases?'
For me, expressiveness is key with any technology evaluation - before investing in a technology, I much prefer to know, up front, if the tech can express my use case without total hacks. Once I know that, I start looking at other 'nice to haves' to make a decision.
Paul :)
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/dyvDKdCXZ6A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.
Thanks for the replies everyone, this gives me a lot to think about. One idea that occurs to me to improve the modularity of using a single state type is to use a Lens into the state, so that different parts of the code can be aware of only the portion of the state they care about (this combinator is called zoom in Control.Lens and has an absurdly general type, but the basic idea is pretty simple, it's zoom : Lens s0 s -> State s a -> State s0 a). I'll play around with this and report back.
Max, I'd like to see that improved code when you get the chance!
Evan, do you have an early draft of that paper, or an informal writeup somewhere? It sounds tantalizing, but I need more detail than what you just gave. :)
> I also expect most early users will be embedding anyway. No industrial user will sit down and decides "I want to throw all of my code away and rewrite it entirely in Elm" so we have time to sort this out.
IMO, I think nailing down a good story for this sort of dynamism is pretty important, even in the short term. Reason is that there's also a class of users (like myself) that are starting new projects and are considering Elm. An existing project can just incrementally rewrite some pages that play well to Elm's current strengths, but new projects are making more 'all or nothing' tech decisions between various possible client side options. It's important therefore that new projects be able to answer the question 'Is Elm expressive enough for these use cases?'
For me, expressiveness is key with any technology evaluation - before investing in a technology, I much prefer to know, up front, if the tech can express my use case without total hacks. Once I know that, I start looking at other 'nice to haves' to make a decision.
--