`opaque type DBConnection` perhaps would be the common way to write such a
type that can only be passed in and passed out but not created.
On Thursday, December 8, 2016 at 11:28:22 AM UTC-7, Mark Hamburg wrote:
>
> I was talking about this further with my coworkers and we more or less
> agreed that the key things that could help with Elm's interface to
> JavaScript were:
>
> * Task ports. Tasks are a building block in a way that commands are not.
> Forcing all external interactions to be asynchronous makes it more clear
> that one is stepping outside and code could fail.
>
> * A "foreign" value type that could capture a reference coming from
> JavaScript to be handed back in other calls. For example, though not a
> great JavaScript example, this could be a database connection. All
> operations on the database would occur via tasks. We just need an easy way
> for Elm to hold the handle to the database connection. This functionality
> would be better if the foreign types could be distinguished within Elm in
> their declaration — e.g.
>
> port type DBConnection
>
> ("port" reads wrong but I was avoiding introducing a new keyword.)
>
> That said, one could also just use Foreign as a base type and use Elm code
> wrap it in more meaning for the type checker:
>
> type DBConnection = DBConnection Foreign
>
> This, however, probably makes it harder to use the types safely in the
> task APIs.
>
> Would those two features address everything needed? No. In particular,
> port wireup inhibits creating libraries. But it would make it much more
> straightforward for any individual project to build interfaces to
> JavaScript-based functionality.
>
> Mark
>
> On Thu, Dec 8, 2016 at 9:27 AM Vojtěch Král <vojtechkr...@gmail.com
> <javascript:>> wrote:
>
>>
>> Dne úterý 6. prosince 2016 23:14:06 UTC+1 Rupert Smith napsal(a):
>>
>>> The thing about ports for something like this is it feels a bit
>>> unnatural to invoke the port resulting in a Cmd. Then you'll need a
>>> subscription port to get the result back in, and have that pass it to your
>>> update function from where you can take it and place it in the model. That
>>> doesn't feel like a good way to call a function : String -> Ast.
>>>
>>> I'd say the best solution is to implemented your parser in pure Elm. But
>>> if that is too much work, just hack together a native module that calls out
>>> to commonmark.js. You won't be able to publish your native module to elm
>>> packages, but that's ok, perhaps no-one else really wants your markdown
>>> with embedded SQL anyway, and if they do there is always
>>> elm-github-install. Some time down the road when you really need to share
>>> this amazing library, redo it in pure Elm.
>>>
>>
>> This resonates with me very much. This is _exactly_ the reason why I made
>> The Elm Alienation post on Reddit:
>> https://www.reddit.com/r/elm/comments/5g3540/the_elm_alienation/
>>
>> I also wanted to ask here about the status of the Native API but I'm
>> seeing you guys already inquired.
>>
>> Forcing people to rewrite everything in Elm is a terrible idea.
>>
>>
>> Dne středa 7. prosince 2016 17:18:37 UTC+1 Mark Hamburg napsal(a):
>>
>>> Would
>>>
>>> it help if there were a standard mechanism to invoke JavaScript code as
>>>
>>> a task (or equivalently to make JavaScript code available as a task)?
>>>
>>
>> Yes! Very much! If this happened, I'd definitely revisit the decision to
>> leave Elm.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> 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...@googlegroups.com <javascript:>.
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
--
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.
