Re: Expression-local variables and 'let'

>What I meant was, when reading the code I thought "the scope of x should not go
>past the comma, but that doesn't make sense, because then the binding would be
>useless, it would have an empty scope. So what does it mean then?"
>  
>
OK, I can understand. On the other hand, we are not inventing a 
completely new and arbitrary rule. The precedents are 'for (int x = 
...)' in C/C++/Java, and 'using' in C# (can variables actually be 
declared there?)

>>>But, I guess this is
>>>what happens in formal parameter declarations anyway. 
>>>
>>>      
>>>
>>I don't get that.
>>    
>>
>
>I meant, that parentheses do not limit parameters' scopes the same way that
>braces limit variables' scopes (for loops are similar):
>
>void f(PrintStream s) {
>   // s is visible here
>   s.println("asdf");
>}
>  
>
Right, that's a good point.

>>>Since "var" and "let" are "new" to Nice (compared to Java), why not just use
>>>      
>>>
>>the ML/OCL/Haskell "let...in" syntax for them? That is, make all 'let' and
>>'var' expressions "expression-local". Before we would write:
>>    
>>
>>But this syntax does not lead to more conciseness (exactly like what you 
>>can currently do). So I don't see what it brings.
>>    
>>
>
>I thought the motivation for expression local variables was to limit scope, not
>to add conciseness. That was the motivation mentioned in Dev/BlockCallSyntax in
>the wiki. 
>
It's both.

>In fact, if you look at the examples you will see that the conciceness
>is questionable:
>
>     int x = foo(); bar(x, x > 0);
>     bar(int x = foo(), x > 0);
>
>You saved three characters, one of which is a space. 
>  
>
Yes, but you cheated a bit! ;-)
In the first version x escapes the scope. You could add braces, but that 
becomes more criptic. Having two statements on one line is not very 
common nor considered good practice.
I would also think the second form is more readable, but of course 
opinions can differ.

>What does the following mean? I assume it passes two arguments to bar but it
>could also be misread as declaring two arguments:
>
>    bar(int x = 1, y = 0);
>  
>
I would say you assume right. You will get a 'unused variable' for x, 
and y needs to be declared previously.

>The "let...in" syntax limits scope in the same way that the proposed syntax
>does. "let...in" lets you limit the scope of multiple variables at once. It
>seems like the proposed syntax only lets you limit the scope of a single
>variable at once. 
>  
>
More precisely, the goal of the new syntax is to give a name to a method 
argument, so that you can reuse it in other arguments. 'let ... in' does 
not give the same convenience to do that.
You can name several arguments, of course.

If you need to define several variables in a limited scope, you can 
already use the C-syntax idiom (should I say Algol?):

{
   let x = ...;
   let y = ...;
   ...
} // scope ends for x and y

>>Expression-local variables basically take this special handling, and 
>>generalize it to a general-purpose construct. This means that the new 
>>construct is not alien, it's a generalization. This also means you can 
>>implement "new syntax" like the 'using' statement purely in the language 
>>instead of hard-wiring it in the language definition and in the parser. 
>>This means the language is both simpler (less special cases) and more 
>>expressive.
>>    
>>
>
>Sure, I realize the benefit, I just think the proposed syntax is not very
>intuitive. But, from your ratoinale in this email I have a better feeling about
>it than I did before.
>  
>
Good. So discussion is useful ;-)

>>I don't think 'val' will only speak to ML users. Well, maybe it will 
>>from experience, but it should not be hard to get used to it. Isn't the 
>>idea of 'value' quite simple and appropriate? A 'let' binding is just a 
>>name for the value it binds to.
>>    
>>
>
>I don't really have a preference. Does this mean that all uses of "let" should
>be replaced by "var"?
>  
>
My plan was to replace it by 'val', because
  1) let inside an expression hurts my linguistic feelings (Bryn's too, 
from private email)
  2) we should avoid two keywords for the same concept

I note that Isaac is worried about var and val being too similar. That 
people object to "overloading" the 'final' keyword.

It's hard to please everyone. Who will come up with the magic solution 
to please them all? ;-)

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