Eliminate final keyword?

[peteroc]

Hi,

Firstly I really like Dart. I have worked 90% with statically typed
languages but the facility to not have to specify types when I am
exploring a solution but am not definitive about it would be really
useful.

Anyway my question is whether it would be possible to eliminate the
use of the "final" keyword and somehow make it as easy and lightweight
to declare an immutable value as it is to declare a variable?
People are disinclined to use "final" in java because it seems verbose
(and maybe a bit uptight). In scala which has a "val" keyword it
seems much more natural to declare a final value.

Scala has a different syntax though e.g.

var x = 1;
val x = 1;

If the user wants to explicitly type a var/val they do:

var x: Int = 1;
val x: Int = 1;

And its clear that both var and val are equal citizens of the
language. This wouldn't work with Dart's syntax because you remove the
var (or val) keyword when explicitly typing . Would there be some
other way similar to the way underscore was used to specify that
something is private? Could you have a special assignment operator
like:

var x := 1; //x is bound to the value 1 and cannot be changed
var x = 1; //x can be reassigned to something else later.

Would this be too difficult to validate? For example if someone used
"=" at one stage in a program and later used ":=" would it just throw
a runtime exception? Is that how "final" works at the moment or is it
a static check? Is this any better than using the "final" keyword? (I
know that it won't work for declaration of method parameters but there
is no real point in declaring a method parameter final anyway in a
pass by reference language). Maybe you could say that an advantage of
the assignment syntax above is that in the case of member variables
you can see in the assignment whether its final or not without having
to go back an look at the declaration.

In summary: Does anybody think it would be a good idea to make it as
easy to declare an immutable value as it is to declare a variable? If
it is a good idea then what could the syntax look like?

Thanks,

Peter

[Gilad Bracha]

Hi,

We have thought a lot about this issue. 

I've been following Scala since before it was called Scala, and yes, in that context, the val/var distinction is nice. It doesn't carry over to Dart. Dart is trying very hard to be familiar to mainstream programmer's. Most people know what final means. So val is not an option.

The idea of using a different assignment syntax is something I have used in other language projects.  Again, not an option here.

I general, most fields are in fact used as finals, and one can make a good case that final should the default. But that again may surprise people. It also requires a concise way of saying a variable is not final.

I guess the executive summary is that familiarity is one our top objectives, and that tends to preclude the course of action you suggest.  At least so far, we have not seen a proposal that we think will fly. But keep them coming.

--
Cheers, Gilad

[peteroc]

Hi Gilad,

Thanks for the reply. It sounds reasonable given your requirements.
(If we didn't have some requirements/reality we wouldn't be making a
living!)

Peter.

[RPR]

On Oct 26, 9:59 am, Gilad Bracha <gbra...@google.com> wrote:
> We have thought a lot about this issue.

...

> I guess the executive summary is that familiarity is one our top objectives,
> and that tends to preclude the course of action you suggest.  At least so
> far, we have not seen a proposal that we think will fly. But keep them
> coming.

...


Trying to parse between the lines here to pin down what the ground
rules are for qualifying flying proposals. So far proposals fail to
fly based on the ill defined and rather loaded semantics of
"familiarity" and the "mainstream programmer".

As near as I can tell these terms are Dart Team newspeak (sorry Gilad,
couldn't resist) for the enterprise Java developer. Yes? No?

So any seriously considered doubleplusgood proposals should retain a
maximum degree of syntactic compatibility with Java and secondarily C+
+. Not much wiggle room there.

And so the semi-regular proposals from the Scala / Python / Ruby /
Javascript "familiar" folks attempting to inject a bit of elegance
into the syntax around some variation of def, var, val with postfix
type annotation are the Dart flying proposal equivalent to Led
Zeppelin. i.e. doubleungoodful thoughtcrime proposals :) Though I
expect they will continue to regularly pop on the Dart list for months
to come.

