Feature: 'where' expressions (continued from GitHub)

[Will White]

Continued from https://github.com/elm-lang/elm-compiler/issues/621.

[David Andrews]

For those not following the bug, the question is: What real-world problems do you have (if any) that would be solved by a Haskell-like `where` syntax, which are not already solved by the current `let...in` syntax?

On Fri, Dec 30, 2016 at 6:10 PM Will White <will.n...@gmail.com> wrote:

Continued from https://github.com/elm-lang/elm-compiler/issues/621.

--


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.

[Lourens Rolograaf]

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 vrijdag 30 december 2016 18:10:52 UTC+1 schreef Will White:

Continued from https://github.com/elm-lang/elm-compiler/issues/621.

[Joey Eremondi]

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 get the advantage of a where expression: the primary thing you're talking about comes first. It works because all Let blocks in Elm are mutually-recursive, so the ordering doesn't matter. But, it's just a pattern with existing syntax, instead of new sugar, which is more inline with the Elm philosophy.

--

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

[Colin Woodbury]

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

[Joey Eremondi]

 we have legitimate issues with "let".

Issues that cannot be solved with the pattern I listed? Also, are these issues that are purely stylistic and preferences, or are they actually blocking or hurting development, and if so, please tell concretely how that is happening.

--

[Rupert Smith]

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 syntactic sugar because some user from another language still thinks this way.

+1 from me. Very much enjoying how Elm is keeping things simple and trying to avoid overlapping features.

[Max Goldstein]

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 where-clauses either let you do something let-clauses don't, or are visibly superior to them.

I'll put forward Janis's concern that where clauses don't work as well in anonymous functions, eg.

List.indexedMap (\i x -> let bar = f x.foo in g i bar) aList

(I'm not entirely sure why this wouldn't work with where-clauses, but Janis knows his stuff.)

Also, have where-clauses been requested by anyone who does not know Haskell? I think let-clauses are much more natural coming from imperative languages, and Elm's target audience is JS devs, not Haskell devs. This discussion seems to be "features for feature's sake" to me, rather than "features that are a solution to a problem". My question is, what is the problem that where-clauses solve when we have let-clauses? How do they solve the problem of local constants in a way superior -- by more than mere personal preference -- to let-clauses?

[Oliver Searle-Barnes]

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 methods as per the where expression (I think it was a practice I picked up from Kent Beck who recommended it for readability) and while I can order my functions this way at the module level I do miss it with let/in. The pattern Joey suggests seems good, the counter argument though is that you need to check the 'in' to know if that pattern is being used so you end up doing the zig zag read anyway.

That being said I favour the simplicity of a single form, I just wish where had been chosen instead of let/in. The argument regarding being able to use let/in with anonymous functions seems irrelevant as it's use would be a clear sign that the function should be broken out into a named function.

[Max Goldstein]

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 you need to compute that?") not resolved until the returned value? Otherwise this fails to be concrete and actionable.

 

The pattern Joey suggests seems good, the counter argument though is that you need to check the 'in' to know if that pattern is being used so you end up doing the zig zag read anyway.

Coding convention around the name "result" or similar would eliminate that. 

The argument regarding being able to use let/in with anonymous functions seems irrelevant as it's use would be a clear sign that the function should be broken out into a named function.

Janis gives a good example of when you'd want a local binding in an anonymous function here. 

[Peter Damoc]

On Sat, Dec 31, 2016 at 2:12 AM, Max Goldstein <maxgol...@gmail.com> 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 achieved by Joey's suggestion? We are looking for code examples in which where-clauses either let you do something let-clauses don't, or are visibly superior to them.

 

I don't think that it is unreasonable to ask for 3 examples in which one has real code expressed with let-in and the same code expressed with where. The code should make it crystal clear that the where version is simpler, more beginner friendly (for people coming from JS) and has a better chance to be understood 6 months down the line. 

Without these motivating cases, the argument would look dangerously close to "I'm familiar with another way of expressing the same concept and I think current Elm programmers and future Elm programmers should pay the price of dealing with a more complicated language to cater to my needs."

