Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Simon]

> * A "foreign" value type that could capture a reference coming from 
JavaScript to be handed back in other calls.

We already have that with Json.Encode.Value, and it can be passed to from 
javascript: see this example for Google maps 
, which I 
copied from how Evan built websockets

Simon


On Thursday, 8 December 2016 19:28:22 UTC+1, 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  > 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 .
>>
>>
>> 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.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

Having external compute run asynchronously opens the possibility of having
it run in parallel some day. That said, if Elm were to emphasize that sort
of programming, it might drive some shifts in how other pieces are
structured. The world is going async — see node.js — but it's a painful
process. Tasks might be enough but I don't know that anyone has written a
complex process around tasks and any such process wouldn't leverage the Elm
debugger. A bigger problem is that once you ask for something to be
computed, it really helps if there is a way to say "nevermind". Reactive
networks also help hide some of the management issues for this sort of work
but Elm has been moving away from those.

So, I embrace async tasks but I think they also then need to be embraced by
the language/runtime/app-architecture.

Mark

On Wed, Dec 14, 2016 at 9:03 PM, Desmond D'Souza 
wrote:

>
>
> On Wednesday, December 14, 2016 at 1:30:48 PM UTC-6, Rupert Smith wrote:
>>
>> On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
>>>
>>> I would love to be able to make synchronous functional calls to js and
>>> get a Result back.
>>>
>>
>> Would you want to publish this code to elm-package?
>>
>
> Yes.
>
>
>>
>> Would the javascript your package calls be included in the package?
>>
>
> I don't know, but do have a naive answer. If I had written all of it in
> Elm, split into App.elm and GraphLayout.elm, I could publish both modules
> bundled into a single package or split into two, and Elm + elm-package
> spells out what a *package user* needs to know and do in both cases. If
> GraphLayout is in javascript, the overall package story should stay as
> close as reasonably possible *for the package user, *and Elm +
> elm-package should spell out what that user needs to know and do.
>
> --
> 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.
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Desmond D'Souza]

On Wednesday, December 14, 2016 at 1:30:48 PM UTC-6, Rupert Smith wrote:
>
> On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
>>
>> I would love to be able to make synchronous functional calls to js and 
>> get a Result back.
>>
>
> Would you want to publish this code to elm-package?
>

Yes. 
 

>
> Would the javascript your package calls be included in the package? 
>

I don't know, but do have a naive answer. If I had written all of it in 
Elm, split into App.elm and GraphLayout.elm, I could publish both modules 
bundled into a single package or split into two, and Elm + elm-package 
spells out what a *package user* needs to know and do in both cases. If 
GraphLayout is in javascript, the overall package story should stay as 
close as reasonably possible *for the package user, *and Elm + elm-package 
should spell out what that user needs to know and do.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Desmond D'Souza]

On Wednesday, December 14, 2016 at 12:18:01 PM UTC-6, Joey Eremondi wrote:
>
> Sure, I could abuse it to call a stateful js ap
>
>
> Which you can currently do with Cmd ports! We'd just want to wrap it in 
> some type like Task or Cmd, and then it would be nicely segregated from 
> pure code. 
>

Correct. I phrased that badly, I meant

 "*Sure, I could call supposedly pure js code to compute a value, but that 
js happens to have some unintended side effect or stateful behavior, 
causing problem if the Elm compiler ...*".

 
Task or Cmd would still be the right way to do all *intentional* side 
effects or communication. But calling some js loaded in the browser right 
alongside my Elm code to synchronously compute *layout(graph) *should be 
handled as similarly as possible to doing all the computation in Elm 
itself. 
 