Frankly, I've been of the impression the debate is pretty much closed
in and around Dart syntax. Yet, on the other hand on more then one
occasion members of the Dart team, who have been very patient in this
area, have encouraged the list to "keep them (proposals) coming".
This seems to imply that there is as least some things still open for
debate that the Dart doesn't feel quite right with. Though for the
life of me, what they may be is unclear.

Could the Dart team please elaborate in what areas they are seeking
some input and flying proposals? The ground rules?

[Peter Ahé]

Hi RPR,

If something bothers you about Dart, or you have an idea, please share
it. We read all the feedback.

There are no ground rules about what you can suggest. Sometimes we can
tell you that we already considered a suggestion, and why we chose to
do something else. This is not meant to discourage anybody, this is
meant as background information.

Cheers,
Peter

[Bob Nystrom]

On Sat, Oct 29, 2011 at 11:10 AM, RPR <ray.r...@gmail.com> wrote:

Trying to parse between the lines here to pin down what the ground
rules are for qualifying flying proposals.  So far proposals fail to
fly based on the ill defined and rather loaded semantics of
"familiarity" and the "mainstream programmer".

It's not quite as simple as that, but those are very high priorities. That is balanced with trying to actually add value over existing mainstream languages. (For example, Dart's => function syntax isn't found in Java or JavaScript (but is in C#) but it's so useful that it justifies its relative novelty.)

As near as I can tell these terms are Dart Team newspeak (sorry Gilad,
couldn't resist) for the enterprise Java developer.  Yes? No?

That's a big part of it. Throw in a good dash of JavaScript experience and maybe some C# and you're probably a little closer.

 

So any seriously considered doubleplusgood proposals should retain a
maximum degree of syntactic compatibility with Java and secondarily C+
+.  Not much wiggle room there.

Maximizing compatibility is good. The less you do so, the more a given proposal will have to add value in other ways.

 

And so the semi-regular proposals from the Scala / Python / Ruby /
Javascript "familiar" folks attempting to inject a bit of elegance
into the syntax around some variation of def, var, val with postfix
type annotation are the Dart flying proposal equivalent to Led
Zeppelin.  i.e. doubleungoodful thoughtcrime proposals  :) Though I
expect they will continue to regularly pop on the Dart list for months
to come.

Others on the team may have a different opinion, but I don't think it's as simple as that. I think we all want elegance and expressiveness (I more than most). Remember, most of Dart's designers have a long Smalltalk background, one of the great forefathers as far as DSL-friendly languages go.

The challenge is that we want to improve the lives of not just the programmers who get excited about super flexible expressive syntaxes, but also the many many many programmers who've only ever lived within a C-style syntax and are uncomfortable venturing beyond it. Finding the right balance there is incredibly hard, and there's no easy answers.

Frankly, I've been of the impression the debate is pretty much closed
in and around Dart syntax.

With any language, the vast majority of proposals will end up not being implemented. I think you'll agree that if it wasn't that way, you'd end up with a language that's a hideous chimera of features pasted together, including many that directly contradict. It's really hard to keep a language simple, but that's one of the most important values a new language can provide. All of us have to be careful about giving up bits of that simplicity and making sure we get a lot of value in return, because once it's gone, it's gone for good. You can never remove a feature.

 

 Yet, on the other hand on more then one
occasion members of the Dart team, who have been very patient in this
area, have encouraged the list to "keep them (proposals) coming".

Right. Even if 99% (a made-up number) of the proposals and suggestions are discarded, that 1% has the opportunity to make a huge difference. We would love it if Dart took off and got very widely used and if so, the contributions people make to the language now can have a wide and lasting effect.

Even the proposals that aren't adopted add value. It's important to make sure we're aware of all of the options for how something should work. For paths we decide not to take, it's helpful to have someone suggest it so that we can have a publicly visible record of why we decided to not go that way. Otherwise it will just come up again and again.

- bob