Idea: in-let instead of let-in

Request Feedback
1

Premise: Source code is easier to read and understand when a module’s functions are ordered from high-level (what the module does) to low-level (the implementation details). It would be nice if a function with a let expression could be organised the same way.

In Elm, as in other ML languages, you can declare a set of locally-scoped functions that are available as helpers to evaluate an expression:

three =
    let
        one =
            1

        two =
            2
    in
    one + two -- 3

This function might be easier to read and understand if it could be written like this:

three =
    in
        one + two
    let
    one =
        1

    two =
        2

To me this is clearly better, but I bet there are many who would disagree.

I’d be curious to hear what @evancz and any other experienced language designers reading this thought.

3 Likes
2

Please have a look at this one Why does Elm support 'let' but not 'where'?.

6 Likes
3

That thread says that where isn’t going to be implemented, but allowing let/in to be written as in/let isn’t really an additional syntax like where would be. :grin:

4

Maybe I’m slow on the up-take, but I’m genuinely confused as to why “in-let” makes sense?

To me the current “let-in” makes sense… you’re saying “let these functions apply in the following”.

1 Like
5

To me “in-let” also makes perfect sense as it means “in the following let these functions apply”.

1 Like
6
  • like Yoda code, it reads
  • more verbose than where
  • decision onwhere has already been made
7

When I code in Haskell these days, I never use where clauses. I use let expressions instead, but probably less often that people might expect. When a let is getting out of hand (to my eye) I start making helper functions to get things out of there.

So a complex function may end up being 3 or 4 functions all under a big comment header like -- CRAWL FILES. These comment headers are how I navigate through large files, and I think they work really nicely!

I find that the result is ordered how I want and easier to read than anything else I have tried, and there are lots of things to try with Haskell syntax!

I think the current syntax in Elm encourages similar coding practices. “Wow, this let is getting long and hard to understand! Maybe I should make a helper function…” I think that is a feature.

Note: The resulting helper functions end up needing more arguments passed in. I also think this is a feature. I used to have where clauses where you couldn’t really tell where all the inputs were coming from easily, and things generally became less confusing when I moved them to the top level and made the arguments fully explicit.

8 Likes
8

I like this too.

But leaving functions inside let allow me to unambiguously indicate this function is only a helper function to this — instead of my module having many top level functions, but some having to “oh don’t look at these, they are just helpers for that function”

(One may argue that difference is a job for exposing)

1 Like
9

Thanks for the insight, @evancz! Makes sense to me.

10

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.