I work best with pattern matching good code. If I have 3 distinct examples I think I can pattern match the better pattern. :) 

List.indexedMap (\i x -> let bar = f x.foo in g i bar) aList

Why is the above code better than 

List.indexedMap (\i x -> g i (f x.foo)) aList

-- 

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Colin Woodbury]

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 arguments made both for and against adding `where` to

Elm. A topic tagged with "For" means it argues in favour of adding `where`.

"Against" means the opposite.

Technical Arguments

**For: Intent First**

Elm is FP, and therefore lends itself to declarative programming. The

following is easier for devs to read, thus increasing code comprehensibility,

thus reducing dev time, thus saving companies money:

foo : (List A, Int)                                                                                      
foo = (my ++ intent, goes - here)                                                                        
  where my = ...                                                                                          
        intent = ...                                                                                      
        goes = ...                                                                                        
        here = ...                                                                                        

Post by Yashaka detailing why `where` is better for declarative programming:

https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-207841658

Downside-up breaks logical flow:

https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-221263715

There have also been multiple copy-cat issues opened on Github, detailing

this as the primary reason to add `where`.

**For: Intent-to-return-type Distance**

Minimizing the distance between your "intent" and your return type increases

the ability to understand a function.

foo : (List A, Int)                                                                                      
foo = (my ++ intent, goes - here)                                                                        
  where ...                                                                                              

Our eyes move very little when confirming the type of our intent. To contrast:

foo : (List A, Int)                                                                                      
foo =                                                                                                    
  let my = ...                                                                                            
      intent = ...                                                                                        
      goes = ...                                                                                          
      here = ...                                                                                          
  in (my ++ intent, goes - here)                                                                          

This causes the "zig-zag" reading as mentioned elsewhere.

**For: "let" goes against Elm's own style guide**

`let` causes "dirtier" git diffs after changing a function:

https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-269137011

**Against: `let` can be used in lambdas, `where` can't**

Claim: `let` is more general than `where`.

https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103122010

My thought: Never use `let` in a lambda. Combining local definitions and

anonymous functions is always an anti-pattern. If your lambda gets to the

point where you need bound names to simplify things, factor all of it out

into a `where` below the function:

-- | Haskell
bar :: [a] -> b                                                                                          
bar = foldl f someAccVal                                                                                  
  where f acc x = ... -- complicated lambda                                                              

A real example: https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103349671

**Against: Use "let" more cleverly**

From Joey Eremondi:

> Use:

 let
   ret = some_expresssion_with_p1_to_pk
   p1 = e1
   ...
   pk = ek
 in
   ret

The idea being that you gain the advantage of declaring "intent first" using

existing syntax. Yet this pattern could be called unidiomatic by Elm's own

standards. Also, as mentioned by Oliver, you need to "zig-zag read" anyway

to make sure `ret` was used correctly in the "in" section.

Philosophical Arguments

**Against: `let` "resonates" with JS devs more**

From Evan:

> Is this something that registers at all for a JS programmer?

From Max:

> I think let-clauses are much more natural coming from imperative languages,

> and Elm's target audience is JS devs, not Haskell devs.

This argument has never been a strong one to me. You're already asking JS

devs to learn an entirely new language with radically different syntax and

concepts. Yet "let" is supposed to make them feel at home somehow? No, if

they're already learning new syntax and a new paradigm, it is not a stretch

to ask them to get used to "intent first".

It doesn't matter what is intuitive to imperative programmers. Elm is not

imperative. If Evan didn't think FP was the superior paradigm, he wouldn't

have written an FP language, or used Haskell to write it.

**Against: There should be only one way to do things in Elm**

From Max:

> Elm's philosophy has been "there's only one way to do it" ...

This is brought up often in these discussions and in the Elm guide. It's a

well-intentioned idea, but I don't think it matches the reality of

programming. Particularly, please explain why there are multiple ways to

call record fields in Elm:

