Hi Peter, this exchange already helped me to understand some of the nuances of the Elm architecture better, thank you. I'm actually implementing a lot in Elm recently, and while I think writing code is the best way to learn a new technology, it also helps to exchange with peers from time to time (just writing and looking at code makes me blind to the obvious ;)).
So yeah, I will keep trying and see how far I can get with your advice. Thanks. On Friday, July 1, 2016 at 4:07:16 PM UTC+2, Peter Damoc wrote: > > Robert, > > What you are describing here can be modeled with current technologies and > it relates to the composition that is usually found in The Elm > Architecture. > Take a look a the nesting examples: > https://github.com/evancz/elm-architecture-tutorial/tree/master/nesting > > These multiple domains that you describe could be modeled either side by > side using some kind of record structure or in a hierarchy where one has > nested domains. > > One could conceivably have components that have behavior only (only the > model, the update and the subscriptions but no view) and that can be > interrogated with functions by some parent view. > > The App.program signature is like the border of the App. It specifies what > all the small bits of your program need to compose to. What you do inside > your program is entirely up to you. > > This is why I suggested that you actually try to implement something. > You might be surprised to discover that Elm is actually more powerful than > you first thought. > > > > > On Fri, Jul 1, 2016 at 4:35 PM, Robert Walter <[email protected] > <javascript:>> wrote: > >> Hi Peter, >> >> thanks for the response, it might very well be that Elm already has all >> the capabilities necessary and I'm just not aware of it. Frankly, ports are >> something I definitely have to look into in more detail before responding >> properly to your suggestions. >> >> While it is possible to chain transformations in the view callback (as >> you showed), it seems a bit kludgy to do this. By design, the view function >> returns a "Html msg", so a better description (compared to my initial post) >> of it would be that it is a wrapper around an app's transformation pipeline >> with a clearly defined input (Model) and output (Html msg). >> Adding an explicit "transformations" callback would allow to decouple the >> model and the transformation pipeline a bit (as I understand it, >> Html.App.program makes it mandatory to have the same model type for init, >> update, view, and subscriptions). I'm not saying that this is bad or >> anything, I just try to explore some ideas. The idea is to have "update" >> and "subscriptions" for each intermediate domain. >> >> Imagine a domain A which I don't want to render directly, but transform >> its models into models of an intermediate domain "B". Third party >> developers could pick up this "piece of the chain" and use it's output "B" >> as input to their own programs, enhance the models with their own concepts >> and render everything however they please. They could still send messages >> to my model of "A" and it would update according to the logic in its >> "update" function, transform it to a model of "B", which is then further >> processed by their own transformation(s). >> >> Yes, this is all very theoretical and I should try to think of some more >> specific use cases. And I need to learn more about Elm ports and Effect >> Managers. >> >> Best, >> Robert >> >> >> On Friday, July 1, 2016 at 1:50:17 PM UTC+2, Peter Damoc wrote: >>> >>> Hi Robert, >>> >>> I'm trying to understand what you are requesting and I keep seeing >>> records/ADT for domains and plain old functions for the transformations. >>> In other words, I don't really understand what is the show stopper here. >>> >>> >>> For example, let's say that you want to transform the model into a text >>> only representation and into some sort of audio output and send those to >>> some other output devices. >>> This can easily be accomplished by adding a textOnly port and an audio >>> port and returning from `update` a Cmd.batch of the commands to these >>> ports. >>> >>> If you don't want ports you could probably use some Effect Manager to >>> produce the commands. >>> >>> Also, if you want the model to pass through several transformations >>> before generating the output, you can easily to that like: >>> >>> view model = >>> model >>> |> firstTransformation >>> |> secondTransformation arg1 arg2 >>> |> finalTransformation >>> >>> Maybe if you try to implement what you want and reach a point where you >>> would like to write something and cannot because of current limitations, >>> you could present some mock code with how you would want things to be. >>> >>> >>> >>> >>> On Fri, Jul 1, 2016 at 1:03 PM, Robert Walter <[email protected]> >>> wrote: >>> >>>> Hello all, >>>> >>>> not having a strong web development background, but rather coming from >>>> the area of domain-specific languages, model-driven development, and IDE >>>> development (i.e. building tools for developers and development >>>> platforms), >>>> Elm made me curious because of a lot of the ideas and features that are >>>> built into the language that I know from other technologies. While I >>>> understand that Elm is specifically targeted to make the lives of >>>> front-end >>>> web developers easier and offer them an alternative to JavaScript and the >>>> zoo of libraries there, I'd like to discuss if Elm could become even >>>> bigger >>>> eventually (especially given technologies like Electron that allow us >>>> easily to target the desktop as well). >>>> >>>> One of the key selling points for me is the thoroughness that is used >>>> to identify what we know as the Elm Architecture. Elm guides you to define >>>> a model of your "world" and to specify how this model changes ("update") >>>> due to effects from outside or inside ("subscriptions" and "commands"). >>>> Also, you define how the model is going to be presented to the user >>>> ("view"). And Elm takes care of wiring these components together. It's >>>> great and I see Elm as a great language not only for veterans, but also >>>> for >>>> beginners! >>>> >>>> In model-driven development, there are a lot of similarities, but also >>>> some differences. Often, your world is made up of several domains ("model >>>> schemas"), and you define transformations from one domain to the other. >>>> That means applications are composed of domains that are wired by >>>> transformations. A system that allows you to build applications that work >>>> that way is MPS, by Jetbrains <https://www.jetbrains.com/mps/>, in >>>> case you would like to see an example. >>>> >>>> One could say that we have a simplified version of that in the Elm >>>> Architecture, where we define one domain ("model") and one transformation >>>> ("view") in which we transform our "domain model" to a "rendering model", >>>> that is passed on to a rendering engine for display. >>>> >>>> So, some of you might say "that's all nice and good, but why do you >>>> bring it up"? Well, I really think that there is a lot of potential in the >>>> idea of model-driven development and projectional editing and I feel like >>>> Elm would be an interesting technology to build something like this on due >>>> to its functional nature and thoroughness put into its architecture. I'd >>>> like to discuss this with the community. >>>> >>>> To make things a bit more specific, I wonder what you think about >>>> generalizing the Elm Architecture in a way that we not only transform from >>>> a domain model to a Html model (a.k.a. view), but to allow for a series of >>>> transformations if necessary. I like that the current architecture allows >>>> us to do something like that to a certain degree. Looking at the Mdl >>>> package for example, I consider this a "Widget domain" and I can >>>> incorporate it into my "view" function, basically reusing portions of >>>> their >>>> "domain model to Html" transformation for my own purpuses. >>>> But if I want to use Elm to transform gradually from a model of low >>>> abstraction to Html via intermediate domains, it is hard to do. A >>>> suggestion would be to have an optional callback called "transformations" >>>> that takes in a model of type A and spits out a model of type B, which is >>>> then again used as input for the final transformation step, which would >>>> still be "view". Optional means that, if no transformation is defined, A >>>> == >>>> B. >>>> >>>> I hope all of this does make a little bit of sense to some of you and I >>>> really hope it is not too controversial. >>>> >>>> Best, >>>> Robert >>>> >>>> -- >>>> 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 [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> There is NO FATE, we are the creators. >>> blog: http://damoc.ro/ >>> >> -- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
