Run **native** Elm on your server and your terminal! Yes, native!

[wolfadex]

@rupert

One way it could be accomplished could be by tagging packages with capabilities. But this would mean they are course grained at the package level.

I think this would have downstream impacts on

@wolfadex

Like I could see a future where elm-ui renames Element.layout to Element.toHtml, and adds Element.toTui and Element.toView which respectively return Terminal.Tui.View.View msg and some native graphical type. This would make elm-ui 99% just Elm code and then there’d be 3 platform specific functions for converting to the appropriate platform type.

correct? I wouldn’t want my hypothetical elm-uipackage to require all possible output types/restrictions when I can easily control that with basic types.

toHtml : Element msg -> Html.Html msg

toTui : Element msg -> Terminal.Tui.View.View msg

already constrain my code in meaningful ways, and similarly

someTask : SpecificCapability -> Task e a

someCmd : SpecificCapability -> Cmd msg

easily and clearly constrain my effects.

---

@rupert

your example you used the capability key “Fs.Stdin” which suggests to me that these capabilities are intended to be more fine-grained than the package level.

I think this matches with the specificity of Browser.Navigation.Key, no?

[dta]

FWIW, this relates to something I think to be a hole in the Elm security model. If a package has a function that returns a Cmd, there is no type-level guarantee that it’s not making a network request (and exfiltrating my data) in the way that there is with a function that something other than a command (and in the way that is impossible to achieve in most other languages!). If I were designing this, I would probably forbid packages from creating Cmds directly, and instead require passing them factory functions so the application layer would have maximum control over permissions (e.g. only allowing requests to a specific domain).

[damir]

That’s what we designed now with capabilities and demonstrated with the Fs sandbox.

Domains will also have the sandbox model. The “Endgame” chapter in the book already alludes to “… set up a policy 'Never let a program call home, always disable http calls’”, and chapter 4 of the web server book shows an actual UI per URL for programs that call home. (That chapter is not yet in the beta repo).

That will take shape in 0,4.0: “no million --allow-X switches every invocation”

[rupert]

@wolfadex

I wouldn’t want my hypothetical elm-uipackage to require all possible output types/restrictions when I can easily control that with basic types.

toHtml : Element msg -> Html.Html msg

toTui : Element msg -> Terminal.Tui.View.View msg

You are right - with tagged packages you would have to come up with some scheme like splitting this imaginary elm-ui up into elm-ui-core, elm-ui-browser, elm-ui-tui, and so on.

Although even as things stand, suppose we have an elm-run/tui and elm/html and want to make some UI package that consumes both, we have the issue of how to distribute that package to solve. Cannot go on https://package.elm-lang.org/, since that will not have the elm-run/tui dependency.

Or as @dta suggests, dependency injection is used to reverse the dependency arrow.

[allanderek]

@rupert

You are right - with tagged packages you would have to come up with some scheme like splitting this imaginary elm-ui up into elm-ui-core, elm-ui-browser, elm-ui-tui, and so on.

And this has the further problem that in that case, all the types that need to be inspected for toHtml and toTui would have to be visible outside elm-ui-core, which means they would have to be generally visible.

[damir]

A massive Thank You to all of you great Elmers at Elm Camp this year: seeing what you do with Elm is inspiring!

The conversations were just so energizing. I’m back, doubling down on code! Super excited to ship new updates this week and get new contributors involved.

"🫶"