foo.bar                                                                                                  
                                                                                                         
.bar foo                                                                                                  

or why anonymous functions can semantically collide with `let` statements:

let x = a in b                                                                                            
                                                                                                         
(\x -> b) a                                                                                              

Yes, any `let` expression can be replaced by a series of lambdas using the Y

combinator. Should we do that instead? No, of course not.

**Against: Elm is not Haskell**

From Janis:

> All I was arguing against was claims that Elm must add where, "because Haskell".

Is Evan obligated to implement every aspect of Haskell into Elm? No, of

course not. However, taking a wider view of things, Elm is Haskell. The

syntax and concepts are so heavily inspired by Haskell that apart from:

- `::` becoming `:` in function signatures

- slightly different `import` syntax

that I'd argue 99% of Elm code in the wild today is parsable as legal

Haskell. If it's already mostly Haskell, why choose to cut `where`? I

understand the motivation for cutting typeclasses, but it makes no sense to

"draw the line" for borrowed features at `where` when so many people are

asking for it.

Meta Arguments

**Medical condition**

One dev admitted to a medical condition such that `let`'s "intent last"

style makes it extremely physically difficult for him to read Elm code:

https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-269231195

**On Alienating Haskellers**

> Haskellers are not Elm's target audience, JS programmers are.

My original comment from the thread:

> Given that Haskellers were the initial adopters, Evan and the rest of the

> Elm core team have to realize they alienate their original users by taking

> this attitude.

> All power to Elm if its goal is to "win" the frontend stack race. I really

> hope that happens. It's unfortunate that Elm thinks it has to be "easy" and

> must avoid advanced concepts at all costs in order to be useful/adoptable.

We're trying to help you (re: `where` and polymorphism/typeclasses).

Alienating us while infantalizing your target audience will leave you as the

smartest kid in the room.

https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-221053554

[Janis Voigtländer]

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 functions, you simply say "Don't". Thus, you are ignoring the counter-point to that stance which I made in that earlier discussion, and which was quoted by Max earlier today on the mailing list. Can you address that? (It was about refactoring.)

--


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.

[Colin Woodbury]

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 existing code (this has happened several times already) in such a case where `let` were removed. I'm sure other "pro-where" people have different opinions.

> ... Can you address that? (It was about refactoring.)

Please correct me if I'm wrong, but I think I already did. To put the above summary together this morning I went over the old thread again, and thought the point about `lambda + let` to be decently refuted already. For brevity above I probably left out the previous back-and-forth. For the interested, that particular stream of debate begins here https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103122010 and ends around here https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103358388.

[Janis Voigtländer]

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 you will want to discuss about dropping let, whereas I will start arguing that if one must be dropped, then where is the one. :-)

If I am not alone in this, then it is counterproductive to not up front discuss the actual alternatives “only let“, “only where“, “where and let“.

And I don’t think that lambda + let was refuted. It is fine to encourage as a style guide that anonymous functions best do not have local bindings inside. It is a different matter altogether to actually outlaw those two to ever be used together. It seriously hampers the use/combination of functional features. My comment in the earlier discussion that was mainly on this point was this. That was written a long time ago, I don’t have the details of the code present in mind anymore, so I can’t tell whether I feel 100% like I did back then on that particular example. But I can suggest this:

Make an experiment asking experienced Haskell programmers what they would chose if they had to give up one of where and let from their language. I bet that (being aware giving up let would mean they can’t have local definitions inside a lambda-expression anymore), the majority would chose to give up where.

In case you want to start counting: Here is one experienced Haskell programmer who would chose to give up where in that case. (I have been programming Haskell for 20 years next summer.)

​

[Colin Woodbury]

> 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 unaddressed. In general, I think that that philosophy remains an ideal detached from the reality of programming (and the mathematics behind it).

> And I don’t think that lambda + let was refuted. 

I will have to dig back into those refactoring examples and see what was missed, if anything.

> Make an experiment...

