Re: [elm-discuss] Unsafe mechanism

[Peter Damoc]

On Mon, Mar 13, 2017 at 11:06 AM, Oliver Searle-Barnes 
wrote:

> What do you think, does this offer a practical route to a greater number
> of pure Elm integration libraries?
>

I seriously doubt it.

The practical route is actually joining forces. It is using multiple pairs
of eyes and multiple brains to solve the Native problem as a community.

Some JS libraries are well designed and their code could be used reasonably
safe within an Elm environment.
You'll still have to assimilate them, that is to adapt their API usage to
the Elm way of managing effects.
This would require a reasonable amount of thought but it can be done and
should be way easier than just reimplementing the functionality in pure
Elm.

In some case, a full reimplementation with Elm paradigms using only bits of
JS code from some source inspiration library might be in order.

In some other cases, the quality of the library is so damn poor and the
assimilation effort is so large that it might make more sense to just write
it from scratch.

The way forward, as I see it, is the generation of a proper documentation
for Native. Not only in the sense of "this is how you do it" but in the
sense of a solid checklist that would make sure you are doing the best that
you can to provide as much reliability as it's possible given the context.

What we have now is the  *AbstinenceONLY™* gospel.
We need proper sex-ed. :)

Just to be explicit, I'm not expecting this from Elm's core team. This
should be a product of the community.
In the absence of this semi-official approach, people will hit unmet needs
like the above mentioned firebase integration and the will try to fulfill
them using Native, potentially breaking a lot of the good practices for
Native code.



-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Unsafe mechanism

[Oliver Searle-Barnes]

(prompted by discussion of firebase integration on elm-dev)

Given that it would be really helpful to have more integration libraries 
available for Elm (auth0, firebase, aws...) I've been wondering if the 
current state of affairs is ideal for achieving:

1) Maximum number of integration libraries available for Elm
2) All of those implemented in pure Elm

Currently the path to get there appears to be:

1) Use an existing javascript library and wrap it using ports
2) Reimplement the library in Elm

1 to 2 often represents a significant amount of development. Because ports 
preclude a library from being published in http://package.elm-lang.org/ and 
elm package doesn't support installing them from anywhere else there's a 
social pressure to not implement effect managers or release libraries that 
make use of ports. 

Another path get to pure Elm libraries might be

1) Use an existing javascript library and wrap it using ports or native 
functions
2) Release it as a library
3) Gradually migrate the library over to pure Elm with the help of any 
members of the community that need it

The concern here is obviously that your Elm code can now blow up and 
there's no way of knowing which code is unsafe. 

What if unsafe because a first class concept in Elm? You could mark 
functions as "unsafe". Any function that calls an unsafe function would 
also be required to be declared as unsafe  e.g.


unsafe attemptAuth : LoginDetails -> Task String AuthStatus
unsafe attemptAuth loginDetails =
Native.WrappedLibrary.attemptAuth loginDetails




type Msg
= unsafe AuthResponse (Result String AuthStatus)



unsafe update : Msg -> Model -> (Model, Cmd Msg)
unsafe update msg model =
case msg of
AuthResponse status ->




This would make it possible to do a first pass on integration by just 
delegating to the javascript implementation. It's now very clear which of 
your Elm code is safe and unsafe. Having that unsafe keyword not only let's 
you know which code carries the Elm safety guarantees (if a function isn't 
marked unsafe) but you now also have this unsafe keyword stinking up your 
code encouraging you to reimplement it in pure Elm. You're using a shared 
library now though so whenever you replace a javascript implementation with 
a safe Elm version everyone benefits.

What do you think, does this offer a practical route to a greater number of 
pure Elm integration libraries?







-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.