[elm-discuss] Re: launchaco built in Elm

['Rupert Smith' via Elm Discuss]

On Wednesday, December 7, 2016 at 11:32:54 PM UTC, Duane Johnson wrote:
>
> I just saw this (very popular link) on hacker news and was very impressed 
> with the UI. Turns out it's built with Elm and Go!
>
> http://launchaco.com/build/
>

I like how you can edit the templates WYSIWYG, rather than enter markdown.

That is actually what I am planning to with server side Html rendering - 
use the same code to render a view server side in 'view' mode, but have it 
rendered client side in 'edit' mode with inline editing. Nice to see inline 
editing done in 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?

[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]

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?

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

[elm-discuss] Re: Simple Fade In/Out effect?

[Rex van der Spuy]

On Tuesday, October 4, 2016 at 2:46:50 PM UTC-4, Joaquín Oltra wrote:
>
> Here's a mini-example for posterity 
> http://jsbin.com/hipeba/edit?html,css,js,output
>

Thanks Joaquín, I just had an opportunity to use your code snippet and it 
was extremely handy! 

-- 
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] Re: Decoding childNodes textContent

[Laurence Roberts]

For anyone who comes across this, see this PR 
- https://github.com/elm-lang/core/pull/768

On Thursday, 24 November 2016 23:58:27 UTC, Laurence Roberts wrote:
>
> I've become stumped by a json decode issue where the code compiles 
> correctly but does not appear to actually run.
>
> If you run this code below, open your console, enter anything in the 
> editable element and click out of it. I would expect the message `"Write!"` 
> to be logged but it is not. Equally the model is not updated.
>
> Is this an issue with my code or is it a limitation of decoding child 
> nodes? The app works fine if refactored to take a model of `type alias 
> Model = { contents : String }` instead of a `List String`. As far as I 
> can tell the issue seems to lie with attempting to decode `childNodes`. 
> Any ideas?
>
> Thanks!
>
> import List exposing (map)
> import Html exposing (beginnerProgram)
> import Html exposing (Html, article, p)
> import Html.Attributes exposing (style, contenteditable, spellcheck)
> import Html.Events exposing (on)
> import Json.Decode as Decode
>
>
> main : Program Never Model Message
> main =
> beginnerProgram { model = model, view = view, update = update }
>
>
> -- MODEL
>
> type alias Model =
> { contents : List String }
>
> model : Model
> model =
> { contents =
> [ "Lorem"
> , "ipsum"
> , "dolor"
> ]
> }
>
>
> -- UPDATE
>
> type Message =
> Write (List String)
>
>
> update : Message -> Model -> Model
> update message model =
> case message of
> Write contents ->
> { model | contents = Debug.log "Write!" contents }
>
> -- VIEW
>
> view : Model -> Html Message
> view model =
> article
> [ contenteditable True
> , spellcheck False
> , on "blur" <| Decode.map Write <| childrenContentDecoder
> ]
> (viewContents model.contents)
>
> viewContents : List String -> List (Html a)
> viewContents contents =
> contents |> map (\content -> p [] [ Html.text content ])
>
>
> childrenContentDecoder : Decode.Decoder (List String)
> childrenContentDecoder =
> Decode.at [ "target", "childNodes" ] (Decode.list textContentDecoder)
>
>
> textContentDecoder : Decode.Decoder String
> textContentDecoder =
> Decode.field "textContent" Decode.string
>
>
>
>

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

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

[elm-discuss] Re: fold function argument order

[Kasey Speakman]

I know this is a really old thread, but I ran into this precise question 
and thought I would add a perspective.

The form a -> b -> b actually makes the fold right-building, regardless of 
the direction you are traversing the list.

An example: Starting from zero, subtract the numbers 1, 2, and 3. The 
expected answer is -6.

List.foldl (-) 0 [1, 2, 3]
-> returns -6 in Haskell (well, actually tested in F# which uses same order 
as Haskell)
expands to: ((0 - 1) - 2) - 3 = -6
-> returns 2 in Elm
expands to: 3 - (2 - (1 - 0)) = 2-- right-building

Elm's foldl implementation is actually equivalent to a right fold of a 
reversed list. So when a and b are the same type it will only return the 
correct answer if the fold operation is also commutative or if flip is used 
to correct the ordering. When a and b are not the same type, the compiler 
will provide an error for wrong ordering of course.

I started out on the side that a -> b -> b was correct as that feels like 
proper "reduction" or chainable syntax. But after exploring it, it is 
clearly not left-building. Makes sense when you consider this form is used 
with pipe to convert right-building operations into left-reading code. e.g. a 
|> f |> g |> h instead of h (g (f a))