>
> On Wed, Dec 14, 2016 at 10:00 AM, Desmond D'Souza  > wrote:
>
>> I would love to be able to make synchronous functional calls to js and 
>> get a Result back. 
>>
>> Taking simple clean synchronous functional code (e.g. if it were all in 
>> Elm), and being forced to chop out bits into async calls with async Msg 
>> callbacks (just because it is not all in Elm) impacts my code in unpleasant 
>> ways: 
>>
>>1. weird async bugs: will my originally sync call to *layout(graph)* get 
>>the layout answer back *after *the user has switched to another graph?
>>2. pollution of model and update: 
>>   - I need to stuff into my model bits that were simple transient 
>>   local variables before, and maintain those extra bits everywhere in my 
>>   code. Forget to clear them somewhere, and chunks of my code like 
>> another 
>>   update branch or a view function, think I have a current graph waiting 
>> for 
>>   a layout.
>>   - I add more checks into my update to deal with possibly getting 
>>   intervening unrelated async inputs
>>   3. API bloat: why does *AndHereIsYourLayoutBack* need to be part 
>>of my API, when that is already explicit through the outgoing call 
>>mechanism (e.g. via something like a synchronous port, or some 
>> alternative)
>>
>> I think #1 would be somewhat alleviated by synchronous tasks from this 
>> thread 
>> ,
>>  
>> but #2 and #3 remain. 
>>
>> Properly supporting this use case would be good for Elm. Sure, I could 
>> abuse it to call a stateful js api, causing problems if the Elm compiler 
>> moves expression evaluation order around, hence I use some *unsafe* marker 
>> either as an annotation to myself or to the compiler.
>>
>>
>> On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote:
>>>
>>>
>>>
>>> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:

 the elm package repo would very quickly get poluted with js code that 
> causes runtime exceptions


 But, Tasks have error handling built into them. We could do something 
 similar with synchronous code, just catch any exceptions thrown, and treat 
 the value in Elm as something like a Result.

>>>
>>> > the elm package repo would very quickly get poluted with js code that 
>>> causes runtime exceptions _* and is not portable *_
>>>
>>> Result would work, but the not portable bit is equally impoertant.
>>>  
>>>
>> -- 
>> 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 .
>> 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.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Wednesday, December 14, 2016 at 6:00:14 PM UTC, Desmond D'Souza wrote:
>
> I would love to be able to make synchronous functional calls to js and get 
> a Result back.
>

Would you want to publish this code to elm-package?

Would the javascript your package calls be included in the package? 

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Joey Eremondi]

>
> Sure, I could abuse it to call a stateful js ap


Which you can currently do with Cmd ports! We'd just want to wrap it in
some type like Task or Cmd, and then it would be nicely segregated from
pure code.

On Wed, Dec 14, 2016 at 10:00 AM, Desmond D'Souza 
wrote:

> I would love to be able to make synchronous functional calls to js and get
> a Result back.
>
> Taking simple clean synchronous functional code (e.g. if it were all in
> Elm), and being forced to chop out bits into async calls with async Msg
> callbacks (just because it is not all in Elm) impacts my code in unpleasant
> ways:
>
>1. weird async bugs: will my originally sync call to *layout(graph)* get
>the layout answer back *after *the user has switched to another graph?
>2. pollution of model and update:
>   - I need to stuff into my model bits that were simple transient
>   local variables before, and maintain those extra bits everywhere in my
>   code. Forget to clear them somewhere, and chunks of my code like another
>   update branch or a view function, think I have a current graph waiting 
> for
>   a layout.
>   - I add more checks into my update to deal with possibly getting
>   intervening unrelated async inputs
>   3. API bloat: why does *AndHereIsYourLayoutBack* need to be part of
>my API, when that is already explicit through the outgoing call mechanism
>(e.g. via something like a synchronous port, or some alternative)
>
> I think #1 would be somewhat alleviated by synchronous tasks from this
> thread
> ,
> but #2 and #3 remain.
>
> Properly supporting this use case would be good for Elm. Sure, I could
> abuse it to call a stateful js api, causing problems if the Elm compiler
> moves expression evaluation order around, hence I use some *unsafe* marker
> either as an annotation to myself or to the compiler.
>
>
> On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote:
>>
>>
>>
>> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:
>>>
>>> the elm package repo would very quickly get poluted with js code that
 causes runtime exceptions