Haha I suppose your 20 years beats my 5. That said, I'd never give up `where`, but also never do local binds in lambdas. I like the idea of that experiment, and will put it together tomorrow, posting the questions here beforehand to make sure they're fair. A google poll posted across IRC, Reddit, and Twitter ought to be representative. Can I trust that the results will be respected, at least within the scope of this debate? It's been made abundantly clear that Haskellers aren't the target audience for Elm. 

[Janis Voigtländer]

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 as an isolated matter, as if adding it without removing let was even an option. (I can’t say whether it is an option.)

About this:

Can I trust that the results will be respected, at least within the scope of this debate?

I can only speak for myself. Of course, having proposed the experiment, I will not anymore claim that a majority of experienced Haskell programmers would prefer abandoning where over abandoning let if the data says otherwise. Whether that “admission” of mine would buy you anything in this debate is another matter. I don’t speak for anyone than myself here anyway. And it’s not like it is exactly my opinion that keeps you from getting where 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+unsubscribe@googlegroups.com.

[Janis Voigtländer]

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) = some expression
  where ... some local definitions involving x ...
f (Node s t) = some other expresion
  where ... some local definitions involving s and t ...

That’s easy to translate into an Elm form

f tree =
  case tree of
     Leaf x -> ...
     Node s t -> ...

if one may use let-bindings in the branches.

But if Elm only had where, and it would work like in Haskell, what would you do? Because the following is not legal in Haskell:

f tree =
  case tree of
    Leaf x -> some expression
      where ... some local definitions involving x ...
    Node s t -> some other expression
      where ... some local definitions involving s and t ...

​

2016-12-31 23:46 GMT+01:00 Colin Woodbury <col...@gmail.com>:

--

[Max Goldstein]

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 default to the status quo. Unless you can come up with an incredibly amazing example that highlights a huge difference in favor of where, the language is not going to change. Yes, Elm has made breaking changes but they have often made the language smaller. I've read JS devs who are frustrated not so much by breaking changes, but by breaking changes for no reason. Benefits from this change are marginal and tradeoff-laden at best. Evan has said that one should avoid refactors that lead to "You know that code that was totally fine? It is different now," and that's what a let-to-where switch would look like. 

There is nothing in this discussion that will make Elm a substantially better language, so it's a pity that we're spending all this time on it. Evan isn't worrying about syntax anymore; he's making the parser faster and the package installer more robust. I know the guy who is working to implement Array in Elm so that it's less buggy and easier to maintain. There are people who produce the Elm-Town podcast, and they invited the author of a library on to talk about it and how it ported Haskell patterns to idiomatic Elm. I personally worked on fuzz testing (i.e. property-based testing similar to QuickCheck) for elm-test, which is powered by a random number generator that I ported to Elm and have submitted a patch for core. If your Haskell experience has led you to parsers, maybe you could help out elm-format. Or you could livestream yourself working on a program and invite the community to watch, comment, and learn. As Evan has advised us, "choose not to block". You can give back to the community right now by building something cool instead of arguing on the internet.

[Colin Woodbury]

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 begun. The "for-and-against" points were laid out, as well as counter-points for the "against" points, and none have been addressed. Furthermore, Janis and I have essentially converged on "add `where` but keep `let`". Code doesn't have to break. Otherwise, it's only been us three talking so far. No one else has really chimed in yet, including Evan.

> there isn't single concrete example or use-case that definitively proves one side is superior

This isn't the case if one accepts "intent first" and its benefits. If you do, every concrete code example using `where` becomes definitive proof. 

> it's a pity that we're spending all this time on it

This comes off as an attempt to end the discussion before it begins. Unless you know something we don't? Will Evan never consider improvements to syntax? Will he refuse to read this thread? Is he the kind of person who is adverse to criticism in general? I've never met him personally, but I'm sure he's very well-intentioned. That said, conflict breeds evolution and improvement. Elm needs people to tell it that it isn't good enough, and that's what I and the flood of past and future people wanting `where` in Elm are saying.