On Tuesday, July 16, 2013 at 6:13:01 AM UTC-5, Evan wrote:
>
> Gotcha, I definitely see the reasoning :)
>
>
> On Tue, Jul 16, 2013 at 12:54 PM, Balazs Komuves  > wrote:
>
>>
>> I was not engaging in debate, religious or not (though I tend to have 
>> very strong opinions about these questions). I was explaining why I think 
>> Haskell uses the order it uses (because it is distinguished from a 
>> mathematical viewpoint). Of course you are not required to follow that 
>> convention, I was just pointing out that it is not simply an ad-hoc choice.
>>
>> Balazs
>>
>>
>>
>> On Tue, Jul 16, 2013 at 12:21 PM, Evan Czaplicki > > wrote:
>>
>>> I think this might be a religious debate on some level. My first 
>>> functional languages were Scheme 
>>> 
>>>  
>>> and Standard ML . The 
>>> libraries I just linked both use the same argument order for foldl and 
>>> foldr as in Elm. I was raised a certain way and it just stuck in my mind. I 
>>> suspect that everyone prefers the order they learned first because it 
>>> matches their mental model.
>>>
>>> I wrote up a bunch of "reasoning", but really, I am just engaging in the 
>>> religious debate. I'd feel bad deleting it all though, so here is some of 
>>> it:
>>>
>>> OCaml's list library 
>>>  does it 
>>> the way you suggest. I find this order offensive on some level.
>>>
>>> The big questions for "physical" argument order are as follows:
>>>
>>>- What is the type of `fold` or `reduce`? When you fold an unordered 
>>>thing, is it from the right or the left? 
>>>- What is the type of `foldp`? Which way does time go? Is this 
>>>cultural?
>>>
>>> I don't find these questions particularly useful, and I don't think 
>>> programmers should have to wonder about them to use fold and foldp.
>>>
>>> At the end of the day, I chose the types on purpose. I find them easier 
>>> to use, easier to teach, easier to understand. I want to keep them this way.
>>>
>>>
>>> On Tue, Jul 16, 2013 at 10:40 AM, Balazs Komuves >> > wrote:
>>>

 The Haskell version of the foldl is the "right one" in the following 
 sense:

 foldl makes sense in general for left-associative operators, and foldr 
 makes sense for right-associative operators.
 Left-associative operators must have the type (a -> b -> a), while 
 right-associative operators must have type (a -> b -> b).

 I think the fact that you cannot change a foldr to foldl without 
 changing the types is actually an advantage: it forces you to think about 
 which version is the "proper" one, and you cannot accidentally do the 
 wrong 
 one. Of course sometimes it can be inconvenient.

 What I somewhat dislike in the Haskell version of foldr (not foldl), is 
 that while 

 (foldl . foldl . foldl) etc makes sense, (foldr . foldr) does not; for 
 that to work you would have to flip the last two arguments:

 myfoldr :: (a -> b -> b) -> ([a] -> b -> b)
 myfoldr f xs y = foldr f y xs

 But the practicality of this change is debatable, I guess.

 Balazs




 On Wed, Jul 10, 2013 at 4:38 PM, Evan Czaplicki >>> > wrote:

> It's partly about composability (i.e. the data structure should be 
> last).
>
> It is also about reuse. In Elm it is valid to say:
>
> foldl (::) []
> foldr (::) []
>
> If I want to change the order of my traversal, I should not *also* need 
> to change the definition of mildly related functions or start using 
> 

[elm-discuss] Re: fold function argument order

[Kasey Speakman]