>>>
>>>
>>> But, Tasks have error handling built into them. We could do something
>>> similar with synchronous code, just catch any exceptions thrown, and treat
>>> the value in Elm as something like a Result.
>>>
>>
>> > the elm package repo would very quickly get poluted with js code that
>> causes runtime exceptions _* and is not portable *_
>>
>> Result would work, but the not portable bit is equally impoertant.
>>
>>
> --
> 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.
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Desmond D'Souza]

I would love to be able to make synchronous functional calls to js and get 
a Result back. 

Taking simple clean synchronous functional code (e.g. if it were all in 
Elm), and being forced to chop out bits into async calls with async Msg 
callbacks (just because it is not all in Elm) impacts my code in unpleasant 
ways: 

   1. weird async bugs: will my originally sync call to *layout(graph)* get 
   the layout answer back *after *the user has switched to another graph?
   2. pollution of model and update: 
  - I need to stuff into my model bits that were simple transient local 
  variables before, and maintain those extra bits everywhere in my code. 
  Forget to clear them somewhere, and chunks of my code like another update 
  branch or a view function, think I have a current graph waiting for a 
  layout.
  - I add more checks into my update to deal with possibly getting 
  intervening unrelated async inputs
  3. API bloat: why does *AndHereIsYourLayoutBack* need to be part of 
   my API, when that is already explicit through the outgoing call mechanism 
   (e.g. via something like a synchronous port, or some alternative)

I think #1 would be somewhat alleviated by synchronous tasks from this 
thread 
, 
but #2 and #3 remain. 

Properly supporting this use case would be good for Elm. Sure, I could 
abuse it to call a stateful js api, causing problems if the Elm compiler 
moves expression evaluation order around, hence I use some *unsafe* marker 
either as an annotation to myself or to the compiler.


On Wednesday, December 14, 2016 at 4:48:06 AM UTC-6, Rupert Smith wrote:
>
>
>
> On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:
>>
>> the elm package repo would very quickly get poluted with js code that 
>>> causes runtime exceptions
>>
>>
>> But, Tasks have error handling built into them. We could do something 
>> similar with synchronous code, just catch any exceptions thrown, and treat 
>> the value in Elm as something like a Result.
>>
>
> > the elm package repo would very quickly get poluted with js code that 
> causes runtime exceptions _* and is not portable *_
>
> Result would work, but the not portable bit is equally impoertant.
>  
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 13, 2016 at 3:42:23 PM UTC, Joey Eremondi wrote:
>
> the elm package repo would very quickly get poluted with js code that 
>> causes runtime exceptions
>
>
> But, Tasks have error handling built into them. We could do something 
> similar with synchronous code, just catch any exceptions thrown, and treat 
> the value in Elm as something like a Result.
>

> the elm package repo would very quickly get poluted with js code that 
causes runtime exceptions _* and is not portable *_

Result would work, but the not portable bit is equally impoertant.
 

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

I basically look on it as code that exists to make Elm run at all. That's
basically what Native exists for. (Native also plays games with the type
system but that's another matter.)

And then there's external code that I would like to run that isn't critical
to Elm being Elm. That seems a natural place to deploy Tasks.

Mark

On Tue, Dec 13, 2016 at 8:06 PM, Mark Hamburg  wrote:

> Then people would complain that all native calls returned Results rather
> than the type they wanted returned.
>
> Mark
>
> On Tue, Dec 13, 2016 at 7:42 AM, Joey Eremondi 
> wrote:
>
>> the elm package repo would very quickly get poluted with js code that
>>> causes runtime exceptions
>>
>>
>> But, Tasks have error handling built into them. We could do something
>> similar with synchronous code, just catch any exceptions thrown, and treat
>> the value in Elm as something like a Result.
>>
>> --
>> 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.
>>
>
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

Then people would complain that all native calls returned Results rather
than the type they wanted returned.

Mark

On Tue, Dec 13, 2016 at 7:42 AM, Joey Eremondi 
wrote:

> the elm package repo would very quickly get poluted with js code that
>> causes runtime exceptions
>
>
> But, Tasks have error handling built into them. We could do something
> similar with synchronous code, just catch any exceptions thrown, and treat
> the value in Elm as something like a Result.
>
> --
> 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.
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Joey Eremondi]