[Janis Voigtländer]

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 available at the same time, how well “where-only” would work if in addition one wants to have a local binding that spans all pattern match branches, i.e., something one would currently write in Elm like so:

f tree =
  let
    a = ... something ...
  in
    case tree of
      Leaf x -> let b = ... in ... using a and b ...
      Node s t -> let c = ... in ... using a and c ...

​

[Robin Heggelund Hansen]

Just wanted to add my 2 cents, seing as I've done very little Haskell, and most of my experience is from Javascript and Clojure. I prefer let-in over where.

In no language I've worked in do you have such a construct, so these opinions could simply be due to lack of experience. But then again, that itself is a reason to prefer let over where.

For me, using let-in is easier because I rarely know what the returning statement should look like in any non-complex function.

When writing code it's easier to first write down the things I know I need, and then figure out how to make those pieces fit in a way which gives me what I want.

It's the same thing when reading code. It's easier, for me, to first read what I have, and then see how those things fit together to return the product.

When I tried to learn Haskell, I always used let-in over where for this reason. Since where didn't really give me any advantages, I never used it. As a result, code using where was more difficult for me to read.

Also, for me, the zig-zag reading argument against let-in doesn't make much sense. If I read a statement like [ my ++ implementation, details] I instantly forget it if I don't know what my, implementation and details are. Until I know those things, the statement is garbage. For me, there is more zig-zag reading with the where expression, due to how I understand code.

The use of let-in or where, is subjective. However, I'd argue that a let-in pattern is much more comfortable for someone who comes from a language like javascript (or Clojure, for that matter), as that is how you're forced to write code in those languages. Some have argued that that is not a good argument, because people are already forced to learn a new language and a new way of doing things. But less people would be willing to do that the more complex features they find. I'd argue that Elm is a language people are willing to learn because it has very few constructs. Again, in my experience, I never finished learning Haskell because it simply became to much hassle. Elm I learned without any issue. I even tried Haskell again after learning Elm, and gave up once more. That Elm is trying to be easy to learn for Javascript developers is a good thing! (tm).

Then there is the argument regarding having one way to do things. This is an argument I agree with. It makes things easier to read as there are less surprises when reading someone elses code. This might be a subjective thing, but I think Python is easier to read than Ruby, Go easier than C++, Elm easier than Haskell. I'd argue that it's a direct result of having less syntax and opinionated code formatting. Some have said that Elm already breaks this principle, and this is true for things like record.value and .value record. But that doesn't mean that we shouldn't strive to break this rule as little as possible.

[David Andrews]

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?

--


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.

[Janis Voigtländer]

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 lambda-abstraction. But that would require new design work to make sure everything fits together and the syntax remains unambigous and usable. That probably presents an even bigger hurdle for acceptance into Elm than “just” wanting to get Haskell-style where in.

​

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@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+unsubscribe@googlegroups.com.

[Bob Hutchison]

Greeting, and a happy new year to all the readers of this thread;

The terms ‘let’ and ‘where’ are kinda widely understood among the *general public*, in Canada at least. The two terms are introduced in elementary school mathematics simultaneously with variables — I think grade three.

A simple google search for "let and where in mathematical notation” will give you plenty of hits.

For example (just search for the words ‘where’ and ‘let’):

* http://web.cs.ucdavis.edu/~amenta/w10/writingman.pdf "A Guide to Writing Mathematics”

* http://www.learningideas.me.uk/clearmaths/ "How to write mathematics clearly"

And on and on.

This is not some kind of highly specialised jargony thing, it a common usage.

Nor is this some legalistic setting where [oops, inadvertent use of the word] “‘where’ like in Haskell” means “‘where’ precisely and exactly as in Haskell” and not “‘where’, sorta like in Haskell but not necessarily exactly like and I don’t have either the time nor (I thought) the need to be totally precise in this informal discussion especially since there’s no clear evidence that it won’t be a total waste of my time to be so precise”.