(deleted and corrected original post with proper expansion of Elm's foldl)

I know this is a really old thread, but I ran into this precise question 
and thought I would add a perspective.

The form a -> b -> b is not left-building, regardless of the direction you 
are traversing the list.

An example: Starting from zero, subtract the numbers 1, 2, and 3. The 
expected answer is -6.

List.foldl (-) 0 [1, 2, 3]
-> returns -6 in Haskell (well, actually tested in F# which uses same order 
as Haskell)
expands to: ((0 - 1) - 2) - 3 = -6
-> returns 2 in Elm
expands to: 3 - ((1 - 0) - 2)

Elm's expansion is wonky for this. It appears to be center-building:
List.foldl (-) 0 [1] -- returns 1, expands 1 - 0
List.foldl (-) 0 [1, 2] -- returns -1, expands (1 - 0) - 2
List.foldl (-) 0 [1, 2, 3] -- returns 2, expands 3 - ((1 - 0) - 2)
List.foldl (-) 0 [1, 2, 3, 4] -- returns -2, expands (3 - ((1 - 0) - 
2)) - 4

When a and b are the same type it will only return the correct answer if 
the fold operation is also commutative or if flip is used to correct the 
ordering. When a and b are not the same type, the compiler will provide an 
error for wrong ordering of course.

I started out on the side that a -> b -> b was correct as that feels like 
proper "reduction" or chainable syntax. But after exploring it, it is 
clearly not left-building. Makes sense when you consider this form is used 
with pipe to convert right-building operations into left-reading code. e.g. a 
|> f |> g |> h instead of h (g (f a))

On Tuesday, July 16, 2013 at 6:13:01 AM UTC-5, Evan wrote:
>
> Gotcha, I definitely see the reasoning :)
>
>
> On Tue, Jul 16, 2013 at 12:54 PM, Balazs Komuves  > wrote:
>
>>
>> I was not engaging in debate, religious or not (though I tend to have 
>> very strong opinions about these questions). I was explaining why I think 
>> Haskell uses the order it uses (because it is distinguished from a 
>> mathematical viewpoint). Of course you are not required to follow that 
>> convention, I was just pointing out that it is not simply an ad-hoc choice.
>>
>> Balazs
>>
>>
>>
>> On Tue, Jul 16, 2013 at 12:21 PM, Evan Czaplicki > > wrote:
>>
>>> I think this might be a religious debate on some level. My first 
>>> functional languages were Scheme 
>>> 
>>>  
>>> and Standard ML . The 
>>> libraries I just linked both use the same argument order for foldl and 
>>> foldr as in Elm. I was raised a certain way and it just stuck in my mind. I 
>>> suspect that everyone prefers the order they learned first because it 
>>> matches their mental model.
>>>
>>> I wrote up a bunch of "reasoning", but really, I am just engaging in the 
>>> religious debate. I'd feel bad deleting it all though, so here is some of 
>>> it:
>>>
>>> OCaml's list library 
>>>  does it 
>>> the way you suggest. I find this order offensive on some level.
>>>
>>> The big questions for "physical" argument order are as follows:
>>>
>>>- What is the type of `fold` or `reduce`? When you fold an unordered 
>>>thing, is it from the right or the left? 
>>>- What is the type of `foldp`? Which way does time go? Is this 
>>>cultural?
>>>
>>> I don't find these questions particularly useful, and I don't think 
>>> programmers should have to wonder about them to use fold and foldp.
>>>
>>> At the end of the day, I chose the types on purpose. I find them easier 
>>> to use, easier to teach, easier to understand. I want to keep them this way.
>>>
>>>
>>> On Tue, Jul 16, 2013 at 10:40 AM, Balazs Komuves >> > wrote:
>>>

 The Haskell version of the foldl is the "right one" in the following 
 sense:

 foldl makes sense in general for left-associative operators, and foldr 
 makes sense for right-associative operators.
 Left-associative operators must have the type (a -> b -> a), while 
 right-associative operators must have type (a -> b -> b).

 I think the fact that you cannot change a foldr to foldl without 
 changing the types is actually an advantage: it forces you to think about 
 which version is the "proper" one, and you cannot accidentally do the 
 wrong 
 one. Of course sometimes it can be inconvenient.

 What I somewhat dislike in the Haskell version of foldr (not foldl), is 
 that while 

 (foldl . foldl . foldl) etc makes sense, (foldr . foldr) does not; for 
 that to work you would have to flip the last two arguments:

 myfoldr :: (a -> b -> b) -> ([a] -> b -> b)
 myfoldr f xs y = foldr f y xs

 But the practicality of this change is debatable, I guess.

 Balazs




 On Wed, Jul 10, 2013 at 4:38 PM, Evan Czaplicki >>> > wrote:

> It's partly about composability (i.e. the data structure should be 
> 

[elm-discuss] Re: launchaco built in Elm

[Marc Laventure]

Hey! I am the author, great to hear your satisfaction with Launchaco. I am 
also super excited to play around with elm on server side rendering! Fun 
tidbit, we used golang to generate the html and assets when you click the 
download button using the "html/template" library. Its very fun to use!

Marc

On Wednesday, December 7, 2016 at 3:32:54 PM UTC-8, Duane Johnson wrote:
>
> I just saw this (very popular link) on hacker news and was very impressed 
> with the UI. Turns out it's built with Elm and Go!
>
> http://launchaco.com/build/
>
> See https://news.ycombinator.com/item?id=13126494 for the author's 
> reference to Elm.
>
> Duane
>

-- 
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: fold function argument order

[Aaron VonderHaar]

What's confusing here is how currying works with infix operators.  It's
idiomatic in Elm to have your accumulator be the last argument, and, for
instance, if you were writing your own data type, you would want to write
your functions so that they can be chained together easily:

myMatrix
|> scale 2
|> subtract 5
|> subtractMatrix myOtherMatrix
|> normalize


But as an infix operator (-) is not able to follow that convention;

5
|> (-) 3
|> (-) 1

is confusingly equivalent to `(1 - (3 - 5))` rather than to `5 - 3 - 1`


If you had a function `subtract` such that

5 |> subtract 3 |> subtract 1 == (5 - 3 - 1)

then you could use that function with fold as you intend

List.foldl subtract 0 [1, 2, 3, 4]  ==  -10

You can achieve the same result with

List.foldl (flip (-)) 0 [1, 2, 3, 4]  ==  -10


Another way to put it is, in Elm, folds expand in the following way:

List.foldl f x [b, c, d]  ==  x |> f b |> f c |> f d
List.foldr f x [b, c, d]  ==  f b <| f c <| f d <| x


On Thu, Dec 8, 2016 at 7:50 PM, Kasey Speakman  wrote:

> (deleted and corrected original post with proper expansion of Elm's foldl)
>
> I know this is a really old thread, but I ran into this precise question
> and thought I would add a perspective.
>
> The form a -> b -> b is not left-building, regardless of the direction you
> are traversing the list.
>
> An example: Starting from zero, subtract the numbers 1, 2, and 3. The
> expected answer is -6.
>
> List.foldl (-) 0 [1, 2, 3]
> -> returns -6 in Haskell (well, actually tested in F# which uses same
> order as Haskell)
> expands to: ((0 - 1) - 2) - 3 = -6
> -> returns 2 in Elm
> expands to: 3 - ((1 - 0) - 2)
>
> Elm's expansion is wonky for this. It appears to be center-building:
> List.foldl (-) 0 [1] -- returns 1, expands 1 - 0
> List.foldl (-) 0 [1, 2] -- returns -1, expands (1 - 0) - 2
> List.foldl (-) 0 [1, 2, 3] -- returns 2, expands 3 - ((1 - 0) - 2)
> List.foldl (-) 0 [1, 2, 3, 4] -- returns -2, expands (3 - ((1 - 0) -
> 2)) - 4
>
> When a and b are the same type it will only return the correct answer if
> the fold operation is also commutative or if flip is used to correct the
> ordering. When a and b are not the same type, the compiler will provide an
> error for wrong ordering of course.
>
> I started out on the side that a -> b -> b was correct as that feels like
> proper "reduction" or chainable syntax. But after exploring it, it is
> clearly not left-building. Makes sense when you consider this form is used
> with pipe to convert right-building operations into left-reading code. e.g. a
> |> f |> g |> h instead of h (g (f a))
>
> On Tuesday, July 16, 2013 at 6:13:01 AM UTC-5, Evan wrote:
>>
>> Gotcha, I definitely see the reasoning :)
>>
>>
>> On Tue, Jul 16, 2013 at 12:54 PM, Balazs Komuves 
>> wrote:
>>
>>>
>>> I was not engaging in debate, religious or not (though I tend to have
>>> very strong opinions about these questions). I was explaining why I think
>>> Haskell uses the order it uses (because it is distinguished from a
>>> mathematical viewpoint). Of course you are not required to follow that
>>> convention, I was just pointing out that it is not simply an ad-hoc choice.
>>>
>>> Balazs
>>>
>>>
>>>
>>> On Tue, Jul 16, 2013 at 12:21 PM, Evan Czaplicki 
>>> wrote:
>>>
 I think this might be a religious debate on some level. My first
 functional languages were Scheme
 
 and Standard ML . The
 libraries I just linked both use the same argument order for foldl and
 foldr as in Elm. I was raised a certain way and it just stuck in my mind. I
 suspect that everyone prefers the order they learned first because it
 matches their mental model.

 I wrote up a bunch of "reasoning", but really, I am just engaging in
 the religious debate. I'd feel bad deleting it all though, so here is some
 of it:

 OCaml's list library
  does it
 the way you suggest. I find this order offensive on some level.

 The big questions for "physical" argument order are as follows:

- What is the type of `fold` or `reduce`? When you fold an
unordered thing, is it from the right or the left?
- What is the type of `foldp`? Which way does time go? Is this
cultural?

 I don't find these questions particularly useful, and I don't think
 programmers should have to wonder about them to use fold and foldp.

 At the end of the day, I chose the types on purpose. I find them easier
 to use, easier to teach, easier to understand. I want to keep them this 
 way.


 On Tue, Jul 16, 2013 at 10:40 AM, Balazs Komuves 
 wrote:

>
> The Haskell version of the foldl is