>
> the elm package repo would very quickly get poluted with js code that
> causes runtime exceptions


But, Tasks have error handling built into them. We could do something
similar with synchronous code, just catch any exceptions thrown, and treat
the value in Elm as something like a Result.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 13, 2016 at 4:19:31 AM UTC, Mark Hamburg wrote:
>
> One doesn't need them to be asynchronous but making them asynchronous 
> helps reinforce the notion that this is happening outside the Elm universe. 
> And if you want monads, Elm's tasks are monadic.
>

I really want to disagree with you because it makes it a PITA when you just 
want to call a pure function written in js, but I have to concede that you 
are right. If making simple synchronous calls to javascript was the 
supported mechanism for interfacing, the elm package repo would very 
quickly get poluted with js code that causes runtime exceptions and it not 
portable. 

Another advantage is that it encourages people to write pure functions in 
Elm in order to share their work, and we all benefit from that.

Best thing to tell people looking for 'unsafe' modules in Elm then, is to 
tell them that we already have them it is just that the keyword is 
'native', and that the platform is protected from such unsafe code by not 
officially supporting it.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

A better way of putting this: Haskell's IO monad structures a particular
set of interactions with the outside world. By making all foreign
interactions go through tasks, Elm could use its task monad to structure
interactions with the outside world. The difference then is that Haskell
has more syntactic sugar around monads than Elm does.

Mark

On Mon, Dec 12, 2016 at 8:19 PM, Mark Hamburg  wrote:

> One doesn't need them to be asynchronous but making them asynchronous
> helps reinforce the notion that this is happening outside the Elm universe.
> And if you want monads, Elm's tasks are monadic.
>
> Mark
>
> On Mon, Dec 12, 2016 at 6:16 AM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com> wrote:
>
>> On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote:
>>>
>>> While there are certainly times when synchronous calls would have been
>>> nice, I recognize that having synchronous behavior for potentially mutable
>>> external state also tends to imply a lot about execution order — something
>>> that a pure functional language expects to be more free about. Hence, I
>>> think it's reasonable to force operations that need to deal with the
>>> external world to be asynchronous.
>>>
>>
>> Consider monads in other fp langauges. You don't need to have an
>> asynchronous model to work with external state and side effects.
>>
>> I suppose you could describe Elm's event driven loop as a monad, in the
>> sense that it chains together sequences of functions over messages.
>>
>> --
>> 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.
>>
>
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

One doesn't need them to be asynchronous but making them asynchronous helps
reinforce the notion that this is happening outside the Elm universe. And
if you want monads, Elm's tasks are monadic.

Mark

On Mon, Dec 12, 2016 at 6:16 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote:
>>
>> While there are certainly times when synchronous calls would have been
>> nice, I recognize that having synchronous behavior for potentially mutable
>> external state also tends to imply a lot about execution order — something
>> that a pure functional language expects to be more free about. Hence, I
>> think it's reasonable to force operations that need to deal with the
>> external world to be asynchronous.
>>
>
> Consider monads in other fp langauges. You don't need to have an
> asynchronous model to work with external state and side effects.
>
> I suppose you could describe Elm's event driven loop as a monad, in the
> sense that it chains together sequences of functions over messages.
>
> --
> 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.
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Friday, December 9, 2016 at 8:07:33 PM UTC, Mark Hamburg wrote:
>
> While there are certainly times when synchronous calls would have been 
> nice, I recognize that having synchronous behavior for potentially mutable 
> external state also tends to imply a lot about execution order — something 
> that a pure functional language expects to be more free about. Hence, I 
> think it's reasonable to force operations that need to deal with the 
> external world to be asynchronous.
>