[Colin, your energy displayed in your December 31 post https://groups.google.com/d/msg/elm-discuss/KiKF6K9gBKU/jzMuSTZmEwAJ is amazing]

Nobody is asking for rocket science. There is no evidence, and I find it hard to believe that any will ever be produced, that there’s anything special about (an english speaking) JavaScript programmer that makes comprehension of ‘where’ difficult.

If anyone’s interested in anecdotal evidence, I can tell you my experience as a 40+ year professional programmer upon discovering the ‘where’ clause in Haskell. And the tick in variable names. And the backtick for infix notation. But I’m clearly not in Elm’s target demographic. So I won’t.

Cheers,
Bob

> On Jan 2, 2017, at 2:07 AM, Janis Voigtländer <janis.voi...@gmail.com> wrote:
>
> 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 lambda-abstraction. But that would require new design work to make sure everything fits together and the syntax remains unambigous and usable. That probably presents an even bigger hurdle for acceptance into Elm than “just” wanting to get Haskell-style where in.
>
>
> 2017-01-02 5:57 GMT+01:00 David Andrews <rand...@gmail.com>:
> 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.voi...@gmail.com> wrote:
>
>
> 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 available at the same time, how well “where-only” would work if in addition one wants to have a local binding that spans all pattern match branches, i.e., something one would currently write in Elm like so:
>
>
>
> f tree =
>
> let
>
> a = ... something ...
>
> in
>
> case tree of
>
> Leaf x -> let b = ... in ... using a and b ...
>
> Node s t -> let c = ... in ... using a and c ...
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
> 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...@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...@googlegroups.com.

[Colin Woodbury]

@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 a c                                                                        
            where c = ...

[Janis Voigtländer]

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 please "where" proponents. Isn't it strange that "a" and "work" look like they might be mutually recursive now, when they are actually not and when the "let"-formulation made that explicitly visible?

--

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.

[David Andrews]

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

 

[Roland Kuhn]

Without any background in Haskell to speak of, may I ask why this would be preferable? How would I discern the intent of line 4 without having to look up what "a" and "b" are? Is it not a lot more fragile to rely upon sensibly chosen names than to state the prerequisites up front? Naming is one of the hardest problems, not only in computer science.

Note that I am not arguing about “intent first”; I am questioning whether that maxim can be effectively implemented in practice using “where” syntax.

Regards,

Roland

[Janis Voigtländer]

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 probably knows that that way of writing the example would have been legal as well, his giving another version with where instead may indicate he also considers these “adjacent wheres” undesirable in terms of clarity/readability of the code.

In any case, even just the fact that let (with in) is a two-keywords-construct makes it clearer for nested uses.

​

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

[Colin Woodbury]

@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 outcome of the pattern of needing a shared bound value across two guards.

The next evolution, avoiding the problem of nested `where`s entirely:

f tree =
  case tree of
    Leaf x -> munge a (b x)
    Node s t -> munge a (c s t)
  where
    a = ...
    b x = ...
    c s t = ...

[Janis Voigtländer]

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 introduce something like an explicit "munge"-function just for the purpose of guaranteeing sharing. But that might be undesirable from a readability standpoint.)

[Richard Feldman]

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 wise to refuse.

 

Is he the kind of person who is adverse to criticism in general?

Far from it.

I've never met him personally, but I'm sure he's very well-intentioned.

For sure! As is everyone in this thread. :)

 

That said, conflict breeds evolution and improvement.

 

It also slows down projects. If Evan spent time seriously considering every possible syntax improvement, Elm still wouldn't even have a virtual DOM system.

Elm needs people to tell it that it isn't good enough, and that's what I and the flood of past and future people wanting `where` in Elm are saying.

There haven't been a "flood" of people asking for this feature. There has been a flood of discussion from an extremely small number of people. This is not a pain point for the overwhelming majority of the Elm community, and insisting otherwise primarily serves to suggest one may be overselling one's knowledge of said community.

Historically, Evan has been amenable to syntax changes such as the following:

