I can’t judge for certain what the compiler could cope with, but some sort of specific indication that you are branching into js seems helpful in general.
What interests me in this area is when it will be possible to distribute code using ports via packages.elm-lang. Given the mantra of ‘use ports, use ports,…’ we need to make it possible to use them in a re-usable way
The trouble is, I would download you package and find that it did not work because I need to also install its port driver. If the port driver were also downloaded automatically, it is the same thing as a free for all on native code, and then the Elm platform will grow in an uncontrolled way and the user experience may suffer.
The proposed idea here is not tied to the elm-ports-driver. It is simply a proposal that would simplify the language and eliminate a class of issues. It is also aligned with the way some people already do the ports code.
Sure, it would simplify the elm-ports-driver project too (on both sides) but that’s an added benefit.
I’m not arguing here for automatic downloads of JS code. A project like elm-ports-driver that could automate some of the things the currently are done with ports cannot be compared with Native because it is outside of the Elm code. You cannot use such a project to break the guarantees of Elm. Also, changes in the Kernel code do not affect in any way a project like this. Even moving the entire Kernel to something like WebAssembly would still not affect a project like this because it is entirely decoupled from Elm compiled code by the ports.
I don’t see that as broken out-of-the-box. Just because something requires you to have an extra step it does not mean that is broken out-of-the-box. elm-mdl behaves like this instructing its users to install the needed MDL css file in the output. I don’t think elm-mdl is broken out-of-the-box.
I also think that not allowing ports to be published encourages new solutions to be developed purely in Elm, versus just wrapping some .js library. If I am not mistaken, I think Richard said that in 0.19 there is only going to be 1 wrapped .js library left, and that will be evancz/elm-markdown. (Presumably because the documentation sites depend on it.)
I suppose our points of view are kind of academic anyway, as Even seems to have made his preferred direction of travel clear. I’m ok to sail with the good ship Elm.
Is your thinking along these lines: If there is just one input function and one output, there is no need to define any more ports than these. All we need is a Program type with input and output in it, and since these never change they might as well be allowed to be published.
Most likely instances of this Program type would not be published to the packages site anyway, as we do not have a way to compose Programs?
I think that’s exactly where this should go. Make input and output ports as a part of Html.Program types, and then it’s a part of the application, and not libraries that would be published. It makes total sense since ports are an application (and not a library) concern.
Yes, I’m arguing for providing a way to define Programs that have these facilities included. As I said, the special ports syntax can be dropped by replacing it with a output: Value -> Cmd function and a special program that can take a decoder. Alternatively, the input can be input : (Value -> msg) -> Sub msg but I would prefer the decoder variant because the subscription variant enforces the use of a NoOp msg.
I don’t see how getting rid of ports would create problems that are impossible with the current policy. I would however be interested in learning about such problems.
I do not see why someone would want to publish an instance of a program like this. It would be useless from inside Elm. In any case, I think 0.19 will make a difference between application and package and I’m perfectly fine with banning Program altho I don’t see the point.