Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

You can write a |> b or b <| a a >> b or b << a a > b or b < a The `let ... in ...` expression has a 'let' clause followed by an 'in' clause. So, why not allow those clauses to be written in either order. (\i x -> let bar = f x.foo in g i bar) (\i x -> in g i

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

@Bob H & @Andrew R: Thank you. @Janis: It's likely that we could continue to produce extensions/refactors to each other's examples for eternity (which isn't a bad thing, I don't think this is a waste of time at all). In the case of such a `munge` in your example, yeah, following a "factor out

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

As pointed out earlier, it is not true for *Haskell's* let and where. > Am 04.01.2017 um 22:52 schrieb 'Andrew Radford' via Elm Discuss > : > > Heh ok read it again I'll make it more programmer friendly: > > ( |> and <| ) and ( >> and << ) > > > They (each)

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Heh ok read it again I'll make it more programmer friendly: ( |> and <| ) and ( >> and << ) They (each) have identical behavior in what they do, with a left/right symmetry. (I guess you just confirmed it is the same for let/where, with a top/bottom symmetry) On Wednesday, 4 January 2017

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

> > Kinda like how you currently have the freedom to chose between |> and <|, > >> and << They're not really the same thing: << is function composition, and <| is function application. There are cases where you can use either, but for each there are cases where only one will do the trick.

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Colin, Thanks for this comprehensive post - very well thought out and reasonably considered TIL about 'where' - wow so much awesome stuff is in Haskell. Let...in now seems to be upside down! 'Where' seems to closer suit describing *ideas* like you would in Plain English: Kinetic Energy is:

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

> > This comes off as an attempt to end the discussion before it begins. > Unless you know something we don't? Well, they know Evan. :) > Will Evan never consider improvements to syntax? Of course he considers improvements to syntax! > Will he refuse to read this thread? He would be

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

But what if the branches are not calls to an external function like "munch", but are instead as originally envisioned arbitrary, in place, expressions, possibly using "b"/"c" several times? Then your latest solution does not apply since it loses sharing. (Of course one can always artificially

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

@Janis, no, truth be told I didn't like it as I was writing it, but it also didn't occur to me at the time to fire `where` down at the bottom like that. Doing so would satisfy "intent first", but I'd say `let` and `where` here would be tied in terms of "zig-zag annoyance", which is a natural

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Yes, and there is no need to only imagine it, since that already *is* a legal use of Haskell-style where. But I have doubts about its readability, with the adjacent where lines towards the bottom, where only indentation determines what the scope of the respective definitions is. And since Colin

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

You could also imagine a parsing of where, where the following would be the way to write this: f tree = case tree of Leaf x -> munge a b where b = ... Node s t -> munge a c where c = ... where a = ... On Tuesday, January 3, 2017 at

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

And do you like that version? It seems to not have the advantages usually claimed for "where" in this discussion. For example, you define "a" before using it. What about "intent first" here? And in some sense, this formulation now looks like a dual to the workaround Joey proposed with "let" to

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

@Janis, I suppose the `where` version of that formation would have to be: f tree = work where a = ... work = case tree of Leaf x -> -- using a and b where b = ... Node s t -> -- using

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

It’s how they are implemented in Haskell, and people asking for where in Elm typically do so by saying “we want where like in Haskell”. One could probably come up with new parsing rules that allow where to be used anywhere in an expression, thus also for example for local bindings inside a

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Is there something fundamental about `where` clauses which would prevent them from parsing as expressions, or is this an artifact of how they are implemented in Haskell? On Sun, Jan 1, 2017 at 9:21 PM Janis Voigtländer < janis.voigtlaen...@gmail.com> wrote: > > > Janis, the following compiles

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Janis, the following compiles for me: … Right, where does not work for expressions, but for right-hand sides, of which pattern match branches are an instance. The next question would be, still under the assumption that a choice has to be made between where and let because both won’t be made

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Happy new year, everyone. Janis, the following compiles for me: zing :: Num t => [t] -> t zing list = case list of [] -> a where a = 1 a:as -> b where b = a + 1 Max, you may have jumped to a conclusion. From my point of view, the discussion (at least on the mailing list) has barely

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

I think it's pretty obvious at this point that this is another classic "internet argument" in which nothing is really resolved and no one changes their minds. That's because there isn't single concrete example or use-case that definitively proves one side is superior. In which case, things

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Ah, actually one more thought, I don’t remember whether it was considered in the original discussion: The situation of where vs. let is a bit different in Elm than in Haskell via the point that Elm does not allow multiple equations for a function. Concretely, in Haskell one can have: f (Leaf x)

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

I am not myself convinced that “there must only be one way” is always a useful philosophy. But I don’t get to decide about when it is followed in the Elm design. The reality may simply be that there is no way to get both let and where into Elm, that’s why I thought it “dangerous” to consider where

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

> it is counterproductive to not up front discuss the actual alternatives While I think `let` is always an anti-pattern, I don't think it needs to be removed if there is support for it. The "there must only be one way" argument is moot so long so long as the points raised above are left

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

I don’t think it is possible to first decide about where and then “whether let will be dropped”. I am fine with adding where. I am absolutely against dropping let. So if first where is added, and only then the argument “but we must not have two ways of doing almost the same thing” kicks in, then

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

To drop `let` or not would be decided after a call on `where` has been made. Personally I don't like `let` and think it's always wrong (or at least ugly) to use it, but there is a clear compromise here where it can stay put. That said, as Elm is not yet 1.0, there is no obligation not to break

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

You frame the discussion as being about adding "where" or not adding "where". But the actual discussion in the past was not so clearly such. It seemed to be more about dropping "let" and replacing it with "where". Also, in connection with the complications of "where" combined with anonymous

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

*On `where`* History: This debate is on-going since May 2014. The aggregate claim: `where` clauses are superior to `let-in` both technically and aesthetically. It was a mistake from the beginning to choose `let` over `where`. They should, at the very least, coexist. Below I've summarized

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

On Sat, Dec 31, 2016 at 2:12 AM, Max Goldstein wrote: > Those in favor of where clauses, would you mind summarizing any arguments > from the thread that do not rely on personal preference but concrete > improvements to code readability or maintainability, in a way not

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

> > Let/in leads to a sort of vertigal zig zagging as you need to jump to the > bottom then scan backwards for the supporting information. This seems subjective and somewhat dependent on code style. Do you have an example where sequentially reading the bindings causes confusion ("why would

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

As a non haskeller I do find my something constantly wishing that where expressions had been chosen instead if let/in. Let/in leads to a sort of vertigal zig zagging as you need to jump to the bottom then scan backwards for the supporting information. In other languages I've always ordered my

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Those in favor of where clauses, would you mind summarizing any arguments from the thread that do not rely on personal preference but concrete improvements to code readability or maintainability, in a way not achieved by Joey's suggestion? We are looking for code examples in which

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

On Friday, December 30, 2016 at 5:34:20 PM UTC, Lourens Rolograaf wrote: > > Please no. Not every Haskell feature should have a place in elm, > especially if there is already a construct that works (and overlaps 100%?) > Please do not make elm2016, elm2017 or coffeeElm, with all kinds of >

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

As a poster from the original thread on Github, I encourage anyone on here who hasn't read it in its entirety to do so. The "pro-where" camp is not just Haskell whiners, we have legitimate issues with "let". On Friday, 30 December 2016 09:10:52 UTC-8, Will White wrote: > > Continued from

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

I think the strongest argument is that, if you really want where expressions, you can just do this: Translate some_expresssion_with_p1_to_pk where p1 = e1 ... pk = ek into let ret = some_expresssion_with_p1_to_pk p1 = e1 ... pk = ek in ret You

[elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

Please no. Not every Haskell feature should have a place in elm, especially if there is already a construct that works (and overlaps 100%?) Please do not make elm2016, elm2017 or coffeeElm, with all kinds of syntactic sugar because some user from another language still thinks this way. Op