Lightening Dart syntax

[kc]

I can see how Dart would be appealing to developers coming from Java - but maybe not so much for those coming from scripting languages - Python, Ruby - and even JS.

Some simple suggestions for lightening Dart's syntax which have *NO* effect on the runtime and minimal on the parsing/AST:

1. 'Any' not 'dynamic'
2. 'let' not 'final' for immutable locals
3. 'new' optional
4. type annotation syntax either:
    a) test(int a) -> int { // code }
    b) test(a:int):int { // code }
5. shorthand syntax for POD's
    class Point(int x, int y);
6. syntax for immutable and constant classes
    let class Point(int x, int y); // immutable class
    const class Point(int x, int y); // 'value' class which can be constant'ed

And ideally, make it a bit more painful to type annotate locals (to give a clearer type inference story):

// type annotate if you must but it's adding no real value
var int x = 3;
// or with ':'
var x:int = 3;

This then gives a light, clean foundation for Dart 2.0 and broadens Dart's appeal.

// nonsense example

class Point(int i, int y);

myfunc(int a) -> Point {
    let lst = [2,4,6];
    for (let i in lst) {
        let i = i * a;
        print(i);
    }
    return Point(3,3);
}

K.

[Gen]

Maybe the "new" keyword will be dropped but probably not. I remember we had that discussion already ;)

The POD proposition with implicit constructor definition might be useful:
- class Point(int x, int y)
- final class Point(int x, int y) ; //all members final
- const class Point(int x, int y) ; // all members constant

I propose in addition:
- final class P {...} ; //all members final
- const class P {...}; // all members constant

With regard to the other changes, I see no improvement but rather disadvantages.
Especially:
1) Why "any" if you can omit the type ?
2) Adding postfix typing introduces variation without benefit but makes code harder to read if styles are mixed all the time.
3) Why making typing more painful (and breaking compatibility) ?

[Enrique Gavidia]

I'm not sure about the other suggestions, but I definitely agree with the postfix instead of prefix type annotations. It just makes actually *reading* code flow a lot smoother -- all your variables and methods line up nicely against the left margin, making it easy to spot what you're looking for with a single smooth vertical eye motion. I've recently started putting my type annotations on their own line before the vars/methods for this reason.  Unfortunately that seems like too big of a change to make post-1.0, especially since the whole goal of Dart's syntax was 'familiarity'... Similarly, "final" is probably more 'familiar' than "let" for most people.

I am liking the "Any" instead of "Dynamic" idea though. It would be less awkward to read than just omitting the type for one param in the middle of a ton of annotated vars in a function definition...

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Enrique Gavidia
415.577.4912
www.enriquegavidia.com

[Lasse R.H. Nielsen]

The only place where you *need* to write "dynamic" is in partally dynamic type parameters, e.g., Map<String, dynamic>.

In all other places it can be omitted, and in most places (variable or parameter declarations, but not return types) be replaced by "var".

How about just allowing "?" in type parameters, basically as a shorthand for "dynamic": Map<String, ?>.

Parsing wise, I *think* it's fairly safe. It must come just after either "<" or ",", where "?" isn't currently allowed.

/L

Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Lasse R.H. Nielsen]

My personal wish-list for syntax improvements:

- Make "new" optional.

- Make "const" be an expression modifier, not a constructor call modifier, and inside the expression, all map and list literals are automatically const, and all constructor calls are also const invocations ("new" is not allowed, extra const prefixes are ok if you want them, so this is backwards compatible).

- Introduce null-guard, e.g.  x ?? y  meaning  (tmp=x) != null ? tmp : y

- Maybe introduce null-guarded operations:  x.?foo(y)   is null if x is null (but does evaluate y).

- Enums (enum { X,Y,Z} just expands to integer constants and enum Foo {X,Y,Z} to an enum class with constants Foo.X,...)

- Allow '=' for the default values of named parameters. It's foo([x = 4]) but foo({x : 4}. I keep having to fix that. Looking like map syntax isn't clever.

- Introduce strict type annotations: Foo! foo(Foo x) => x ?? new Foo(42);  This is like the type annotation "Foo", except that it doesn't accept "null" as well. (Yes, Null! would accept null :)

And something that can't be done by just a preprocessor:

- Type parameters on functions/generic functions.

- Allow both optional positional and named parameters on the same function.

/L

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Rich E]

On Wed, Jan 29, 2014 at 10:25 PM, Enrique Gavidia <obli...@gmail.com> wrote:

I'm not sure about the other suggestions, but I definitely agree with the postfix instead of prefix type annotations. It just makes actually *reading* code flow a lot smoother -- all your variables and methods line up nicely against the left margin, making it easy to spot what you're looking for with a single smooth vertical eye motion.

Coming from a C++ background, I disagree on this one and prefer dart's current type annotation syntax. For me, the most important information I need to know when analyzing code is the types, not the user provided name.  I do however try to make the variable names easier to read by tabbing them out with a decent amount of space.

[Enrique Gavidia]

On Wed, Jan 29, 2014 at 11:26 PM, Rich E <reaki...@gmail.com> wrote:

Coming from a C++ background, I disagree on this one and prefer dart's current type annotation syntax. For me, the most important information I need to know when analyzing code is the types, not the user provided name.  

 
That's interesting. Though, I guess it is something that would vary from codebase to codebase. But usually when I dive in to read other people's code (especially in dynamic languages), I spend a lot of time visually scanning back and forth for the definitions of things by name. Type annotations are repeated too often to be useful for quick visual scanning IMO. And while I might guess what type a function returns by its context, there's always cases like implicit .toString() calls that might make it unclear, and in that case, having a dozen functions start off with 'String' over and over again doesn't exactly help with scanning efficiency. Besides, if variables/methods are named well, you can probably quickly inference the type in your head without having to actually read the explicit type annotation anyway

I guess going by types might be more useful in static languages where you're basically forced to create types in to get around certain limitations (e.g. maps/lists/tuples), but Dart is still very much dynamic, so it would ultimately be up to the community to see how much liberty is taken with the type annotation usage. Though, let's also not forget that Dart is also currently targeting a platform where some people deliberately go to great lengths to avoid semicolon usage just because it's 'ugly'...

Either way, the whole thing is kind of a moot point, since it's unlikely they'll make such a big confusing change to the syntax now anyway...

[Gen]

I prefer tools with a good UI instead of reading other people's code.

With regard to postfix typing, I would prefer that:

funName : returnType (para1 : type, para2 : type) 

Anyway, I would use prefix types and avoid the "var" and " : " tokens.

[Marcello Dias]

I think DART does not have to try to appeal to Group A or Group B,Syntax should be as Clear and short as possible,I myself think that if someone has to program in two languages profissionally  ,the more different they´re ,the better it is.

2014-01-30 Gen <gp78...@gmail.com>:

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Marcello Dias

Gerentede T.I

Rua Olimpiadas, 194 - 2º/8º/9º/13º Andares
Vila Olímpia - São Paulo / SP - Brasil
Cep: 04551-000
Tel.: + 55 11 3028-9800
Fax: + 55 11 3028-9842
marcelo@brasfond.com.br
www.brasfond.com.br

[Gen]

I agree.

But:

1)

It would be nice to have "final" and "const" baked into the (object or variable) type:

- to avoid exceptions in case of object modification.

- to enable implicit concurrency.

2)

I do not understand your enum proposal.

[George Moschovitis]

2. 'let' not 'final' for immutable locals

I would love this, I guess it's to late now :(