Consider monads in other fp langauges. You don't need to have an 
asynchronous model to work with external state and side effects.

I suppose you could describe Elm's event driven loop as a monad, in the 
sense that it chains together sequences of functions over messages.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Duane Johnson]

On Fri, Dec 9, 2016 at 1:07 PM, Mark Hamburg  wrote:

> operations that need to deal with the external world


The one thing I don't like about Elm is the feeling that it's *hard work*
to deal with the world. I wish it felt like a happy place, a tool I would
easily reach for, or a pleasant experience.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

While there are certainly times when synchronous calls would have been
nice, I recognize that having synchronous behavior for potentially mutable
external state also tends to imply a lot about execution order — something
that a pure functional language expects to be more free about. Hence, I
think it's reasonable to force operations that need to deal with the
external world to be asynchronous.

Mark


On Fri, Dec 9, 2016 at 7:31 AM Vojtěch Král 
wrote:

>
>
> Dne pátek 9. prosince 2016 12:12:43 UTC+1 Rupert Smith napsal(a):
>
> On Thursday, December 8, 2016 at 5:27:53 PM UTC, Vojtěch Král wrote:
>
> 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/
>
>
> If I can quote from that: "In a nutshell, Elm needs unsafe."
>
> I mostly agree with this, but have some reservations.
>
> The existing native API is easy enough to figure out, just look at any
> 'native' module implementation. Basically  you follow the conventions you
> see for namespaing you javascript code and wrapping functions with helpers
> like F2, F3 and so on, and return an object containing all the functions
> you want to expose to Elm.
>
> Also code does not need to be made asynchronous to be made type-safe, you
> could use Result for synchronous calls. Just map all exceptions to Err, and
> succesfull calls to Ok.
>
> It would be nice if we could just mark our own native modules as 'unsafe'
> and have an 'unsafe' section on package.elm-lang.org to share them.
>
>
> Yup. I didn't realize Tasks are this async, thanks for pointing that out.
> +1 to your email.
>
>
>
>
>
>
>
>
>
> --
>
>
> 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.
>
>
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Vojtěch Král]

Dne pátek 9. prosince 2016 12:12:43 UTC+1 Rupert Smith napsal(a):
>
> On Thursday, December 8, 2016 at 5:27:53 PM UTC, Vojtěch Král wrote:
>>
>> 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/
>>
>
> If I can quote from that: "In a nutshell, Elm needs unsafe."
>
> I mostly agree with this, but have some reservations.
>
> The existing native API is easy enough to figure out, just look at any 
> 'native' module implementation. Basically  you follow the conventions you 
> see for namespaing you javascript code and wrapping functions with helpers 
> like F2, F3 and so on, and return an object containing all the functions 
> you want to expose to Elm.
>
> Also code does not need to be made asynchronous to be made type-safe, you 
> could use Result for synchronous calls. Just map all exceptions to Err, and 
> succesfull calls to Ok.
>
> It would be nice if we could just mark our own native modules as 'unsafe' 
> and have an 'unsafe' section on package.elm-lang.org to share them. 
>
 
Yup. I didn't realize Tasks are this async, thanks for pointing that out. 
+1 to your email.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Thursday, December 8, 2016 at 5:27:53 PM UTC, Vojtěch Král wrote:
>
> 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/
>

If I can quote from that: "In a nutshell, Elm needs unsafe."

I mostly agree with this, but have some reservations.

The existing native API is easy enough to figure out, just look at any 
'native' module implementation. Basically  you follow the conventions you 
see for namespaing you javascript code and wrapping functions with helpers 
like F2, F3 and so on, and return an object containing all the functions 
you want to expose to Elm.

Also code does not need to be made asynchronous to be made type-safe, you 
could use Result for synchronous calls. Just map all exceptions to Err, and 
succesfull calls to Ok.

It would be nice if we could just mark our own native modules as 'unsafe' 
and have an 'unsafe' section on package.elm-lang.org to share them.

