Re: Expression-local variables and 'let'

>>Let's call balance the current balance. Now, display that balance, and 
>>warn the user if that balance is negative.
>>
>>vs
>>
>>Display the balance which is the current balance, and warn the user if 
>>that balance is negative.
>>
>>The first version is more complex: it starts by posing a binding, and 
>>then goes on with the main part. I think that's akin to first proving a 
>>lemma when what you want is to prove a certain theorem. If the lemma is 
>>    
>>
>
>I found I could understand the first one faster than the second one. Also,
>according to Flesch-Kincaid readability test as implemented in MS Word, the
>first one is easier to read (grade 5.5) than the second one (grade 6.6).
>  
>
I suppose that only takes into account one aspect, which is the precise 
understanding of all the details of the sentence. One of my points what 
that you can quickly spot the main point in the second form (display). 
When you read source code, there are different levels of reading. 
Sometimes you want a very precise understanding (of you're debugging 
that specific method for instance). Sometimes you want a general view, 
if you try to see the purpose: "OK, here we do some displaying".

We should also be careful about applying a _numeric_ mesure of the 
complexity of the text to the original program. For instance, does that 
mesure only account for the structure, or does it take into account 
length too? Programming languages are more concise, so a level of 
nesting that is not acceptable in natural language might be in a PL. I 
don't think two levels of 'if' are common when speaking, while they are 
in code, for instance.

>>With a less serious example: I would say "There is this person who is 
>>the brother in law of the boss of my wife's cousin. Well, i'm going to 
>>play music with him at his place", but I wouldn't say "There is this 
>>person who is my father. Well, i'm going to play music with him at his 
>>place", but "I'm going to play music with my father at his place" (in a 
>>program, you would write "at my father's place", because there is no 
>>implicit binder like it/him/her, unless you program in perl ;-)
>>    
>>
>
>You are mixing things around. Your first sentence is like:
>  
>
Agreed. This was introduced as a "less serious example". In the former 
one I tried to precisely follow the code. In this one my point was 
simply that there is a threshold about when splitting is necessary.

>>>You have to have seperate grammar constructs "single variable declaration"
>>>      
>>>
>>(for parameters) and "variable declaration" (for the general case). 
>>    
>>
>>That's a minor annoyance, especially given that their semantics 
>>scope-wise is different.
>>    
>>
>
>I mean, it makes it harder for someone learning the language to understand the
>syntax. 
>  
>
Do you think people will fall with "Oh, I always forget that you cannot 
bind multiple variables in a row inside an expression"?

>I don't think you can implement 'while' as a user-defined function with the same
>syntax since 'while' needs to be able to evaluate the expression in the
>parentheses multiple times. 
>
You can call the body multiple times. 'foreach' is implemented in 
nice.lang, for instance.
Am I missing something?

>>Yes, it's rarely used, but I'm not sure it's because the syntax is ugly. 
>>It can also be because methods should be short anyway, so you probably 
>>write a helper method instead of creating a nested scope. And for what's 
>>left, the extra trouble is probably not worth the extra scoping you get 
>>(if a method is 3-5 lines, then usage is easily spotted).
>>    
>>
>
>This is an argument against the construct in general, not the "let..in" syntax
>for it.
>  
>
Right. But this means that given the choice between 'let .. in' which 
solves better this "local scope" problem and offers some support for the 
"binding arguments" situation, and expression-local variables, which are 
tailore for "binding arguments", given that there is already a good 
enough way to handle "local scopes", I'll chose the latter, because the 
ration benefit/peculiarity is higher.

Daniel



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click