Expression-local variables and 'let'

Daniel Bonniot <[email protected]>
Newsgroups gmane.comp.lang.nice.general
Message-ID <[email protected]>
Hi,

A new feature that is already implemented in the development version is 
the ability to introduce local variables inside an expression (while 
that was only possible as a statement). A benefit is that you can give a 
name to an argument, and be able to refer to it in another argument. 
Instead of:

  int x = foo();
  bar(x, x > 0);

you can write:

  bar(int x = foo(), x > 0);

First, this form is more compact (while hopefully still perfectly 
readable), and will allow more simple method implementations to be made 
of a single expression, which makes it possible to use the short form 
(type name(...) = ...;). And additional benefit that x is not visible in 
the rest of the block.  If you need it, then it makes sense to introduce 
it with the first form.

This syntax is especially useful combined with the new syntax for method 
calls with an anonymous function argument:

using(PrintStream s = ...) {
  s.println("...");
}

It's quite a neat feature that this is user-definable, pure Nice code 
('using' included). No special handling in the parser.

The question I'd like to raise is the following. Sometimes it is nicer 
not to have to write explicitely the type of the new variable, but to 
let the compiler find it out. For variable declarations as statements, 
we have 'let' and 'var', for respectively immutable bindings and 
variables. It would be good to have the same feature for 
expression-local variables. However, although 'var' is fine in this 
context, 'let' seems very awkward:

  using (let s = new PrintStream(...)) { ... }

I guess the awkwardness comes from 'let' being something that fits well 
the begining of a sentence, not a qualifier to an object (in the 
linguistic sense). 'var', short form of 'variable', fits well this role, 
and the equivalent for immutable binding could be 'value', in short 'val':

  using (val s = new PrintStream(...)) { ... }

"Using the value s which is the PrintStream ..., ...".

So I think we should use the 'val' keyword in this context. Now, it 
seems strange to have both 'let' and 'val' for the same concept, 
depending on the context. So we could use 'val' everywhere, which would 
be more consistent with 'var' anyway. Yes, those two keywords differ by 
only one character, but they are still quite distinguisable, and editors 
could easily display them in different color or whatever. Besides, 
mistaking one for the other does not have strong consequences. And 'r' 
and 'l' are luckilly not close on the keyboard :-)

It was also argued that 'val' has a more straightforward meaning that 
'let', especially to non-native speakers, while 'let' might remind 
people about BASIC, can you imagine that !?!  ;-)

Is there any objection to these changes? 'let' would of course be 
supported for quite a long time, to allow for a smoother transition.

Daniel

PS: for those who want to try the dev version, it currently implements 
the 'let' and 'var' variants, not the one with a type.



-------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.