Feature: 'where' expressions

[jonashaag]

I'd love to see support for "upside down" let ... in expressions, like you have in Haskell:

spam = foo bar where
  bar = ...

Sometimes code is easier to read if you see the Big Picture first, with the details hidden. Having a Haskell background, I often find myself laying out new definitions by typing let \n in first, leaving empty the let part, then sketching the Big Picture in the in part, and finally filling out all the details in the let part:

foo = let
      in

==>

foo = let
      in ... Big Picture ...

==>

foo = let details
      in ... Big Picture ...

I understand that 'where' expressions are a bit problematic because they flip the order in which code is executed (since Elm is eagerly evaluated, you'll have to evaluate the where ... block before evaluating the Big Picture expression). But I think this is something you can easily adapt your thinking to, so I wouldn't expect it to cause a lot of confusion.

[Fresheyeball]

+1, the mental flexibilty 'where' provides makes coding more pleasant. Even nicer if the compiler supported swapping from 'let' to 'where' for IDE's.

[mgold]

Have you ever worked on a large Rails app and seen the same thing done 10 different ways? That's what's going on with let/where. As soon as there's a subjective decision, codebases fragment, and developers lose time on petty arguments. There has to be one way to do it.

[Fresheyeball]

I agree that too many ways is bad, but that doesn't mean that 2 is too many. I think the right number of ways to do something in a language should be between 1 or 2, but no more than that. 10 is madness. I like how Elm handles record type aliases for example, there are 2 ways to construct them and each facilitates a different use-case.

[ColonelJ]

I think it is pretty well acknowledged that 'where' is a much more popular and readable alternative to 'let' (when it can be applied). There's no reason that having 'where' in Elm is going to cause arguments or fragment code bases; so I don't know what all that was about.

The main problem with 'where' is that Elm tries to replicate Haskell syntax. By not implementing what is a very fundamental syntactical construct, it is guaranteed that Haskell users are going to be upset, when they end up trying to use it. This adds to the learning curve of using Elm, as well as other issues:

• Having to always snap out of using 'where' when switching from Haskell into Elm
• Not being able to write programs following the natural reading order (illustrated earlier)
• Making it harder to port Haskell code into Elm (which already uses 'where')

As noted previously in this thread, 'let' and 'where' aren't even semantically equivalent, so having 'one way to do it' is actually not an option here. This is simply a missing feature, which should really be implemented. But, as far as I could tell, the lead developer hasn't really looked into how it would be done (the same as Haskell?) and isn't interested in doing it.

I expect that people are going to continue to complain about the absence of 'where' until one of the following happens:

• Someone makes a fork of Elm which does implement 'where', and everyone starts using that (it's more usable) - at which point you're forced to introduce it - or risk losing control of the project and fragmenting the community (the joys of open source)
• Someone makes something better than Elm; Elm fades into obscurity and therefore nobody talks or cares about it any more

So... having this issue being closed really doesn't achieve anything. Probably nearly all of Elm users would prefer to have this syntax available. So... make it happen already!

[ColonelJ]

By the way there is quite a good discussion of this now on the Haskell Wiki succinctly describing the key differences between 'let' and 'where'. I think it makes it quite obvious that both are needed, since sometimes you can only use one and not the other.

[jvoigtlaender]

That Haskell Wiki page doesn't prove anything concerning the necessity of having"where" in Elm. The case it gives for when you cannot use a let-expression does not apply to Elm, which has no guarded equations. So, no, that page does not make it obvious that "where" is needed in Elm.

Several of your other arguments are moot as well.

For example, Elm is not trying go replicate Haskell syntax. That statement is simply wrong.

[Fresheyeball]

@ColonelJ I think you are being abit sour. Elm is a unique project with its own voice, and not trying to replicate Haskell. Its done great so far without 'where' and likely will continue to succeed without adding 'where'. I personally would preffer the addition of 'where', but its not going to hold Elm back much.

[mgold]

On the point that Haskell users will dislike Elm for not having where, Haskellers are not Elm's target audience, JS programmers are. And coming from an imperative/procedural world, let makes a lot more sense and where seems "backwards".

[yashaka]

I believe that Elm's subject seems to be closer to "declarative reactive functional programming". And target audience is what will be a consequence of the former. Declarative and FRP is nevertheless a completely other world from imperative/procedural. So why care of the latter? :)

"where" is closer to declarative style than "let".

Нд, 22 трав. 2016 о 20:28 Max Goldstein notifications@github.com пише:

On the point that Haskell users will dislike Elm for not having where, Haskellers are not Elm's target audience, JS programmers are. And coming from an imperative/procedural world, let makes a lot more sense and where seems "backwards".

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/elm-lang/elm-compiler/issues/621#issuecomment-220844777

[ColonelJ]

I think any effort to use Elm is much more likely for someone who's already sold on functional programming, than a Javascript developer, who already has a lot of tools at their disposal. Compared to a language built into every browser (with full access to webpage elements), a Javascript developer would have to have a very open mind to use something like Elm, which requires a totally different ecosystem (built under Haskell no less!)

For a Haskell user, on the other hand, Elm lets you do Web client-side stuff, which you couldn't before, and more importantly, it lets you explore the world of FRP (more likely the reason you decide to play with Elm in the first place, from a theoretical perspective).

Since having a Haskell-like thing to run in the browser is nice, changes from the Haskell syntax are best avoided. Though one has to acknowledge that the <| borrowed from F# is a lot better than Haskell's $ when provided alongside the popular |> (with people even adding these to Haskell). Other stuff, like swapping the meaning of : and :: (from F#, Scala, etc.), tuple constructors (,,), and so on, we can live with, but a lot of other differences just show up as omissions from Elm or are just plain annoying/confusing. (E.g. I don't agree with << instead of ., which represents the circle composition operator from maths. There's already >>> for the other option in Haskell - why need a different syntax?)

I found this very interesting list of differences between Haskell and Elm. Thanks to Python making list comprehensions very much the 'mode du jour' (being far more readable for long expressions), the whole map/reduce idea has lost favour, and this is another Elm missing feature which shows up just like where in the above list. (Of course there's an issue for it already #147 which is also CLOSED.)

And right, the special use case for where being needed in Haskell. Indeed, that doesn't apply, because Elm doesn't have guard expressions... Great, yet another feature that Elm doesn't have! Maybe it should be added too? (And forget about the multi-way if syntax. This is NOT the same as pattern guards, and is probably going to be removed anyway.)

Coming back to the "only one way to do it" logic, by excluding where from Elm, one might wonder why you wouldn't also consider removing <| and << for exactly the same reason: they don't follow the imperative control flow, and you can use |> and >> instead. Makes sense right, who needs 'em?

Man, I don't where this language is going, but implementing more features of Haskell into Elm is better than not, and the syntax doesn't need to change. If you can just use some 'Elm equivalent' it's not so bad, but let is no substitute for where.

[jvoigtlaender]

@ColonelJ, you are entirely entitled to your own opinion about what the target audience for Elm should be, but that doesn't change a bit about what the declared target audience for Elm is. You think Elm shouldn't try to "convert" JavaScript developers. Fine. The creator of Elm has a different opinion, and certainly you cannot expect that because of the opinion you have the language changes course.

[fosskers]

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

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.

[Fresheyeball]

Designing to infantilize a target audience is how we got Java.

JavaScript dev's who are interested in Elm, are the cream of the crop imho and good engineers will step upto the plate when challenged. I love how Elm lowers the barrier to entry, but that is a separate concern from target audience. It feels like its being implied that good JS devs are less willing or capable of dealing with abstraction than Haskell devs, and its just not the case. JS world is maddeningly complex, and good JS engineers deal with complexity way beyond what a simple 'where' clause introduces.

I'd like to see Elm focus on being the best programming language in can be, and meet the goals of the language, including simplicity and a low barrier to entry. But that is very different from, 'lets exclude useful abstractions because JS devs are too dumb to understand', that's the wrong attitude. Not to say there are not stupid JS devs out there, but Elm should not en-devour to fix the unfixable.

If the addition of language feature X, makes Elm for flexible and pleasurable to use, and doesn't conflict with the goals of the language or the preservation of its properties.... then it makes Elm more flexible and pleasurable to use, period; regardless of the programming background of the developer.

[jvoigtlaender]

@Fresheyeball, I fully agree with you. But what we are getting above is wrong statements like "Elm tries to be a Haskell derivate, so it must add this and this and this syntactic feature from Haskell". Or "It's basically hopeless to make Elm attractive for JS folks, so the language must target Haskell folks instead, and for this reason must copy as much as possible of Haskell syntax, because things must be like they are in Haskell, in order not to turn away Haskellers" etc.

[Heimdell]

I still vote for where. But not solely because it is present in haskell - that is not the root cause. I vote for this but because it allows me to make things upside-down. For now, Elm allows only downside-up constructions.

Downside-up code breaks logical flow. You read: problem deps... = let now stop and see how I shift bits in ... and think "wait, that doesn't looks like a solution... oh, it is (10 lines below)".

[fosskers]

Elm tries to be a Haskell derivate

It's changed quite a bit over the years, but we can't deny the stark similarity between the two. Don't want higher-kinded types? Fine, all power to you, Elm doesn't have to be Haskell. That said, drawing the line at where vs let using that same argument seems silly.

It's basically hopeless to make Elm attractive for JS folks

Is anyone actually claiming this? Adding where to appease the Haskellers is not anti-JS nihilism. Adding where isn't even just for the Haskellers. where is just better than let.

[jvoigtlaender]

I assume the last comment is addressed to me, since it is quoting excerpts from my previous comment. If it is addressed to me, you seem to be making assumptions about my position that are not true. I have nowhere above said that I am against having where. If you look through the old comments above from months ago, you will find that I was arguing against replacing let by where, not against adding where. And if you look throught the comments from the recent days, you will find that I didn't take a position about having or not having where at all. Nor do you know anything about my preferences concerning higher-kinded types or whatever. All I was arguing against was claims that Elm must add where, "because Haskell".

About this:

It's basically hopeless to make Elm attractive for JS folks

Is anyone actually claiming this?

I was writing that because of this paragraph in someone else's comment:

I think any effort to use Elm is much more likely for someone who's already sold on functional programming, than a Javascript developer, who already has a lot of tools at their disposal. Compared to a language built into every browser (with full access to webpage elements), a Javascript developer would have to have a very open mind to use something like Elm, which requires a totally different ecosystem (built under Haskell no less!)

... followed by essentially an argument that "because of this", Elm must copy Haskell as much as possible in syntax and operator names.

[fosskers]

I was quoting you, yeah. That said:

you seem to be making assumptions about my position that are not true

More like the de facto agreement of the Elm team, as opposed to you specifically. The same goes for higher-kinded types. I didn't mean you. I've just reread the entire thread, and it's interesting that it has been an entire year we've been debating this.

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

We can agree that that's silly.

I was writing that because of this paragraph...

Point taken.

I was going to suggest more discussion points, but having reread the entire thread as I was writing this, I can see almost everything that can be said has been. Critically, however, the following has not yet been discussed, and has been a concern of mine recently (as a user, contributor, and proponent of Elm):

Designing to infantilize a target audience is how we got Java.

[ghost]

I'm from JS and I'd like to use where over let, for the reason @Heimdell gave. JS has already gone to (x) => x * 2, so it shouldn't be too hard for a JS programmer to learn in Elm what would amount to (x) => x * y where y = ....

[kana-sama]

let/in goes against elm style guide

Goal: a consistent style that is easy to read and produces clean diffs.

Haskell:

Before:

f a b = a + b

After new feature:

f a b = a + b + c
  where c = 10

Easy to read changed body (it is immediately after the old).

Elm:

Before:

f a b =
    a + b

After new feature:

f a b =
    let
        c = 10
    in
        a + b + c

It is like a new function with old name

[ghost]

@kana-sama Please correct me if I'm wrong, but isn't that just about Elm having a newline after f a b =, rather than about let vs where?

[kana-sama]

@willnwhite Nope. Diff is much cleaner after adding where than after adding let-in, because a + b + c comes immediately after a + b.

[ghost]

Got it! I was interpreting function body as including the let-in, so I couldn't see it.

[mgold]

Folks: where-expressions are not going to happen. A contrived diff isn't going to make a difference.

(Yes, contrived: how often do you add a new parameter like this when making a change? You have a solution in search of a problem. When designing Elm, we like to start with a collection of real-world pain points, not a collection of language features.)

[Birowsky]

@mgold the examples are coming in because Evan likes them. Also, since you need painpoints, here's mine. I thought i'd never share it since it makes me uncomfortable confessing it in public, but what the hell. It's for a higher cause.

I have a medical issue where once I open a file and start reading it, I can't go back. If i need to read a couple of lines above, I need to close the file, reopen it, and start over, hoping i wouldn't miss them again.

I don't need to tell you how bad let..in makes things for me.. needing to remember everything inside let, just so i can use it inside in. Countless times have I forgotten just because there was one too many line inside the let for me to remember. It's a good thing I have a shortcut for reopening files.

And doctors keep telling me how there is js compiler for haskell, but i stand my ground! And I will. keep. standing. my. ground.

[mgold]

@Birowsky I'm sorry to hear about your condition. Thank you for having the bravery to share.

I don't know how to balance your medical needs with the (non-medical) needs and preferences of the rest of the community, so I will bow out of this conversation.

[srid]

@mgold Yes, contrived: how often do you add a new parameter like this when making a change?

You are referring to the adding of c in this code?

f a b =
    let
        c = 10
    in
        a + b + c

There is no extra (function) parameter in the above; and isn't it common to abstract out a subset of expression and assign it to a variable for re-use? I do it all the time (using where in PureScript, or let in Elm).

When designing Elm, we like to start with a collection of real-world pain points

If I may ask? What is the (data) source for these real-world pain points if not the barrage of requests and complains in this Github Issues tracker?

[fosskers]

isn't it common to abstract out a subset of expression and assign it to a variable for re-use?

This is precisely the purpose of both let and where. The written out characters from the above example were contrived, but the example itself was not.

[mgold]

Yes, it's common enough to extract named expressions, and I may have been fooled by the generic-ness of a, b, and c. However, once a let (or Haskell where) is in use, extracting another item creates a simple diff in both cases.

If I may ask?

I may be grouchy on this thread, but this community never turns away an honest question!

What is the (data) source for these real-world pain points if not the barrage of requests and complains in this Github Issues tracker?

They're not data in any statistical sense, but we like to hold language discussions on the mailing list. The best of these focus on "how do I do this web development thing" or "how can I structure my application". This issue tracker is used by Elm's creator for bugs, not feature requests.

[ghost]

Continued on the mailing list: https://groups.google.com/forum/#!topic/elm-discuss/KiKF6K9gBKU

[alk-jerber]

Miso has where. 😉

[Mazuh]

nothing yet about this feature? there's only intended support to let ... in expressions as it is?

[fosskers]

@Mazuh see the mailing list link. Here's a summary of the arguments on both sides.

Note: Elm's creator didn't participate in any of the follow-up discussion (his last comment was in this GH thread in 2015), and considers the matter closed.

[srid]

I Haskell in the frontend nowadays and make both use of let and where. The intent-first thing is my primary motivation to use where clause.

Le dim. 22 juill. 2018 10:07 p.m., Colin Woodbury notifications@github.com a écrit :

@Mazuh https://github.com/Mazuh see the mailing list link. Here's a summary of the arguments on both sides. https://groups.google.com/forum/#!msg/elm-discuss/KiKF6K9gBKU/jzMuSTZmEwAJ

Note: Elm's creator didn't participate in any of the follow-up discussion (his last comment was in this thread in 2015), and considers the matter closed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/elm/compiler/issues/621#issuecomment-406918553, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPngtOGr2LPLRBErGt5e5RmTmXcFl-ks5uJS_dgaJpZM4B4ePC .

[lukewestby]

Hey folks, we're not gonna do where. Please see https://discourse.elm-lang.org/t/why-does-elm-support-let-but-not-where/1634/7 for an explanation.