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

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

On Wednesday, 4 January 2017 16:52:17 UTC-5, Andrew Radford wrote:
>
> 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 20:30:25 UTC, Joey Eremondi wrote:
>>
>> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

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) 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 20:30:25 UTC, Joey Eremondi wrote:
>> 
>>> 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+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] Re: Feature: 'where' expressions (continued from GitHub)

['Andrew Radford' via Elm Discuss]

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 20:30:25 UTC, Joey Eremondi wrote:
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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

On Wed, Jan 4, 2017 at 12:20 PM, 'Andrew Radford' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> 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`*
>>
>> 
>>
> --
> 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] Re: Feature: 'where' expressions (continued from GitHub)

['Andrew Radford' via Elm Discuss]

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`*
>
> 
>

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

> Am 03.01.2017 um 17:39 schrieb 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 = ...
> 
> -- 
> 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] Re: Feature: 'where' expressions (continued from GitHub)

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

2017-01-03 10:43 GMT+01:00 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 = ...
>
>
>
>
>
> On Tuesday, January 3, 2017 at 1:26:33 AM UTC-5, Janis Voigtländer wrote:
>>
>> 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?
>>
>> Am 02.01.2017 um 23:10 schrieb 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 = ...
>>
>>
>> On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer 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+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] Re: Feature: 'where' expressions (continued from GitHub)

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

 



On Tuesday, January 3, 2017 at 1:26:33 AM UTC-5, Janis Voigtländer wrote:
>
> 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?
>
> Am 02.01.2017 um 23:10 schrieb 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 = ...
>
>
> On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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?

> Am 02.01.2017 um 23:10 schrieb 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 = ...
> 
> 
>> On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer 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+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] Re: Feature: 'where' expressions (continued from GitHub)

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


On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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

2017-01-02 5:57 GMT+01:00 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?
>
> On Sun, Jan 1, 2017 at 9:21 PM Janis Voigtländer <
> janis.voigtlaen...@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+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] Re: Feature: 'where' expressions (continued from GitHub)

[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?

On Sun, Jan 1, 2017 at 9:21 PM Janis Voigtländer <
janis.voigtlaen...@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+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] Re: Feature: 'where' expressions (continued from GitHub)

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

​

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

[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 :

> > 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.
>
> --
> 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] Re: Feature: 'where' expressions (continued from GitHub)

[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. :-)
​

2016-12-31 23:46 GMT+01:00 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.
>
> --
> 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] Re: Feature: 'where' expressions (continued from GitHub)

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

[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.)
​

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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






-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

Colin Woodbury  schrieb am Sa. 31. Dez. 2016 um 20:36:

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

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

[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 

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

[Peter Damoc]

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

[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 

. 

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

[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?

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

['Rupert Smith' via Elm Discuss]

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.

-- 
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] Re: Feature: 'where' expressions (continued from GitHub)

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

On Friday, 30 December 2016 09:10:52 UTC-8, Will White 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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

On Fri, Dec 30, 2016 at 11:34 AM, 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.
>
> Op vrijdag 30 december 2016 18:10:52 UTC+1 schreef Will White:
>>
>> 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+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] Re: Feature: 'where' expressions (continued from GitHub)

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

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