>From what I've read about it, there is a another aspect to this that the 
keyword 'unsafe' doesn't quite cover. Elm could also run in a different 
environment to browser + javascript. To take a hypothetical example, it 
could be ported for writing native Windows applications. In which case the 
native parts of the platform that are currently written in javascript might 
end up getting rewritten as say C#. Then the exact same Elm code could 
produce a web application or a native windows application. For Android it 
would be Java, you get the idea.

So we'd need a keyword and understanding about lack of potential forward 
compatability that expresses this, were there to be a way to provide some 
degree of official recognition that people want to write and share native 
code. Perhaps its an 'unsafe javascript elm18 module' that we need...

I like that Evan has had the foresight to prevent Elm being locked in to 
its current runtime environment in order to keep options open for the 
future. If I need to delve into hacking javascript to do something that I 
can't do otherwise, I'm happy enough with taking the risk of no forward 
compatability, because I'm using the version of Elm that I currently have, 
to solve problems that I currently need to solve, and finding that Elm is 
good enough to be worth making an exception for. As I say, there is always 
elm-github-install for the hackers.

 

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Wil C]

So now, either I write a ports for commonmark.js, or I write it as a native 
>> module. I asked about it here 
>>  with 
>> no answers. 
>>
>
> I think if you write it as ports or native, you'll still need to map the 
> AST between javascript and Elm. As a native module that could be done with 
> a Decoder or by constructing the Elm AST in native code with Javascript. 
> Perhaps Decoders are not so bad?
>

In the case of using commonmark.js, I didn't use a decoder. Taking a page 
out of the elm-markdown playbook, I call directly into VirtualDom's js calls 
. 
My guess is that Evan did it as a hack. And since it's not a published API, 
I don't expect it to stick around. Reaching into a private API is usually 
bad news. I chose not to write decoders in this case, because I'm using 
commonmark.js already, so it's not like I could share the code as a lib. 
And it's admittedly a shortcut.

In the case of parsing SQL, I did end up using a decoder. I sent the sql 
string into a port, had it parsed and returned as JSON representing an AST, 
that fed back into a subscription port that I then decoded into union types 
.
 

> I don't think a parser is a side-effect. A parser is a pure function from 
> String -> Ast, with no side effects.
>

Technically, no. That's why I was asking about a native module API, since I 
just copied elm-markdown.
 

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

Well, since there's no official documentation on a native module API, ports 
is what I can rely on. But from a semantics point of view, since I'm 
calling out to something that might have a side effect, it makes sense. 
It's just the mechanics is a bit awkward. I've had the pleasure of swimming 
in his design decisions in Elm so far, and he's built up enough cred with 
me that I think he'll figure something out.

I was just looking for some guidance as to what to implement in pure elm, 
and what to leverage native modules for. Even in other languages where new 
libraries are implemented completely in that language (like ruby, per the 
original post on native modules a year ago), there are libraries that call 
out. The main one that comes to mind is the Linear Algebra Package (LAPACK) 
originally written in Fortran, but most languages that use it now are 
usually just wrappers around it. I just wondered where Elm community drew 
the line.

Wil

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Thursday, December 8, 2016 at 5:27:53 PM UTC, Vojtěch Král wrote:
>
> 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.
>

I'm not sure that calling Javascript as a Task solves the issues you 
brought up. Specifically that an ordinary function call becomes 
asynchronous - you have to then schedule the task to be run and get back 
the result as a msg to your update function. Sometimes you just want to 
call a foreign function and get the answer back right away.

Of course, with native modules it is very easy to do this already with Elm. 
You just can't publish a package with it in to the official repo. 

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[OvermindDL1]

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

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 
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+unsubscr...@googlegroups.com.
>
>
> 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.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Vojtěch Král]

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Mark Hamburg]

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)?
When the goal is to do some external computation, ports feel awkward as a
mechanism. Something like:

port parseMarkdown : String -> Task Error Json.Decode.Value

