Immutable bindings

[kc]

There has been some debate re using 'val' instead of 'final' for immutable bindings.

'val' via it's terseness makes it easier to do the right thing in most cases - and is symmetrical with 'var' - easy to convert from one to the other.

Proposal:

1) Currently function paramater bindings are mutable. Would it be desirable to make them immutable by default:

// Error - as function signature defaults to: test(val a)

test(a) { 

   a = 2; 

}

// For a mutable binding

test(var a) {

   a = 2;

}

2) For loops default to val bindings

val lst = [1,2,3];

for (i in lst) print(i); // defaults to: for (val i in lst) print(i);

// Want to set the loop variable

for (var i in lst) print(i); 

Surely this would aid the parsing and runtime DartVM performance.

And make it's easier for developer's to do the right thing without being overly restrictive/constraining.

K.

[kc]

On Saturday, May 18, 2013 12:58:23 PM UTC+1, kc wrote:

There has been some debate re using 'val' instead of 'final' for immutable bindings.

Come on!

Immutable bindings by default for function paramaters and 'for' loop variables.

Make it easy for both developers to succinctly do the right thing and the Dart VM to optimise.

K.

[Iván Zaera Avellón]

+1 for immutable params.

But I prefer final to val. ;-)

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
 
 

[kc]

On Sunday, May 19, 2013 11:33:33 AM UTC+1, Iván Zaera Avellón wrote:

+1 for immutable params.

Good.

What about immutable loop variables in 'for' loops. Updating the loop var is very bad practice. 

var lst = [2,4,6];

for (final i in lst) {

     i = i + i; // Error - this is bad

}

And if immutable ('final/val/let'/whatever) or 'var' is not explicitly used then default to the immutable binding:

var lst = [2,4,6];

for (i in lst) { // i Defaults to 'final/val/let'

     i = i + i; // Error - this is bad

}

Basically:

- make it easy for developers to do the right thing - but give them the option to do the wrong thing if they must with 'var'.

- aid the DartVM with immutable loop var. The whole point of Dart is a language that works with the DartVM - not against it.

K.

[Gen]

Why not just dropping the "final" keyword and make it the default for identifier declarations ?

[kc]

On Sunday, May 19, 2013 1:37:53 PM UTC+1, Gen wrote:

Why not just dropping the "final" keyword and make it the default for identifier declarations ?

Too unfamiliar. It would be like Python - would need a nonlocal keyword.

There's nothing wrong with familiar - it's just that Dart have choosen *'familiar with Java/C#* - when developers are moving *away* from these languages.

The sweet spot for syntax is succinct, readable - and by default the right thing is done. Without being overly restrictive.

K. 

[James Wendel]

The Dart team has been very clear in their intentions and talk that they are focusing on people that are familiar with C/C++ style languages.  They have already chosen their target audience, so they built the language syntax around that.  Syntax is just a small part of a language, and once you get used to it, it's easy to code in any language.  If start changing things now (especially something as big as 'final'), it will confuse a lot of people.

The core language syntax IS NOT CHANGING for at least a few months.  The team is working on hammering down everything to launch Dart 1.0.  Maybe sometime after that they may consider language changes, but they have said for the last 6 months that there will be no more major syntax or core changes until after 1.0.  So I'm guessing they are going to wait to see how the language is received at that point and decide what they want to do.

[kc]

On Sunday, May 19, 2013 3:28:24 PM UTC+1, James Wendel wrote:

The Dart team has been very clear in their intentions and talk that they are focusing on people that are familiar with C/C++ style languages.  They have already chosen their target audience, so they built the language syntax around that.  

They chose wrong. The target audience does not exist.

 

The core language syntax IS NOT CHANGING for at least a few months.  The team is working on hammering down everything to launch Dart 1.0.  Maybe sometime after that they may consider language changes, but they have said for the last 6 months that there will be no more major syntax or core changes until after 1.0.  So I'm guessing they are going to wait to see how the language is received at that point and decide what they want to do.

It's not the core C syntax - that's fine:

if (expression) {statements; } 

It's the type system notation. It's wrong. Utterly misleading for a language which is as dynamic as Dart. As Bob N. rightly noted it looks like static allocations are made.

Get it right *before* 1.0.

The Dart team should:

- focus on getting the VM on x86 and ARM to 0.9

- then get dart2js in sync with the VM

- leave the tools/editor and type inference/analyzer to Jet Brains.

K. 

[Vyacheslav Egorov]

> - aid the DartVM with immutable loop var. The whole point of Dart is a language that works with the DartVM - not against it.

In majority of cases that would not aid VM even a single bit: in fact local variables completely disappear when optimizing compiler does its job.

// Vyacheslav Egorov

K.

[kc]

