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]> 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]. > 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.
