[Haskell-cafe] Proposal: Non-recursive let

[Timon Gehr]

On 07/11/2013 08:37 AM, AntC wrote:
>> <oleg <at> okmij.org> writes:
>> ...
>> In Haskell I'll have to uniquely number the s's:
>>
>>          let (x,s1)  = foo 1 [] in
>>          let (y,s2)  = bar x s1 in
>>          let (z,s3)  = baz x y s2 in ...
>>
>> and re-number them if I insert a new statement.
>>
>> I once wrote about 50-100 lines of code with the fragment like the
>> above and the only problem was my messing up the numbering (at one
>> place I used s2 where I should've used s3). ...
>
> Oleg, I hope you are not saying that in production code you use names like
> x, y, z, s1, s2, s3, s4, ...
>

Depending on context, those can be perfectly good names, modulo the 
numbering. I'd be more worried about 'foo', 'bar', 'baz'. :o)

> It leads to opaque code.

Questionable. Typically there tends to be more relevant information in 
the name of an arrow than in the name of a point, with the arrows 
connecting the points and thus clarifying their meaning.

> If even you can mess up, what hope for us with only nano-Oleg brain capacity?
>

Non-recursive let.


(On a less tongue-in-cheek note, IMHO, assuming that there is something 
like a constant 'brain capacity' significantly varying between persons 
that limits how well one can master a certain discipline is a good start 
for painting oneself into a corner.)

> Next you'll be wanting GOTO  and destructive assignment.
>

Unlikely. Haskell already has constructs which are more expressive than 
goto and destructive assignment, without requiring the language to give 
up the benefits of the absence of those features in direct code.

> Who knows: one day somebody modifying your code might need to insert a
> line. (That 'somebody' might be your future self.)
>

(That was part of his point.)

> Just don't do that! Use long_and_meaningful names.
>

'meaningful' is long enough.

> 50-100 near-identical lines of code sounds like an opportunity for an
> algorithm.
>...

He expressed that he wrote 50-100 lines of code containing such a short 
fragment and the only problem was inside that fragment. Since the goal 
of that anecdote presumably was to establish the relevance of a pitfall 
that a non-recursive let would make less severe, I think this is a more 
natural way to interpret the only slightly ambiguous wording.