Re: [elm-discuss] Why `let`?
Dnia 2017-04-23, o godz. 10:34:22 Tom Ayerst napisał(a): > "where" would be nice though... > > foo a b = >x + y > where > x = a > y = b Most people read from top to bottom not otherwise. So let - in gives information in proper order: Let -- using this saw, plane, hammer, nails, two boards, two planks in -- do that make bookshelf https://github.com/elm-lang/elm-compiler/issues/621 https://groups.google.com/forum/?fromgroups=#!topic/elm-discuss/KiKF6K9gBKU :) -- Wojciech S. Czarnecki ^oo^ OHIR-RIPE -- 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] Why `let`?
"where" would be nice though... foo a b = x + y where x = a y = b On 23 April 2017 at 10:17, Jan Tojnar wrote: > On Sunday, 23 April 2017 02:23:20 UTC+2, Witold Szczerba wrote: >> >> in real code things are much more complicated and confusing. I have >> looked at the Todo.elm you prepared and (for me) it is much harder to >> reason about. >> > > I agree, it is especially confusing once we get to *destructing*: > > https://github.com/rtfeldman/elm-todomvc/blob/ > 8678c8bcaeb5cb4b3f87dbefb7a01b5fe492dbc7/Todo.elm#L44 > > let – in allows quick visual distinction between definitions and the main > statement. > > Cheers, > > Jan Tojnar > > -- > 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] Why `let`?
On Sunday, 23 April 2017 02:23:20 UTC+2, Witold Szczerba wrote: > > in real code things are much more complicated and confusing. I have looked > at the Todo.elm you prepared and (for me) it is much harder to reason about. > I agree, it is especially confusing once we get to *destructing*: https://github.com/rtfeldman/elm-todomvc/blob/8678c8bcaeb5cb4b3f87dbefb7a01b5fe492dbc7/Todo.elm#L44 let – in allows quick visual distinction between definitions and the main statement. Cheers, Jan Tojnar -- 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] Why `let`?
I would agree with Noah Hall, the let/in keywords make parsing easier. In a simple expression like you provided: a = 5 b = 6 a + b it's all clear, but in real code things are much more complicated and confusing. I have looked at the Todo.elm you prepared and (for me) it is much harder to reason about. Regards, Witold Szczerba On Sat, Apr 22, 2017 at 10:23 PM, Noah Hall wrote: > Two notes: > > Let bindings do not have order. Using them in the way suggested > implies order. In this world, they would have to be ordered or > confusion would reign. This is more imperative style. > > I've actually really disliked this in CoffeeScript/Ruby, that > implicitly the last item in the block is the thing returned. Makes it > a lot harder to parse mentally. > > -1. > > On Fri, Apr 14, 2017 at 10:00 PM, Akio Burns wrote: > > It's not clear to me why Elm uses `let`, instead of simply scoping > > definitions to the expression below them. > > > > > > With `let`: > > > > foo = > > let > > a = 1 > > b = 2 > > in > > a + b > > > > Scoping definitions to the expression below them: > > > > foo = > > a = 1 > > b = 2 > > > > a + b > > > > > > I understand that each function must contain a single expression. In Elm, > > although they contain expressions, definitions are not expressions. > > > > > > Visualized: > > > > foo = > > > > > > foo = > > a + 2 <- EXPRESSION > > > > foo = > > a = 1 <- DEFINITION SCOPED TO THE a + 2 EXPRESSION > > a + 2 > > > > > > Another way to demonstrate scope is: > > > > let > > a = 1 > > b = 2 > > in > > a + b > > > > would become (parenthesis to demonstrate scope): > > > > ( > > a = 1 > > b = 2 > > > > a + b > > ) > > > > > > It seems to me that `let` and `in` are unnecessary and verbose. Put > another > > way, I think few people would agree that requiring a keyword before > variable > > assignment `set a = 1` would be a good idea. The `=` makes the intent > > explicit. Likewise, indentation—or parenthesis—could make scopes > explicit, > > and `let` and `in` unnecessary. > > > > Some have argued that without `let`, we could not have arbitrarily nested > > scopes. I don't have significant experience with Elm, but I would guess > that > > nesting `let`s today is pretty big code smell. Instead of nesting `let`s > to > > reuse variable names, developers should either pick more descriptive > > variable names, or abstract into a function. > > > > > > This could—of course—apply anywhere an expression is expected: > > > > True -> > > x = 0 > > y = 0 > > > > (x, y) > > ... > > > > > > @rtfeldman on the Slack pointed out that this syntax is more diff > friendly: > > > > if I write a view function like > > view model = > > div [] > > [ ... lots of other stuff ] > > > > and then I want to introduce a nested constant like so: > > view model = > > let > > foo = ... > > in > > div [] > > [ ... lots of other stuff ] > > > > the fact that I indented the final expression makes the VCS diff explode > > this happens to me all the time, and it's pretty annoying > > with [this] idea it wouldn't happen anymore > > > > > > Lastly, here's elm-todomvc with scoped definitions, courtesy of > @rtfeldman > > again: > > > > https://github.com/rtfeldman/elm-todomvc/blob/ > 8678c8bcaeb5cb4b3f87dbefb7a01b5fe492dbc7/Todo.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. > -- 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] Why `let`?
Two notes: Let bindings do not have order. Using them in the way suggested implies order. In this world, they would have to be ordered or confusion would reign. This is more imperative style. I've actually really disliked this in CoffeeScript/Ruby, that implicitly the last item in the block is the thing returned. Makes it a lot harder to parse mentally. -1. On Fri, Apr 14, 2017 at 10:00 PM, Akio Burns wrote: > It's not clear to me why Elm uses `let`, instead of simply scoping > definitions to the expression below them. > > > With `let`: > > foo = > let > a = 1 > b = 2 > in > a + b > > Scoping definitions to the expression below them: > > foo = > a = 1 > b = 2 > > a + b > > > I understand that each function must contain a single expression. In Elm, > although they contain expressions, definitions are not expressions. > > > Visualized: > > foo = > > > foo = > a + 2 <- EXPRESSION > > foo = > a = 1 <- DEFINITION SCOPED TO THE a + 2 EXPRESSION > a + 2 > > > Another way to demonstrate scope is: > > let > a = 1 > b = 2 > in > a + b > > would become (parenthesis to demonstrate scope): > > ( > a = 1 > b = 2 > > a + b > ) > > > It seems to me that `let` and `in` are unnecessary and verbose. Put another > way, I think few people would agree that requiring a keyword before variable > assignment `set a = 1` would be a good idea. The `=` makes the intent > explicit. Likewise, indentation—or parenthesis—could make scopes explicit, > and `let` and `in` unnecessary. > > Some have argued that without `let`, we could not have arbitrarily nested > scopes. I don't have significant experience with Elm, but I would guess that > nesting `let`s today is pretty big code smell. Instead of nesting `let`s to > reuse variable names, developers should either pick more descriptive > variable names, or abstract into a function. > > > This could—of course—apply anywhere an expression is expected: > > True -> > x = 0 > y = 0 > > (x, y) > ... > > > @rtfeldman on the Slack pointed out that this syntax is more diff friendly: > > if I write a view function like > view model = > div [] > [ ... lots of other stuff ] > > and then I want to introduce a nested constant like so: > view model = > let > foo = ... > in > div [] > [ ... lots of other stuff ] > > the fact that I indented the final expression makes the VCS diff explode > this happens to me all the time, and it's pretty annoying > with [this] idea it wouldn't happen anymore > > > Lastly, here's elm-todomvc with scoped definitions, courtesy of @rtfeldman > again: > > https://github.com/rtfeldman/elm-todomvc/blob/8678c8bcaeb5cb4b3f87dbefb7a01b5fe492dbc7/Todo.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.
[elm-discuss] Why `let`?
It's not clear to me why Elm uses `let`, instead of simply scoping definitions to the expression below them. With `let`: foo = let a = 1 b = 2 in a + b Scoping definitions to the expression below them: foo = a = 1 b = 2 a + b I understand that each function must contain a single expression. In Elm, although they contain expressions, definitions are not expressions. Visualized: foo = foo = a + 2 <- EXPRESSION foo = a = 1 <- DEFINITION SCOPED TO THE a + 2 EXPRESSION a + 2 Another way to demonstrate scope is: let a = 1 b = 2 in a + b would become (parenthesis to demonstrate scope): ( a = 1 b = 2 a + b ) It seems to me that `let` and `in` are unnecessary and verbose. Put another way, I think few people would agree that requiring a keyword before variable assignment `set a = 1` would be a good idea. The `=` makes the intent explicit. Likewise, indentation—or parenthesis—could make scopes explicit, and `let` and `in` unnecessary. Some have argued that without `let`, we could not have arbitrarily nested scopes. I don't have significant experience with Elm, but I would guess that nesting `let`s today is pretty big code smell. Instead of nesting `let`s to reuse variable names, developers should either pick more descriptive variable names, or abstract into a function. This could—of course—apply anywhere an expression is expected: True -> x = 0 y = 0 (x, y) ... @rtfeldman on the Slack pointed out that this syntax is more diff friendly: if I write a view function like view model = div [] [ ... lots of other stuff ] and then I want to introduce a nested constant like so: view model = let foo = ... in div [] [ ... lots of other stuff ] the fact that I indented the final expression makes the VCS diff explode this happens to me all the time, and it's pretty annoying with [this] idea it wouldn't happen anymore Lastly, here's elm-todomvc with scoped definitions, courtesy of @rtfeldman again: https://github.com/rtfeldman/elm-todomvc/blob/8678c8bcaeb5cb4b3f87dbefb7a01b5fe492dbc7/Todo.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.