(I'm handwaving here because I don't know what Error should be.)

One would wire up parseMarkdown in much the same way as other ports
possibly using something like JavaScript promises to allow for long
computations.

The arguable downside to this sort of interop is that it doesn't really
provide a good way to build modules that can be distributed to others since
the ports need to be connected in the app launch code. But that's true of
other port types as well.

Mark

On Tue, Dec 6, 2016 at 2:14 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Tuesday, December 6, 2016 at 7:32:49 PM UTC, Rupert Smith wrote:
>>
>> On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote:
>>>
>>> So now, either I write a ports for commonmark.js, or I write it as a
>>> native module. I asked about it here
>>>  with
>>> no answers.
>>>
>>
>> I think if you write it as ports or native, you'll still need to map the
>> AST between javascript and Elm. As a native module that could be done with
>> a Decoder or by constructing the Elm AST in native code with Javascript.
>> Perhaps Decoders are not so bad?
>>
>> I don't think a parser is a side-effect. A parser is a pure function from
>> String -> Ast, with no side effects.
>>
>
> 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.
>
> --
> 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.
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Simon]

Are there additional restrictions on using native code? I installed a 
library with native code using elm-github-install. As far as I can see 
`"native-modules": true` is set in the library but it still cannot find the 
native code, whereas the native code from the http library that is also in 
the project is read.

Simon

On Tuesday, 6 December 2016 23:14:06 UTC+1, Rupert Smith wrote:
>
> On Tuesday, December 6, 2016 at 7:32:49 PM UTC, Rupert Smith wrote:
>>
>> On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote:
>>>
>>> So now, either I write a ports for commonmark.js, or I write it as a 
>>> native module. I asked about it here 
>>>  with 
>>> no answers. 
>>>
>>
>> I think if you write it as ports or native, you'll still need to map the 
>> AST between javascript and Elm. As a native module that could be done with 
>> a Decoder or by constructing the Elm AST in native code with Javascript. 
>> Perhaps Decoders are not so bad?
>>
>> I don't think a parser is a side-effect. A parser is a pure function from 
>> String -> Ast, with no side effects.
>>
>
> 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. 
>

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 6, 2016 at 7:32:49 PM UTC, Rupert Smith wrote:
>
> On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote:
>>
>> So now, either I write a ports for commonmark.js, or I write it as a 
>> native module. I asked about it here 
>>  with 
>> no answers. 
>>
>
> I think if you write it as ports or native, you'll still need to map the 
> AST between javascript and Elm. As a native module that could be done with 
> a Decoder or by constructing the Elm AST in native code with Javascript. 
> Perhaps Decoders are not so bad?
>
> I don't think a parser is a side-effect. A parser is a pure function from 
> String -> Ast, with no side effects.
>

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. 

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

['Rupert Smith' via Elm Discuss]

On Tuesday, December 6, 2016 at 5:18:04 PM UTC, Wil C wrote:
>
> So now, either I write a ports for commonmark.js, or I write it as a 
> native module. I asked about it here 
>  with no 
> answers. 
>

I think if you write it as ports or native, you'll still need to map the 
AST between javascript and Elm. As a native module that could be done with 
a Decoder or by constructing the Elm AST in native code with Javascript. 
Perhaps Decoders are not so bad?

I don't think a parser is a side-effect. A parser is a pure function from 
String -> Ast, with no side effects.

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

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Wil C]

I'm building a document editor with executable code in it. So far, I have 
SQL embedded in Markdown. 

For markdown, I needed flexibility in changing the output from the standard 
HTML output, like adding extra info around a code block. I looked at 
elm-markdown, and found it didn't have this flexibility. In addition, it 
embedded a minified version of marked.js inside of it. 

Looked into parsing markdown briefly, and discovered it's not even a BNF, 
and would probably spend a lot of time writing the parser. I found 
commonmark.js. 

So now, either I write a ports for commonmark.js, or I write it as a native 
module. I asked about it here 
 with no 
answers. 