• Changing a legacy syntax decision inherited from Haskell to something more user-friendly. (Examples: type alias, import Foo exposing (..), changing module Foo where to module Foo exposing (..))
• Deleting syntax from the language. (Examples: backticks, primes, ranges)
• Additions in the service of a major new feature. (Examples: port, and...yeah, this language has existed for almost 5 years I can't come up with any others. I think that paints a pretty fair picture of where the bar is for new syntax to make it into the language.)

I've heard Evan say "I'm not making this language to fight the syntax wars," and I think that's a sensible way to prioritize a language as ambitious as Elm. (Ambitions like someday making it the best server-side language too.) There are an unlimited number of ways Elm's syntax could potentially be improved incrementally. Considering things takes time, and if Evan spent time even considering every proposed incremental syntax improvement, no progress would ever be made on the rest of the language.

At some point there has to be a bar for "this is not worth the time it would take to seriously consider it." A syntax feature that would, at best, be an incremental improvement over a status quo that only a tiny fraction of the Elm community finds objectionable...to be honest, I'd consider it pretty irresponsible of Evan as a language maintainer to spend time seriously considering whether this would be a good change to make - let alone implementing it.

Carry on debating if you like, but please be aware your odds seem vanishingly low to outside observers who have been around for at least 3 years each.

PS: I am usually in the habit of responding to rebuttals, but in the case of this thread I do not intend to post again. I've said my piece. If you find my reasoning objectionable or fallacious, fine: skewer it. It's your time. Spend it however you find most meaningful.

[Andrew Radford]

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:  1/2 mv^2

 where 'm' is the mass

 and 'v' is the velocity

i.e it follows a pattern more human-brain-friendly:

Name : Fundamental Idea

 other

 small

 details

 if you really care

For the same reason we don't lay out our recipes ingredients first followed by the name of the dish. Or our CVs with the description of duties, sate of service then finally the Job title.

I'm a 'top down' thinker, not a 'bottom up' thinker, so would probably chose where over let. But is Is 'where' really actually just a re-organised let..in? I.e if there was support for both, would it be simply a choice of personal style preference? Kinda like how you currently have the freedom to chose between |> and <|, >> and << etc?

On Saturday, 31 December 2016 18:36:14 UTC, Colin Woodbury wrote:

On `where`

<Snip>

[Joey Eremondi]

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.

Whereas, where vs. let are literally identical in what they do, they just look different.

--

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

[Andrew Radford]

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)

[Janis Voigtländer]

As pointed out earlier, it is not true for *Haskell's* let and where. 

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

[Andrew Radford]

Gotcha. Presumably there would have to be an Elm flavor of it, which may not work the same way but kept the core concept of being an 'let..in'  the other way up.

I have a feeling that 'where' would clarify a lot of my code. But I also have a feeling I'll never see it in Elm.

[Colin Woodbury]

@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 common behaviour" maxim, I'd default to a new (likely non-exported) function as I did here: https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-103349671

@Richard F:

>> That said, conflict breeds evolution and improvement.

> It also slows down projects. If Evan spent time seriously considering every possible syntax improvement, Elm still wouldn't even have a virtual DOM system.

Slippery slope. Wanting to not rock the boat under any circumstance creates echo chambers. Honest question: Do you know if Evan believes that conceding on `where` would mean "opening the floodgates", and he's concerned he'd never hear the end of proposals for improvements (from "the Haskell people" or otherwise)?

> This is not a pain point for the overwhelming majority of the Elm community

If the "target audience" is JS devs who have never heard of `where`, then of course it isn't, because they don't know what they're missing. We've seen a few non-Haskell Elm users here say "hey I'd like that". 

[doug moen]

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 bar let bar = f x.foo)

This is a lot less complicated than adding a Haskell-like 'where' expression that can't be used in all of the same contexts as 'let'.

Doug Moen.

[Will White]

`in... let...` is either a perfect stepping stone, or if the idea of `let... in...` is that's "it's like in academic papers", it's an abomination for which `where` would be a better fit. Unless `in... let...` is in academic papers, of course!