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