On Sunday, May 19, 2013 3:39:54 PM UTC+1, Vyacheslav Egorov wrote:

> - aid the DartVM with immutable loop var. The whole point of Dart is a language that works with the DartVM - not against it.

In majority of cases that would not aid VM even a single bit: in fact local variables completely disappear when optimizing compiler does its job.

At runtime.  It compiles at runtime. Therefore anything which assists compilation is good. Especially when it's what the developer wants to semantically express.

K.

[Vyacheslav Egorov]

> Therefore anything which assists compilation is good.

Let me repeat again: for local variables it does *not* really assist, there are *no* local variables after SSA construction. If you make all variables immutable that would certainly assist by allowing compiler to skip SSA construction phase, but with a mixture of immutable and mutable variables there is not much of help.

[there are some cases when you can end up producing a bit better code if you compare immutable vs. mutable captured variables but that's it]

// Vyacheslav Egorov

K.

--

[kc]

On Sunday, May 19, 2013 3:55:30 PM UTC+1, Vyacheslav Egorov wrote:

> Therefore anything which assists compilation is good.

Let me repeat again: for local variables it does *not* really assist, there are *no* local variables after SSA construction. If you make all variables immutable that would certainly assist by allowing compiler to skip SSA construction phase, but with a mixture of immutable and mutable variables there is not much of help.

In some blocks all bindings immutable is a definite possibility.

K.

[Vyacheslav Egorov]

> In some blocks all bindings immutable is a definite possibility.

VM would still have to apply generic algorithm, have the same generic IR for unoptimized code if it's only *some* blocks. *Some* does not help. You need *all* code to be in a single-assignment form (e.g. like Erlang) to change the way VM builds compiler IR. But even then the gain is questionable: yes, you can remove one phase from compiler, but it is not really the most expensive phase at all.

So overall you should not use VM as an argument for your suggestion.

// Vyacheslav Egorov

K.

--

[Gen]

Am Sonntag, 19. Mai 2013 14:28:24 UTC schrieb James Wendel:

On Sunday, May 19, 2013 8:12:26 AM UTC-5, kc wrote:

On Sunday, May 19, 2013 1:37:53 PM UTC+1, Gen wrote:

Why not just dropping the "final" keyword and make it the default for identifier declarations ?

Too unfamiliar. It would be like Python - would need a nonlocal keyword.

There's nothing wrong with familiar - it's just that Dart have choosen *'familiar with Java/C#* - when developers are moving *away* from these languages.

The sweet spot for syntax is succinct, readable - and by default the right thing is done. Without being overly restrictive.

K. 

The Dart team has been very clear in their intentions and talk that they are focusing on people that are familiar with C/C++ style languages.  They have already chosen their target audience, so they built the language syntax around that.  Syntax is just a small part of a language, and once you get used to it, it's easy to code in any language.  If start changing things now (especially something as big as 'final'), it will confuse a lot of people.

I do not think that Lars and Gilad love the C syntax. It is just a common syntax without major flaws.
Lars wanted to have the flexible and classic programming style from the C family including Java and Javascript.
But there is no reason not to change one or the other superfluous keyword.

Syntax is not where the effort of transition lies, but the libraries and async and isolates instead of classic threads.
 

The core language syntax IS NOT CHANGING for at least a few months.  The team is working on hammering down everything to launch Dart 1.0.  Maybe sometime after that they may consider language changes, but they have said for the last 6 months that there will be no more major syntax or core changes until after 1.0.  So I'm guessing they are going to wait to see how the language is received at that point and decide what they want to do.

If they do not change this year, then better never.
Nobody will complain about a better syntax for a new language.
Actually, who would not expect different and better from a new language ?
But everybody will complain once code and tools are breaking and the already learned Dart becomes cluttered with changes and optional syntax.
Many people are very reluctant regarding changes after the symbolic 1.0.

[Gen]

Thanks for this clarification.
I really love how the Dart team cares about this forum. There is no comparison :-)

[kc]

On Sunday, May 19, 2013 5:34:18 PM UTC+1, Gen wrote:

I do not think that Lars and Gilad love the C syntax. It is just a common syntax without major flaws.
Lars wanted to have the flexible and classic programming style from the C family including Java and Javascript.
But there is no reason not to change one or the other superfluous keyword.

It' s not the core C syntax that's the issue. That's OK. 

But the C type syntax does have 'major flaws' for a dyanamic language like Dart.

And the fact the users can change:

var x = 1;

to:

int x = 1;

is incredibly misleading. Looks like a duck type going to a static int.

I am *not* proposing any changes to the VM. None.

 

Syntax is not where the effort of transition lies, but the libraries and async and isolates instead of classic threads.
 

That's where the action/good stuff is. But why cover it with a misleading syntax.

 

K.