4. type annotation syntax either:
    a) test(int a) -> int { // code }
    b) test(a:int):int { // code }

Too late for that.

 

5. shorthand syntax for POD's
    class Point(int x, int y);

I would love to see this.

[George Moschovitis]

- Make "new" optional.

- Make "const" be an expression modifier, not a constructor call modifier, and inside the expression, all map and list literals are automatically const, and all constructor calls are also const invocations ("new" is not allowed, extra const prefixes are ok if you want them, so this is backwards compatible). 

- Introduce null-guard, e.g.  x ?? y  meaning  (tmp=x) != null ? tmp : y

- Maybe introduce null-guarded operations:  x.?foo(y)   is null if x is null (but does evaluate y).

- Enums (enum { X,Y,Z} just expands to integer constants and enum Foo {X,Y,Z} to an enum class with constants Foo.X,...)

- Allow '=' for the default values of named parameters. It's foo([x = 4]) but foo({x : 4}. I keep having to fix that. Looking like map syntax isn't clever.

- Introduce strict type annotations: Foo! foo(Foo x) => x ?? new Foo(42);  This is like the type annotation "Foo", except that it doesn't accept "null" as well. (Yes, Null! would accept null :)

And something that can't be done by just a preprocessor:

- Type parameters on functions/generic functions.

- Allow both optional positional and named parameters on the same function.

+1 on all suggestions.

[Paul Brauner]

On Thu, Jan 30, 2014 at 11:15 AM, George Moschovitis <george.mo...@gmail.com> wrote:

2. 'let' not 'final' for immutable locals

I would love this, I guess it's to late now :(

To me the main problem with final is not that it is longer than let. It's that if you want a variable to be both final and type-annotated you pay a penalty. This leads people to omit type annotations or to give up on using final. In other words, I'd like final to be the default, and "var" or "mutable" to be the extra keyword. But I don't think this will ever change.

 

4. type annotation syntax either:
    a) test(int a) -> int { // code }
    b) test(a:int):int { // code }

Too late for that.

 

5. shorthand syntax for POD's
    class Point(int x, int y);

I would love to see this.

--

[Gen]

If "let" is used as keyword than I prefer it for variables with only a public getter but a private setter.

For now, I had no use for "final".

I think that "final" and "const" are short enough.

Although it would be nice to have a way to affect all members of a class or object at once as proposed above.

[Gen]

As already discussed elswhere, I would like to have "static" optional in "static const" for class members.

class C {

 const v = ...;

}

instead of:

class C {

 static const v = ...;

}

[Matthew Butler]

While Dart 2.0 may have breaking changes, I certainly hope it is never to this extreme. To in one pass make all internal core libraries, and all existing projects completely unusable would be devastating and require a complete rewrite of not just the Editor, Compiler, and VM but the entire core library. 

That said, Dart has been accepted into the standardization body ECMA TC52 [1]. you will need to petition that working body for such language changes not Google. They have already stated that further language changes and enhancements will be deferred to that body rather than tackled at this point.

Many of your proposed changes do not enhance the language any yourself nor provide significant benefits in terms of productivity or performance of the tools and really cannot be justified beyond 'your personal preference', which of course we're all entitled to have. However for myself, those changes make the language less familiar to me, and one of the stated goals of Dart was to be familiar. (let for instance is a block-scope variable in Javascript, not a final variable, in C# it's kind of final, but for query expressions only.) Making keywords optional can lead to a whole other mess when it comes to projects with multiple contributors (this project wants to enforce the new keyword for consistency or this one doesn't want it in there etc). Which should be used on the internal libraries, or the officially 'supported/promoted' way by Dart? 

My personal preference? Leave it as it is. Dart has reached 1.0 status and while I hope for new features coming down the pipes, I hope that for 2.0 there won't be a all-encompassing breaking change that affects almost every other line of code.

[1]: http://www.ecma-international.org/memento/TC52.htm 

Matt

[cc "maco" young]

concur

--

[Günter Zöchbauer]

I'm glad that I don't have to expect radical changes to Dart anymore.

I would rather hate that pascal style variable declaration (name: type;) 

But I have to admit that I find those proposals quite interesting as it shows what people with a different background (languages and tools I will probably never have the time to learn them) found convenient.

And sometimes very interesting discussions about Dart emerge that reveal details about Dart I would not have learned otherwise.

What I find interesting is, that type annotations are optional but I have the impression that they are used

more and more also for local/private variables. 

I think this is 

- because it just helps to find many bugs.

- it improves the Editor experience with better autocompletion

If I have to find a bug in someone else's code, the first thing I do is adding type annotations

until DartEditor/Analyzer tells me where the bug is :-)

So my proposal:

Allow a configuration setting that enforces type annotations everywhere where 

the type can't be inferred or is set to dynamic explicitly.

This wouldn't even need any language change. It's just about tooling support.

[Marcello Dias]

agreed 110% with 

Matthew Butler

2014-01-30 Günter Zöchbauer <gzo...@gmail.com>:

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Marcello Dias

Gerente de T.I

[George Moschovitis]

My personal preference? Leave it as it is. 

I don't think that anyone really expects that such aggressive changes will be incorporated at this point in Dart's evolution. ;-)

-g. 

[kc]

OK - I don't think any of these will happen ... but I want to express this:

A lot of these suggestion are related to Dart's type annotation story.

From the 'Type Annotation' secton in the 'Dart Style Guide':

PREFER providing type annotations on public APIs.#
PREFER using var without a type annotation for local variables.#
AVOID annotating with dynamic when not required.

This is what I'm looking for. Basically a great set of publicly available libs with type annotations. Gives me code completion and type inference in my apps. My non-public app code wil be pretty much be type annotation free.

But for public API's in published libs maybe explicitly typing with 'Any' aka 'dynamic' is a better way to go. (dynamic is from c# but c# was trying to lighten itself coming from a static heavy direction via the .net vm. Whereas Dart is coming from the opposite direction of a Smalltalk inspired OO dynamic runtime).

But currently developers are saying 'I would like to use type inference - but feel it's safer to type annotate everything'.
And if the local is immutable then:
final Point p = new Point(1,1); // yuk

If developers go-to-town with types then imo the dynamic OO story of Dart becomes too brittle and ceases to work.

But with a rejigged type annotation syntax it should be much easy to express union types (for types that don't have a common ancestor) which should lessen the usage of 'Any' aka 'dynamic' on public API's:
test(cat|frog creature)-> cat|dinosaur { // code };
test(creature: cat|frog): cat|dinosaur { // code };

And ideally the static type annotation part of the language spec should be removed to a separate document/spec so the type inference story can evolve separately via developer experience. With the ability of dial up and dial down the static type experience. As opposed to a strait jacket which encourages developers to type annotate everything rather than just public api's. And the place to offer this developer friendly experience is ... Spark.

K.

[kc]

On Thursday, January 30, 2014 2:25:12 PM UTC, Matthew Butler wrote:

That said, Dart has been accepted into the standardization body ECMA TC52 [1]. you will need to petition that working body for such language changes not Google. They have already stated that further language changes and enhancements will be deferred to that body rather than tackled at this point.

Many of your proposed changes do not enhance the language any yourself nor provide significant benefits in terms of productivity or performance of the tools and really cannot be justified beyond 'your personal preference', which of course we're all entitled to have. However for myself, those changes make the language less familiar to me, and one of the stated goals of Dart was to be familiar. (let for instance is a block-scope variable in Javascript, not a final variable, in C# it's kind of final, but for query expressions only.)

OK - sorry guys. I just have to accept the even though I think the core Dart idea was great - simple semantics yields a simpler, faster VM combined with a nice surface syntax - it's not hitting the sweet spot for me.  (Thought if the VM gets into Chrome and offers stellar performance then dev's will be interested regardless of the syntax).

Re 'let'. Gilad - I think - considered 'let' for immutable bindings because of let's functional/immutable heritage. Whereas ES6 needed a replacement for it's hoisted 'var'.

From a recent Angular JS presentation - ES 6 & Contracts - at 31:09:
http://www.parleys.com/play/529c4440e4b0e619540cc3b9

This looks like a flexible pluggable type system. Dart is currently the Windows 8 of static and dynamic types - confusing. And some developers are saying 'Give me the desktop/static types. Where's my Start Button/new'. No Metro/dynamic for me.'

K.

[David Kopec]

I think some of these are nice ideas (well neutral ideas because they depend on your prior language background how you view them), but it's a bit late in the game.

It's clear that most syntax decisions were made to ensure an easy transition for Java/JavaScript developers.  I'm not sure it would be a good idea to undermine that strategy while the language is still growing.

[Gen]

Dart is intended as independent language that shares basic syntax with the C/C++ family of languages.

Keeping Dart in bondage because of Java or Javascript would be a very bad strategy and kill it soon; for technical and marketing reasons.

If Dart should be successful then it must stand on its own feet with self confidence on the same level of its competitors (Java, Javascript).

  

Growing a language makes it more complicated, e.g. C++.

But I am certain that no syntax or feature is added that would not be used frequently.

I guess, Gilad and the Dart team does not like features just for special cases or to enable directly different programming styles.

[Anders Holmgren]

Yeah I think any changes should provide major value rather than be a synonym for something existing.

My biggest grouch is that omitting the type annotations on locals makes them dynamic rather than inferred. I would have much preferred being forced to have to use the dynamic keyword explicitly.

As it stands now you can completely stuff up your code and won't see it till you run a unit test. That's why most of my locals have type annotations now and as someone pointed out my code bloats cos I also add final to them.

Would love to see warnings in the editor and linter on these. If dart aims to improve code quality to that of js then IMO this is a must have

My 2c

[Günter Zöchbauer]

exactly my experience

[Gen]

1)