I decided to write it as a native module with elm-markdown.js as a 
template. It's a bit messy in there, because 1) I'm proving out a concept, 
but also, 2) I'm not sure what is considered good practice. I had looked at 
a few other libs with native modules, and it seemed like they were using an 
API of some sort, rather than directly using namespaces like 
"_elm_lang$virtual_dom$Native_VirtualDom"

That's why I was asking. In cases where it's an integration library, like 
talking to the twitter API, I think it makes sense to write it entirely in 
Elm. Might be boring work, but it's doable. But what about things like 
parsers? If you find a parser in JS (ie. code above a certain complexity 
threshold) for a language, should you try to rewrite it in Elm? My guess is 
ideally, yes. But often times, I'm under a time crunch, or I'm more 
interested in proving out a concept to myself, so diving down to take the 
time to write a parser didn't make sense for me this time.

Wil

On Monday, December 5, 2016 at 9:22:42 AM UTC-8, Richard Feldman wrote:
>
> No new thinking on that as far as I'm aware...what are you looking to 
> build?
>
> On Mon, Dec 5, 2016, 8:37 AM Wil C  wrote:
>
>> Do you know if there's going to be a guide on native modules? I just used 
>> elm-markdown as a guide, but I saw there were other conventions in other 
>> libraries with native modules.
>>
>> I understand the hesitation in giving a guide on an escape hatch to 
>> native, since people will instinctively reach for it. Just was wondering if 
>> there was new thinking on it.
>>
>>
>> On Monday, December 5, 2016 at 8:19:14 AM UTC-8, Richard Feldman wrote:
>>>
>>> Looking at the evancz/elm-markdown 
>>>  parser, that seems like a case 
>>> that warrants it, yeah.
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/nuR4NnCVcMs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss...@googlegroups.com .
>> 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.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[W. Brian Gourlie]

Not OP but a guide would be useful for contributing to existing libraries. 
 For example, the websocket library is lacking some features 
(https://github.com/elm-lang/websocket/issues/14) that I would like to try 
and implement.  The two things that suck right now: No documentation for 
the native framework, and, not sure if it would be in vain since Evan is 
highly opinionated (and rightly so) on API design, and I have no idea if 
whatever I implement would meet his standard.

On Monday, December 5, 2016 at 11:22:42 AM UTC-6, Richard Feldman wrote:
>
> No new thinking on that as far as I'm aware...what are you looking to 
> build?
>
> On Mon, Dec 5, 2016, 8:37 AM Wil C  wrote:
>
>> Do you know if there's going to be a guide on native modules? I just used 
>> elm-markdown as a guide, but I saw there were other conventions in other 
>> libraries with native modules.
>>
>> I understand the hesitation in giving a guide on an escape hatch to 
>> native, since people will instinctively reach for it. Just was wondering if 
>> there was new thinking on it.
>>
>>
>> On Monday, December 5, 2016 at 8:19:14 AM UTC-8, Richard Feldman wrote:
>>>
>>> Looking at the evancz/elm-markdown 
>>>  parser, that seems like a case 
>>> that warrants it, yeah.
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/nuR4NnCVcMs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss...@googlegroups.com .
>> 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.

Re: [elm-discuss] Re: Stance on native APIs for 0.18?

[Richard Feldman]

No new thinking on that as far as I'm aware...what are you looking to build?

On Mon, Dec 5, 2016, 8:37 AM Wil C  wrote:

> Do you know if there's going to be a guide on native modules? I just used
> elm-markdown as a guide, but I saw there were other conventions in other
> libraries with native modules.
>
> I understand the hesitation in giving a guide on an escape hatch to
> native, since people will instinctively reach for it. Just was wondering if
> there was new thinking on it.
>
>
> On Monday, December 5, 2016 at 8:19:14 AM UTC-8, Richard Feldman wrote:
>
> Looking at the evancz/elm-markdown
>  parser, that seems like a case
> that warrants it, yeah.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/nuR4NnCVcMs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> 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.