Re: Expression-local variables and 'let'

Quoting Daniel Bonniot <[email protected]>:

> 
> >>you can write:
> >>
> >>  bar(int x = foo(), x > 0);
> >>
> >>using(PrintStream s = ...) {
> >>  s.println("...");
> >>}
> >
> >My initial reaction was that the scope of x should not go past the comma,
> > and the scope of s should not go outside of the parentheses. 
> >
> Then the binding would be useless, it would have an empty scope!

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

> >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");
}

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

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);

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. 


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

> >Anyway, if you don't like "let" in your original expression-local let
> >syntax, why not replace it with "final"? "val" has no meaning to anybody that
>
> That's an interesting idea. The problem is that we used to have 'final' 
> but replaced it by 'let' because some people dislike 'final' being used 
> with different meanings (final class/final variable).

Okay, I had not realized this. I thought that we could use "final" as in Java
(with both meanings), but I tested it and in fact it doesn't work.

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

- Brian




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