I am quite certain that "dynamic" as default is strongly intended.

AFAIK, Gilad is no friend of types and type inference.

It would be great to have more capable editor (tools) that might replace "var" by "final InferedType" for example.

But we have not even automatic code formatting or code completion when using "part of".

So do not hold your breath for any editor or tool progress.

 

2)

It think that the propositions in this discussion are very reasonable.

Avoid enum because you can implement them already now ?

Not having POD with implicit constructors ? 

Not having "final class/exp" or "const class/exp" oder even "static class" ?

Not having a short way to deal with null ?

Growing a language is risky.

But keeping a language dead and frozen is almost certainly the wrong choice.

By "special case" I meant for instance something that works for XML but not for JSON.

[Anders Holmgren]

Totally agree we enums and deeply immutable objects. But let vs final etc is not worth it IMO nor is dropping new. Just too small a gain for me

[Quildreen Motta]

Shorter syntax is not necessarily better (unless you're using a text editor). As Smalltalkers, I believe that the Dart team would be more concerned in providing good tooling to work with the language at a higher level, and leave the language as just the basis for simple and expressive semantics, than supporting special cases for Group A or B — to which I entirely agree with as a PL designer. And it is sooo much better if you can express any sort of construct you want in the language itself, because then you don't need to wait years for the designers to come up with that functionality!

So, I believe that instead of syntax, you could motivate things with use cases and functionality/semantics. I don't particularly think that Dart's syntax is too verbose (and this from someone who's mainly into extremely concise languages, like Haskell). Sure modifiers are sort of verbose, but they're orthogonal, so I don't really mind them much.

The only thing I'd get rid of in Dart would be static annotations, since I don't believe static members fit the OO philosophy. Dart has first-class functions and libraries, which already solve all the problems static members would. (I would also drop "null" entirely, but I don't think the Dart team would agree with me on this one).

On 31 January 2014 06:11, Anders Holmgren <andersm...@gmail.com> wrote:

Totally agree we enums and deeply immutable objects. But let vs final etc is not worth it IMO nor is dropping new. Just too small a gain for me

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

--
Quildreen "(Soreλ\a)" Motta  (http://robotlolita.github.io/)
— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —

[Gen]

<< leave the language as just the basis for simple and expressive semantics, than supporting special cases for Group A or B 

What do you mean by support ? Macros ?

For source code related features, I prefer having a standard instead of countless do-it-yourself variants.

And macros can evolve into DSL languages which means additional effort to maintain and to learn as employee.

On the other hand, I would welcome if Dart (and libraries) would become a simple target platform for compiled and interpreted languages.

Short, flexible and efficient but not cryptic syntax matters much to me.

Dart is quite good so far. Much better than Javascript.

Classes serve as namespaces or modules as well.

So "static" has some use cases except for "static const name  = ...".

[Bob Nystrom]

On Thu, Jan 30, 2014 at 7:41 PM, Anders Holmgren <andersm...@gmail.com> wrote:

My biggest grouch is that omitting the type annotations on locals makes them dynamic rather than inferred. I would have much preferred being forced to have to use the dynamic keyword explicitly.

That depends on what you mean by "inferred" here. My understanding is that the analyzer will use inferred for both autocomplete and "hints" when you use var. You should be able to get some kind of output from the analyzer if it can determine by inference that you're doing something non-type-safe.

Is that not what you're experiencing?

- bob

[Quildreen Motta]

On 31 January 2014 15:30, Gen <gp78...@gmail.com> wrote:

<< leave the language as just the basis for simple and expressive semantics, than supporting special cases for Group A or B 

What do you mean by support ? Macros ?

In this case, "support" means special constructs baked in right into the language for really specific use cases/groups of people.

 

For source code related features, I prefer having a standard instead of countless do-it-yourself variants. 

And macros can evolve into DSL languages which means additional effort to maintain and to learn as employee.

From my experience (and from the academic papers I read), it is actually the opposite. DSLs (specially DSELs) are easier to maintain, and easier to learn for employees. Specially if you have different groups of people working on different features. Libraries tend to be a special case of DSELs, for example.

 

On the other hand, I would welcome if Dart (and libraries) would become a simple target platform for compiled and interpreted languages.

Compiling to high-level languages is really difficult (to optimise) if the semantics aren't closely related. I'm currently working in a compile-to-JS PL with semantics close to Haskell, and optimising it is right now only possible due to the static type system. So Dart as a compile target would be fairly limited in terms of which languages you can efficiently compile down to it.

 

Short, flexible and efficient but not cryptic syntax matters much to me.

Dart is quite good so far. Much better than Javascript.

I dislike the classical formulation of OO, so in this regards I would prefer the prototypical formulation of OO (even though JavaScript's implementation is really limited, if you compare it to Io, Slate or Self). But in all other aspects, Dart is a huge improvement over JavaScript, indeed.

 

Classes serve as namespaces or modules as well.

So "static" has some use cases except for "static const name  = ...".

Yeah, I'm saying that classes shouldn't double as namespaces. To me, classes should only define what objects are to become, and objects should be only a bag of dynamically dispatched behaviour. There are better constructs for modelling other features, Dart's libraries already cover the namespacing problem (although last time I looked at it, the import didn't have a way of refining the names to be included in the namespace, such as Clojure has).

 

[Bob Nystrom]

On Fri, Jan 31, 2014 at 12:22 PM, Quildreen Motta <quil...@gmail.com> wrote:

although last time I looked at it, the import didn't have a way of refining the names to be included in the namespace, such as Clojure has

You can exclude identifiers in an import using "show". If you want to exclude all but a whitelist of names, you can use "hide". I don't think you can rename an individual identifier.

Cheers!

- bob

[Quildreen Motta]

That's neat!  👍

[Anders Holmgren]

Take a simple example

class Person {

  int age;

  String name;

}

void foo() {

  var p = new Person();

  p = 6;

}

void fum() {

  Person p = new Person();

  p = 6;  

}

In fum the editor gives me a visual cue that I stuffed it up, but in foo I get nothing.

For me it would be extremely rare that I would have actually wanted to have p be dynamic. So for those rare (for me) cases I would prefer to have to do 

  dynamic p = new Person();

One that I kept tripping over a lot was using Option. e.g.

Option<Person> fooPerson() {  }

void fumPerson(Person p) {}

void blah() {

  final p = fooPerson();

  fumPerson(p); // no warning!!!!!

  fumPerson(fooPerson); // do get warning

}  

Until the editor gives me a visual indication of these sorts of cases I'll have to keep putting types on even though it bloats things annoyingly

A

[Anders Holmgren]

 

I don't think you can rename an individual identifier.

but as you can do

import 'package:foo/bar.dart' as fred show Bar;

you have sort of renamed Bar as fred.Bar which is good enough for me 

[Quildreen Motta]

For me it would be extremely rare that I would have actually wanted to have p be dynamic. So for those rare (for me) cases I would prefer to have to do 

If I get correctly what Bracha et al want with optional types, type inference would be entirely optional as well, and delegated to a tool, rather than baked right into the language. So every time you type `var foo = new Person()`, your IDE (or something) see that as `Person foo = new Person()`.

[Anders Holmgren]

That would totally work for me. I don't need it baked it as long as I get the feedback straight away. The sooner you catch something the less time it costs you. Waiting until you run something (e.g. a unit test) is a productivity drain as far as I'm concerned

[Günter Zöchbauer]

This is exactly my experience.
Code completion doesn't work properly either with var.
I don't use var at all except when I want dynamic (in very rare cases).

[Greg Lowe]

My biggest grouch is that omitting the type annotations on locals makes them dynamic rather than inferred. I would have much preferred being forced to have to use the dynamic keyword explicitly.

Mine too. I raised a ticket about this a while back. Except my example in the ticket is a bit crap. Perhaps you'd like to add your example to the ticket.

http://code.google.com/p/dart/issues/detail?id=9401

[Greg Lowe]

Hmmm actually that ticket is a bit dated now - I think the "--type-checks-for-inferred-types" feature used to do this, but was removed from the analyser.

[kc]

Another Anders comments:

Microsoft PDC 2008 - "The Future of Programming Languages" panel
https://channel9.msdn.com/Blogs/pdc2008/TL57

Anders Hejlsberg (seated next to Gilad Bracha) at 1:14:48:

"type inference for local variables, I am convinced that it is valuable ... C and  C++ and Java and C# previously, they just force you to state the type too much. What is the point of saying ... Dictionary of String, Object mydictionary = new Dictionary of String, Object ... didn't you just say that <audience laughter> so why not just say it once. There are so many cases where it's just bloody obvious from the context what the type is and you just don't care."

[kc]

On Friday, January 31, 2014 3:41:00 AM UTC, Anders Holmgren wrote:

Yeah I think any changes should provide major value rather than be a synonym for something existing.

The following is in no way a suggestion of any kind ;) , (I always considered the real version 1.0 of Dart to be when the native Dart VM goes into Chrome - which was and error on my part).

Right. Re 'let' or 'val' for immutable bindings vs 'final'. See:

https://groups.google.com/a/dartlang.org/forum/#!searchin/misc/final/misc/Nhk-w9RCIhQ/cHETGKaGPE0J

Gilad actually suggested 'val' from Scala (not 'let' as I originally thought). I think that the semantics of 'final'  are too overloaded and associated with class inheritance rather than local immutability.  And given that some dev's prefer immutability on locals the ergonomic/eyeballing and finger tip costs shouldn't be greater than mutable locals.

So 'let' or 'val' are a bit more than synonyms. My suggestions weren't really just whims or opinions - rather an attempt to reflect the core semantics of Dart more cleanly to get a broader audience than just Java or C# developers. Especially people coming from scripting languages or learning programming for the first time. A market Dart could use.

And the thing that should really be clearly reflected by the syntax is the optional/pluggable type annotation concept. Type annotations are just type annotations. For development time tools/analysis. Not used by the production Dart VM.

But, fundamentally, the 'C' heritage type annotation syntax does not play well with this optional/pluggable concept and the core Smalltalk-ish Dart runtime/semantics. 'C' style types always look like something more than just annotations and encourage the drift by developers to type annotate on locals. And as the Angular presenter said when discussing type annotations: Static types spread like cancer.

That's my 2 cents.

K.

[Anders Holmgren]

If val (or let) is semantically identical to final then IMO it's too late for that. Sure I may have preferred val to final but I wouldn't want to see both supported as I feel it just adds noise.

On the other hand if val was defined as final with inferred type, now that might be something. i.e.

final int foo = 6;

val foo = 6; // final and inferred as int (not dynamic)

but if the tools are going to improve and give the sorts of 'tips' that I am hoping for then I can certainly live with doing

final foo = 6;

even though I could save 2 chars, if that's all it gave me then I don't think it's worth it.

I liked the idea that final would be the default. Pity that didn't happen.

It's no easy task coming up with a language that appeals to people from Java/C# and JS etc. Some features will inevitably please one camp and annoy the other. Defaulting to dynamic is likely one of those.

Interestingly I see parallels between C++ vs Java and Dart vs Scala. C++ was much more eager to adopt new features where as Java was much more conservative. Scala reminds me of C++ in that way and Dart of Java. I saw the other day that thoughtworks rated scala as "adopt - the good bits". That says a lot. 

For mass appeal I think the conservative approach is often best even though many of us will lament missing features. I reckon it served Java well at least in the early days, although now has become a liability as it feels like a very blunt tool compared to the likes of Dart.

A

[Mehmet D. Akın]

Very nice list of improvements.

I started to think having a really opinionated default dartfmt and dropping most of the  ;  {} and () noise would be nice as well. But I guess it is too late for that. Ah also nicer looking for loops :)

M.

On Thursday, January 30, 2014 8:22:04 AM UTC+1, Lasse Reichstein Holst Nielsen wrote:

My personal wish-list for syntax improvements:

- Make "new" optional.

- Make "const" be an expression modifier, not a constructor call modifier, and inside the expression, all map and list literals are automatically const, and all constructor calls are also const invocations ("new" is not allowed, extra const prefixes are ok if you want them, so this is backwards compatible).

- Introduce null-guard, e.g.  x ?? y  meaning  (tmp=x) != null ? tmp : y

- Maybe introduce null-guarded operations:  x.?foo(y)   is null if x is null (but does evaluate y).

- Enums (enum { X,Y,Z} just expands to integer constants and enum Foo {X,Y,Z} to an enum class with constants Foo.X,...)

- Allow '=' for the default values of named parameters. It's foo([x = 4]) but foo({x : 4}. I keep having to fix that. Looking like map syntax isn't clever.

- Introduce strict type annotations: Foo! foo(Foo x) => x ?? new Foo(42);  This is like the type annotation "Foo", except that it doesn't accept "null" as well. (Yes, Null! would accept null :)

And something that can't be done by just a preprocessor:

- Type parameters on functions/generic functions.

- Allow both optional positional and named parameters on the same function.

/L

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[kc]

In a recent presentation on Dart (http://www.infoq.com/presentations/dart-motivation-future), the section 'Optional Types' beginning at 23:25 has an accompanying slide displaying:

"Checked Mode ... Creates a language that *does* require types :-("

Thus, examples from the dartlang site often contain explicit type annotations which could easily be inferred e.g. from the subsection 'Concise' with the byline: 'Write less. Say more.':

List shapes = [];                     // Use literals to create lists.

But developers may respond:

https://twitter.com/rich_4711/status/428092733236842497

Especially those with a scripting/functional/type inference language background. The Java-ish boilerplate will turn them off - which is a shame.

(n.b. C style type annotation syntax and type inference ambiguity re 'var' possibly contribute to excessive type annotation as well as checked mode).

K.

[Peter Ahé]

On Feb 9, 2014 8:48 AM, "kc" <kevin...@gmail.com> wrote:
>
> In a recent presentation on Dart (http://www.infoq.com/presentations/dart-motivation-future), the section 'Optional Types' beginning at 23:25 has an accompanying slide displaying:
>
> "Checked Mode ... Creates a language that *does* require types :-("
>

I don't think that is correct, and I'll discuss it in person with Gilad and report back.

The gist of my objection to that statement is that types aren't required, but when you use them, they must match.

This creates problems for proxy classes which is why I have always argued that the is operator should be user definable.

> Thus, examples from the dartlang site often contain explicit type annotations which could easily be inferred e.g. from the subsection 'Concise' with the byline: 'Write less. Say more.':
>
> List shapes = [];                     // Use literals to create lists.
>

I think you miss the point of this example: by including the type, the example documents what the type of the literal is.

Cheers,
Peter

> But developers may respond:
>
> https://twitter.com/rich_4711/status/428092733236842497
>
> Especially those with a scripting/functional/type inference language background. The Java-ish boilerplate will turn them off - which is a shame.
>
> (n.b. C style type annotation syntax and type inference ambiguity re 'var' possibly contribute to excessive type annotation as well as checked mode).
>
> K.
>
>
> On Thursday, January 30, 2014 3:40:47 PM UTC, kc wrote:
>>
>> OK - I don't think any of these will happen ... but I want to express this:
>>
>> A lot of these suggestion are related to Dart's type annotation story.
>>
>> From the 'Type Annotation' secton in the 'Dart Style Guide':
>>
>> PREFER providing type annotations on public APIs.#
>> PREFER using var without a type annotation for local variables.#
>> AVOID annotating with dynamic when not required.
>>
>> This is what I'm looking for. Basically a great set of publicly available libs with type annotations. Gives me code completion and type inference in my apps. My non-public app code wil be pretty much be type annotation free.
>>
>> But for public API's in published libs maybe explicitly typing with 'Any' aka 'dynamic' is a better way to go. (dynamic is from c# but c# was trying to lighten itself coming from a static heavy direction via the .net vm. Whereas Dart is coming from the opposite direction of a Smalltalk inspired OO dynamic runtime).
>>
>> But currently developers are saying 'I would like to use type inference - but feel it's safer to type annotate everything'.
>> And if the local is immutable then:
>> final Point p = new Point(1,1); // yuk
>>
>> If developers go-to-town with types then imo the dynamic OO story of Dart becomes too brittle and ceases to work.
>>
>> But with a rejigged type annotation syntax it should be much easy to express union types (for types that don't have a common ancestor) which should lessen the usage of 'Any' aka 'dynamic' on public API's:
>> test(cat|frog creature)-> cat|dinosaur { // code };
>> test(creature: cat|frog): cat|dinosaur { // code };
>>
>> And ideally the static type annotation part of the language spec should be removed to a separate document/spec so the type inference story can evolve separately via developer experience. With the ability of dial up and dial down the static type experience. As opposed to a strait jacket which encourages developers to type annotate everything rather than just public api's. And the place to offer this developer friendly experience is ... Spark.
>>
>> K.
>

[kc]

On Sunday, February 9, 2014 7:47:17 PM UTC, Peter von der Ahé wrote:

> Thus, examples from the dartlang site often contain explicit type annotations which could easily be inferred e.g. from the subsection 'Concise' with the byline: 'Write less. Say more.':
>
> List shapes = [];                     // Use literals to create lists.
>

I think you miss the point of this example: by including the type, the example documents what the type of the literal is.

For that particular example maybe. It just happened to be in the 'Concise' section.

But from the example in the 'Testing' section:

 Point a = new Point(2, 15);  
 Point b = new Point(7, 3);

 'Write less. Say more.' does not apply. The type annotations are redundant. And the presentation seemed to indicate that 'new' violates the principle of uniform access and is also redundant.

Type annotations on locals in the examples do not seem to be following the Style Guide.

K.

[Peter Ahé]

Good point. I've been annoyed by javaisms like that as well.

You could file a bug or send them a patch :-)

Cheers,
Peter

--

[kc]

On Monday, February 10, 2014 5:23:40 AM UTC, Peter von der Ahé wrote:

Good point. I've been annoyed by javaisms like that as well.

You could file a bug or send them a patch :-)

The darlang site's front page examples all seem to explicitly type annotate on locals. 'var' is not used.

My question is why? Why was the style guide not followed - especially given that the examples were written by a Dart team member.

I think the reason is a combination of Checked Mode, 'C' style type annotations, ambiguity re type inference and 'var' and static type analysis which is baked into the language spec.

Type inference issues were discussed here - but were they resolved:
https://groups.google.com/a/dartlang.org/d/topic/misc/GEsj0qyEa-4/discussion

Basically, imo these issues are more fundamental than a bug/patch. Dart doesn't have an optional type system. It has a binary type system - all or nothing. And all means annotate on locals. The static type system is wagging the dynamic runtime dog.

K.


 

[Bob Nystrom]

On Mon, Feb 10, 2014 at 6:15 AM, kc <kevin...@gmail.com> wrote:

The darlang site's front page examples all seem to explicitly type annotate on locals. 'var' is not used.

My question is why? Why was the style guide not followed - especially given that the examples were written by a Dart team member.

There is no why here. It's a bug in the examples. They shouldn't be using type annotations for locals. Can you file a ticket so we don't forget to fix this please? Thanks!

Cheers,

[Alex Tatumizer]

"var" meaning "dynamic" also breaks the principle of uniformity: if it's fully synonymous with "dynamic", why another name? If it's not synonymous, what's the difference? If could mean "inferred", but the notion of inferred type was not developed into consistent concept, as examples in the discussion thread indicate.

Maybe in this case, like with "new", "familiarity" comes into play somehow? Too many rabbits to chase...

[Anders Holmgren]

I finally realised why I felt the need to revert to putting types on locals when others on this list don't. It comes down to the programming style I've evolved to with dart.

In short I use the cool iterable methods like map, fold, where etc a lot. Partly that may be me taking out my frustrations of javas lack of lambda support out on dart, but mostly because I really like programming that way.

Unfortunately, due to the lack of generic types on methods (https://code.google.com/p/dart/issues/detail?id=254) the map method (and fold, expand etc) is defined as

Iterable map(f(E element));

i.e. you jump from a typed iterable to a dynamic one so at this point you may as well be coding javascript cause the editor is not going to help you. e.g

    final il = new List<int>();

    final il2 = il.where((i) => i > 2);

    final sl = il.map((f) => '$f');

    il.first.abc; // nice hint here - thanks dart editor team

    il2.first.abc; // nice hint here - thanks dart editor team

    sl.first.abc; // :-( nada here

Since only 102 people have starred https://code.google.com/p/dart/issues/detail?id=254 I'm guessing most people don't use map much or haven't realised how that issue completely destroys all the awesome work the editor team has done with hints if you use it.

A

[Bob Nystrom]

On Mon, Feb 10, 2014 at 11:58 AM, Anders Holmgren <andersm...@gmail.com> wrote:

In short I use the cool iterable methods like map, fold, where etc a lot. Partly that may be me taking out my frustrations of javas lack of lambda support out on dart, but mostly because I really like programming that way.

Unfortunately, due to the lack of generic types on methods (https://code.google.com/p/dart/issues/detail?id=254) the map method (and fold, expand etc) is defined as

Iterable map(f(E element));

i.e. you jump from a typed iterable to a dynamic one so at this point you may as well be coding javascript cause the editor is not going to help you. e.g

Ah, this is a great point. Idiomatic Dart code does use a bunch of transformers on sequences (and streams and futures) and those indeed throw a lot of auto-complete out the window right now. :(

 

Since only 102 people have starred https://code.google.com/p/dart/issues/detail?id=254 I'm guessing most people don't use map much or haven't realised how that issue completely destroys all the awesome work the editor team has done with hints if you use it.

102 stars is actually quite a bit. That's the fifth-most starred open issue on the tracker.

Cheers!

- bob

[Anders Holmgren]

Well it's 105 now so we're making progress ;-)

Just tripped over another interesting one copying code out of the polymer elements grid layout example (grid_test.dart). There is actually a bug in there but you wouldn't know it from looking at the code in the editor.

If you look at the following it should really be List<List<List<int>>> but as dart list literals [] make the list dynamic it passes through undetected. Mind you I think the editor should warn here as the field is declared with types

List<List<int>> _arrangements = 

    [[

      [1, 1, 1],

      [2, 3, 4],

      [2, 3, 5]

    ], [

      [4, 3, 2],

      [5, 3, 2],

      [5, 1, 1]

    ], [

      [1, 1],

      [2, 3],

      [4, 3]

    ]];

[Greg Lowe]

Idiomatic Dart code does use a bunch of transformers on sequences (and streams and futures) and those indeed throw a lot of auto-complete out the window right now. :(

At least for the built in libraries the generic method signatures could be hard coded within the analyzer, allowing it to infer types correctly. An ugly solution - but it would improve the editing experience a lot.

--

[Greg Lowe]

Just tripped over another interesting one

It would be interesting to collect a list of examples where Dart type checking and/or analyzer inference allows errors to slip through. 

Also - I'm really happy about the recently added hint for missing return statements. 

https://code.google.com/p/dart/issues/detail?id=13373

It's good to see that the static analysis is continuing to improve.

--

[Anders Holmgren]

+1 I think until these issues are fixed the style guide is more of a vision for how we'd like to be coding rather than something that is practical to follow today.

In fact it makes some aspects of idiomatic dart at odds w the style guide IMO

And +1 for the missing return fix. That's a biggie for me so greatly appreciated.

[David Kopec]

Some us will have to just agree to disagree on some of these style issues.  Personally, I find local type annotations make code more readable for me, as I am accustomed to read things from left to right.

[Bob Nystrom]

On Mon, Feb 10, 2014 at 3:08 PM, Anders Holmgren <andersm...@gmail.com> wrote:

+1 I think until these issues are fixed the style guide is more of a vision for how we'd like to be coding rather than something that is practical to follow today.

If we don't write code the way we want to, the tools will never grow to accommodate that style. Why would the analyzer folks spend the time to implement any type inference if everyone was fully annotating everything?

It's the job of tooling to make your life easier. It's not your job to make the tool's life easier. That does mean that there are times where there's lag between your ideal style and what the tool supports most gracefully, but I think if you are patient during that lag, in return you get tooling that does more work for you.

 

In fact it makes some aspects of idiomatic dart at odds w the style guide IMO

Given that I wrote both of those documents, I hope that isn't the case!

- bob

[Bob Nystrom]

On Mon, Feb 10, 2014 at 10:23 PM, David Kopec <snpu...@gmail.com> wrote:

Some us will have to just agree to disagree on some of these style issues.  Personally, I find local type annotations make code more readable for me, as I am accustomed to read things from left to right.

There's no real disagreement here. The style guide allows this. That's why it says "PREFER" and not "DO". Though, for what it's worth, the general trend in the entire software industry is moving away from annotation local variables. See: Scala, Java's diamond operator, Kotlin, "var" in C#, auto in C++, etc.

Cheers!

- bob

[David Kopec]

Thanks for the reply, Bob.  That makes a lot of sense.  Why do you think the industry is moving away from local type annotations?  Do people really find it easier/friendlier for new programmers without them?

[Greg Lowe]

Why do you think the industry is moving away from local type annotations?

Because in most langauges (with the exception of Dart *) these are totally redundant, leading to extra typing and extra time for a programmer to read.

i.e. if equivalent, which do you prefer?

  MyBigLongClassName myBigLongClassName = new MyBigLongClassName();

or:

  var myBigLongClassName = new MyBigLongClassName();

* The analyzer in Dart doesn't always infer local type annotations yet. Which is why some people prefer to use them - they get completion and better static hints.

[Cogman]

@David

The reasons vary by language.

For example, in C++ one of the prime motivators for auto was the complex types returned by templates

This

for (std::vector<int>::const_iterator ci = v.begin(); ci != v.end(); ++ci)

turns into this

for (auto ci = v.begin(); ci  != v.end(); ++ci)

For most, explicitly typing out what ci provides no benefit, its usage implies what it is.

For the java example,

List<Bob> bobs = new ArrayList<Bob>();

turned into

List<Bob> bobs = new ArrayList<>();

The reason behind this change was to reduce the redundancy of type information (and it was any easy change, underneath java doesn't know the difference between ArrayList<Bob> and ArrayList<Tim>)

Ultimately, I think it boils down to the typing systems information being redundant or overly verbosity, but really it just depends.  The motivations are different.

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Anders Holmgren]

On Wednesday, 12 February 2014 07:13:06 UTC+11, Greg Lowe wrote:

Why do you think the industry is moving away from local type annotations?

Because in most langauges (with the exception of Dart *) these are totally redundant, leading to extra typing and extra time for a programmer to read.

+1

[David Kopec]

Like I said before, I actually prefer the former because I'm used to reading from left to right and also when quickly scanning downward through a source code file, I notice the things on the left most end first...  but I can see both sides of the equation.

[Anders Holmgren]

On Wednesday, 12 February 2014 05:49:53 UTC+11, Bob Nystrom wrote:

On Mon, Feb 10, 2014 at 3:08 PM, Anders Holmgren <andersm...@gmail.com> wrote:

+1 I think until these issues are fixed the style guide is more of a vision for how we'd like to be coding rather than something that is practical to follow today.

If we don't write code the way we want to, the tools will never grow to accommodate that style. Why would the analyzer folks spend the time to implement any type inference if everyone was fully annotating everything?

I would hope they would do it based on the issues we create and star plus feedback via channels like this

 

It's the job of tooling to make your life easier. It's not your job to make the tool's life easier. That does mean that there are times where there's lag between your ideal style and what the tool supports most gracefully, but I think if you are patient during that lag, in return you get tooling that does more work for you.

When I first came across the style guide I liked it for the most part so went about adopting it, including deleting local types. This ending up coming back to bite me big time as I found I was constantly catching silly stuff in unit tests (or worse if my coverage wasn't 100%) rather than as I typed it. I believe it also destroyed a bunch of refactoring as I went and renamed methods & fields but the editor can't know how to apply those renamings on fields / methods called where it's lost the type. 

I found this was too time wasting and alarming for my code quality so I went back to typing locals. But once the issues are fixed I'll happily drop them again (i.e. as long as they are truly redundant)

 

In fact it makes some aspects of idiomatic dart at odds w the style guide IMO

Given that I wrote both of those documents, I hope that isn't the case!

Well I like them both but I find it totally impractical to follow both until local types are truly redundant

 

- bob

[kc]

On Monday, February 10, 2014 5:10:33 PM UTC, Alex Tatumizer wrote:

"var" meaning "dynamic" also breaks the principle of uniformity: if it's fully synonymous with "dynamic", why another name? If it's not synonymous, what's the difference? If could mean "inferred", but the notion of inferred type was not developed into consistent concept, as examples in the discussion thread indicate.

Bob made a similar point in the other thread.
https://groups.google.com/a/dartlang.org/d/msg/misc/GEsj0qyEa-4/32UephpS3P0J

Maybe developers coming from C# have type inference expectations regarding 'var'. Especially given that Dart has 'dynamic' like C#.

Whereas dev's from a JS/scripting background see var as an dynamic/Any type. Which at the moment matches the language spec.

K.

 

[Gen]

I would like to have this too:
- var => Tells the tools that static type safety is required. This enables error messages and type based change of identifiers.
- dynamic or any => Declares dynamic as type.

If there is any way to change the spec, I would like to have a referendum about that change.

[Lasse R.H. Nielsen]

How about the Go syntax:

  x := expression;

which is equivalent to the variable declaration:

  <static type of expression> x = expression;

It requires static type inference, which the VM doesn't have, so it's probably not a good idea for Dart (but it could be handled by a preprocessor with type inference).

/L

On Wed, Feb 12, 2014 at 1:59 PM, Gen <gp78...@gmail.com> wrote:

I would like to have this too:

- var => Tells the tools that static type safety is required. This enables errors and type based change of identifiers.

- dynamic or any => Declares dynamic as type.

If there is any way to change the spec, I would like to have a referendum about that change.

Am Mittwoch, 12. Februar 2014 07:19:26 UTC+1 schrieb kc:

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Gen]

I am fine with your proposition.

But I do not understand your concern about the VM.
Tools are free to add whatever help and type constraints are wanted.
That the VM does not need type declarations is awesome.
I thought that a loose relationship between VM, compiler and tools was a goal for Dart.

Are you thinking about code generation at runtime without static tool checks ?
I do not know how that will turn in Dart.
My guess is that the VM uses already type information, type constraints and type checks all the time.

[Gen]

Although the difference between := and = is just a colon which is easily misread or mistyped.
This can lead to subtle problems if you trust a type based change of some identifier.
Being forced to write multiple characters to make the difference is safer.

My guess is that ES6 will continue to please the dynamic language proponents and
I think that Dart (especially with the current user culture) might be better off with static type inference as default.
=>
x = expression //Static type inference
dynamic x = expression //dynamic as static type
any x = expression //dynamic as static type
var x = expression // static type inference ?

[Lasse R.H. Nielsen]

On Wed, Feb 12, 2014 at 3:37 PM, Gen <gp78...@gmail.com> wrote:

I am fine with your proposition.

But I do not understand your concern about the VM.
Tools are free to add whatever help and type constraints are wanted.
That the VM does not need type declarations is awesome.
I thought that a loose relationship between VM, compiler and tools was a goal for Dart.

Are you thinking about code generation at runtime without static tool checks ?
I do not know how that will turn in Dart.
My guess is that the VM uses already type information, type constraints and type checks all the time.

My point was that for the syntax to act like in Go, that is

  x := 42;

being equivalent to

  int x = 42;  // type inferred as static type of left-hand-side

the runtime system would *need* the static type inference. Otherwise it would do the wrong thing on:

   x := 42;

   x = "something";

in checked mode (where it should throw a type error). Since the VM doesn't have static type inference, and we probably don't want to require it to do so, that syntax isn't going to work in practice for Dart.

Nor will any other variant of static type inference that spills over to runtime - which implicit type annotations do.

/L

-- 

[Gen]

Sorry, i still do not understand.
AFAIK:
1)
The purpose of static types is to avoid that the following can be compiled :

   x := 42;

   x = "something";
Static types mean whole program checks.
Therefore my remark about dynamic code generation.

2)
I feel ridiculous to tell you about the VM but judging from my test,
the Dart VM seems to use types and does dynamic type checks.
For example:
- The use of "as".
- When trying to call some function from a variable that has the wrong type. E.g. B x = new A();

[Lasse R.H. Nielsen]

On Wed, Feb 12, 2014 at 4:51 PM, Gen <gp78...@gmail.com> wrote:

Sorry, i still do not understand.
AFAIK:
1)
The purpose of static types is to avoid that the following can be compiled :

   x := 42;

   x = "something";
Static types mean whole program checks.
Therefore my remark about dynamic code generation.

Type annotations are used for thee things in Dart:

1. documentation.

2. static type checking.

3. dynamic type checking in checked mode.

Static type checking isn't forcing your program to be error-free, but it does help you find obvious errors. You can still have fully typed programs with no static type warnings that fail at runtime. Example:

  num foo() => 42.5;

  main() {

    int x = foo();

  }

Assignability is bivariant, so this type-checks statically, but fails dynamically in checked mode.

Static type inference and checking is done by the Analyzer and Dart2js, but not the VM.

Dynamic type checking checks the actual values at runtime. These may be subtypes of the declared types/statically inferred types.

 

2)
I feel ridiculous to tell you about the VM but judging from my test,
the Dart VM seems to use types and does dynamic type checks.
For example:
- The use of "as".
- When trying to call some function from a variable that has the wrong type. E.g. B x = new A();

Dynamic type checks, yes, but no static type checks. It does not have the algorithm for finding the static type of an expression available.

So, if Dart introduced syntax like:

  x := expr;

so that it should mean the same as 

  <static type of expr> x = expr;

then the VM would be unable to make the dynamic type check for other assignments to x. It simply doesn't know what type x should be declared as having. It can't use the actual type of "expr", because that may not be the same as its static type, causing other assignments to fail where they shouldn't.

That is why having inferred type annotations is a problem. It links the static type inference to the runtime type checks, two phases that is otherwise kept separate.

/L

[Gen]

Thanks for your explanations.
I have come to the conclusion that we have different type systems in mind.

I would expect that the following does not compile:

[Anders Holmgren]

That was my thoughts when I read that too but dart's type system is not what I (and many others from a statically typed background) are used to (see https://www.dartlang.org/articles/why-dart-types/)

Personally I would be happy with tools that provide "hints" by doing type inferencing and leave it out of the VM if that simplifies things. Anything that helps me catch most of the simple errors up front would be a big help.

People from a dynamic background would probably not want to see those hints so I suspect they need to be configurable. You would likely end up with people using the tools quite differently. People like me would dial up the type checking hints. I'd even like to be able to turn on contravariant return type checking to flag the foo example above, but I guess that's pushing it ;-)

A

[kc]

On Wednesday, February 12, 2014 8:00:46 PM UTC, Anders Holmgren wrote:

That was my thoughts when I read that too but dart's type system is not what I (and many others from a statically typed background) are used to (see https://www.dartlang.org/articles/why-dart-types/)

 

Gilad's comment on the other thread:

My *personal* view is that the type system really should be external to the language and entirely managed by tools. In Dart we chose differently - the type system interacts with the runtime in checked mode and this has important benefits and some drawbacks. Dart does not really support pluggable types - it's only taken 20 years to get optional types, so stay tuned ....

Back to Anders:

 

Personally I would be happy with tools that provide "hints" by doing type inferencing and leave it out of the VM if that simplifies things. Anything that helps me catch most of the simple errors up front would be a big help.

Exactly. So would I.
 

People from a dynamic background would probably not want to see those hints so I suspect they need to be configurable. You would likely end up with people using the tools quite differently. People like me would dial up the type checking hints. I'd even like to be able to turn on contravariant return type checking to flag the foo example above, but I guess that's pushing it ;-)

Exactly. Developers should be able to dial up and dial down the type checking/inference as they wish. But as Gilad noted in the presentation a rigid static type system has emerged by default.

Basically:
- Checked Mode should be removed from the DartVM
- the type system w/type inference belongs in a separate spec which can evolve separately to the language spec.

This is fundamentally why I think 'name:type' is a better syntax for type annotations. It makes the sale to developers that type annotations are *just* annotations much easier. ES7 is looking at type contracts/guards which amazing enough does look like an optional pluggable type system. And it can be much richer - as well as being more parsable/toolable:

gte18(x)=>x >= 18;
myfunc(age :int:gte18):int { // code }

If the language designers preferences were followed Dart would be a great language that would find the sweet spot between static and dynamic. But Dart has shot itself in the foot.

K.

[Alex Tatumizer]

Are you sure 'name: type' is that important for the feature to work? The following doesn't look bad to me:
int myfunc(int:gte18 age) { // code }

What stops from adding it to the language now?

[Gen]

Surprisingly I was surprised by the dart type checker and the bivariance for num, int and double.

But variance based type checks do not guarantee much because they require classes and objects to be defined accordingly (Liskov Substitution principle).

Does the Dart library respect LSP ? At least not for the above example where "int" is more restrictive than "num".

What remains are type hints for tools and bivariance limitations of nominal types and their instances.

Since Gilad is not fond of type systems and Dart is not meant as academic experiment for academics, I can understand to some degree the design of Dart.

And (IMHO less surprising and more flexible) structural types are not wanted for Dart either.

https://groups.google.com/a/dartlang.org/forum/?fromgroups#!searchin/misc/structural$20types/misc/zVaqpdOiHWQ/wZHymdSfbTYJ

Are type contracts/guards or dependent types the solution ?

I do not know.

And even if, which web developer wants to learn the type theory ?

Which Dart programmer should implement it ?

I have the impression that the Dart team has no resources to implement fancy stuff as experiment.

Can arbitrary type checkers be added and work with already defined classes and objects like in the standard library ?

I doubt it.

[Alex Tatumizer]

I recently ran into situation where "new" really hurts. Situation is so common I wonder why never became a subject of serious academic research (one could make a fortune on this topic).

The crucial observation is that "new" requires noun. But not everything is noun. Some verbs and adjectives and exclamations can play the role of nouns in certain contexts, without being nouns themselves, but they don't play well with "new". If this sounds vague, here's an example.

My functions - for some reason beyond this discussion - need to return commands. A lot of short functions, each can return a command like: "done", "cancel", "more", etc.

In a simple case I can define a constant MORE and say "return MORE".

But other instructions require parameters (e.g., cancel with such-and-such error message).

The only thing I can do now is to define class Command with named constructors, e.g

return new Command.done(42);

return new Command.cancel("busted");

etc.

Again, my functions are short 1-liners, they were supposed to demonstrate the cuteness of dart. Instead, they will scare users away with monstrosities like return new Command.cancel("busted").

What I could do if "new" was not mandatory? Simply define classes Done, Cancel etc (extending Command), and say

return Done(42)

return Cancel("busted")

Sometimes even "return" is redundant:
()=>Cancel("busted");

But I can't say return new Cancel("..."), because cancel cannot be "new", for it's a verb.

I'm in a terrible fix. Any advice?

[Greg Lowe]

Any advice?

Why not just define a top-level function.

done(foo) => new Done(foo);

Then you can:

return done(42);

[Alex Tatumizer]

I considered return done(...), return cancel(...), but I think in this context it should start with capital letter, that is,

return Done(42) is MUCH better than

return done(42)

The thing is that it's a command, not just a return value.

Please look at it again - do you think it's ok with lowercase?

[kc]

My core interest is the native Dart VM - and how tightly it will work with Blink in it's 2014 goal of 60fps on touch. Especially with the eventual native implementation of Web Components/Web Animations etc. (V8 has started work on the armv8 port - which I think is going to be the dominant mobile touch platform going forward).

The Dart VM does not use type annotations - so to me they are a side dish. They should get out of the way. Work for me rather than constrain me. The 'C' style type annotations are tricky to parse and restrict how Dart can develop the type system - whether in a guards direction or otherwise.

And 'C' style types mislead developers coming from other 'C' heritage languages:

C/C++
int i = 2; // stack allocation

Java/C#
int i = 2; // same but in byte code

Dart
int i = 2; // a binding to an Integer object of unlimited size. 'int' is just an annotation. Totally different.

I don't expect any syntax changes though - just that the InfoQ presentation reminded me of missed opportunities re simplicity. The key thing is the green light on the Dar tVM going into the client platforms - especially Android and ChromeOS.

K.

[Greg Lowe]

do you think it's ok with lowercase?

Fine by me.

Of course everything could be perfect with a new and perfect programming language, but in the meantime pragmatism always wins.

--

[Alex Tatumizer]

Oh, now I recall why lowercase "done" is no good: it's extremely error-prone!

People may call done(42) and think it matters. But it doesn't. It should be "return done(42)".

It looks like a function call, which is DOING something. This is not the case, It will be doing something only if returned as command. "Done" with capital D doesn't look like function call. That's the difference.

[Greg Lowe]

Oh well. Looks like you're going to have to design the perfect language then. Ping me when you're done ;)

I don't think this is really a problem. If a user forgets a return statement the function will implicitly return null this will be caught by unit tests. Better still if the function is annotated with a return type this will cause a static hint in the editor/analyzer (well soon - was implemented recently not sure when it ships).

[Alex Tatumizer]

I think, I'm leaning towards your suggestion. I better relax the rules. No "return". Just call "done(42)" at any point - it will create the object as if "new Command.done(42)" is called, and memorize it. After function returns, I will execute the command. Certain restrictions may (or may not) apply (e.g. just a single command can be placed in the buffer). In other words, it will be treated as "scheduleCommand".

But still, I think the problem is broader than my immediate needs. There should be naming convention or something about such delayed actions, at least for readability. Maybe there are precedents already, I'm just not aware of them. In java, people introduce a lot of classes like "MaximizeAction", "TextSizeAction", etc. but this style doesn't fit in dart at all IMO.
 

[Filipe Morgado]

IMO, we're discussing details here that do not affect productivity at all.

Some proposals (like the removal of 'new' or 'return') would only augment the learning curve for people coming from the most popular languages.

(and IMO make the language less readable).

Dart's syntax is set. It won't change now. Anyway, no professional developer chooses a language only for its syntax, but it's toolability, IDE and overall features.

And Dart is in the right path.

We should be discussing features that would actually bring more power to developers.

[Matthew Butler]

With all due respect, in this case you're faulting Dart's 'new' keyword for your library's API design? As you mention, the 'new' keyword prefers a noun... but this isn't something about Dart, this is about Class-based objects. A class represents an object, a noun. Not an action. Those are generally reserved for method names. (even your sample, isn't totally concise, as 'done' is a passive participle, aka finished, where 'cancel' is an action verb). Dealing with English, these issues can frequently arise, actually that's true for almost all languages (FWIW, I'd _love_ to see an API written in Esperanto!)

On Thursday, February 13, 2014 8:12:04 PM UTC-4, Alex Tatumizer wrote:

I think, I'm leaning towards your suggestion. I better relax the rules. No "return". Just call "done(42)" at any point - it will create the object as if "new Command.done(42)" is called, and memorize it. After function returns, I will execute the command. Certain restrictions may (or may not) apply (e.g. just a single command can be placed in the buffer). In other words, it will be treated as "scheduleCommand".

But still, I think the problem is broader than my immediate needs. There should be naming convention or something about such delayed actions, at least for readability. Maybe there are precedents already, I'm just not aware of them. In java, people introduce a lot of classes like "MaximizeAction", "TextSizeAction", etc. but this style doesn't fit in dart at all IMO.
 

Why is a Command factory (I'm assuming Command.done(42) would be a factory to create a new Done object) 'Dartish' but not DoneAction? Why Comamnd.xxx instead of Cmd.xx? or Verb.done(42)? I ran into much the same early on with one of my projects. That case was a little different, and I was creating new user input commands not API commands, so it made sense for the command to be passed as an argument to just a general Command constructor.

Just my $0.02CDN =)

Matt

[Alex Tatumizer]

Matthew,

I meant that with "new" keyword optional, I could create classes named Done, Cancel, etc, and say simply return Done(42). which would be as dartish as it gets.

The whole point was that "new" stands in the way of good writing, be it English writing or otherwise.

I was leaning towards the suggestion from prev, post yesterday, but today I stopped leaning  because I found a way to do with without constructors and functions at all (changed perspective, and things look different).

"new" is harmful and even not tenable (consider substring). That's the point I'd like to make. "new" was copied from C++ (where it's really needed) to java (where there's no much need in it) and then implanted into dart, where it's just a foreign element with no meaning or purpose. 

.

--

[Greg Lowe]

I think the main reason new is required is because only constructors are allowed to take generic type parameters. If we one day get generic type parameters for functions, then there is probably no reason why new cannot become optional. I believe this has been discussed before on the list.

[kc]

On Friday, February 14, 2014 3:41:55 PM UTC, Alex Tatumizer wrote:

Matthew,

I meant that with "new" keyword optional, I could create classes named Done, Cancel, etc, and say simply return Done(42). which would be as dartish as it gets.

The whole point was that "new" stands in the way of good writing, be it English writing or otherwise.

Sign of Classic OO Noodling:

 "To new, or not to new, that is the question—".  Thing or action hmm...

Solution: Crack open that massive tome of Design Patterns Vol IV. Polish that boilerplate.

Seriously Dartisans, there's a visceral sticker shock associated with eyeballing trad OO boilerplate. Which means there's a whole set of dev's who will have a quick look and move on.

K.