The Dart standards committee (ECMA TC52) met on January 14th, 2015. The committee discussed several areas where the language could be improved and agreed that these should be investigated in more detail, likely leading to detailed proposals over the next few months.
Some libraries only work on the server, or only on the client (in particular, if dart:html has been imported then a server execution is ruled out). There may be added support for some kind of conditional compilation such that different contexts may make different choices about which libraries to import.
Another proposal, which is much more complex and powerful, is concerned with parameterized libraries, e.g., libraries that may take type arguments or other libraries as arguments. Erik mentioned that the conditional compilation feature might already be included in the language, based on the ‘part’ mechanism, and Gilad agreed that that would be worth investigating, too.
First-class functions with different arity is another case. A problem with union types is that they tend to cause parsing conflicts; maybe they could be confined to typedef declarations, but that does not work well with generics; support for local typedefs may help. The operations allowed (when avoiding static type warnings) are just the ones in the common supertype of all operands of the union type operator, i.e., just the operations that are shared among all the types. Avoiding the accidentally shared operations (the ones that are declared independently in several operands) helps greatly avoiding a number of typing related complications.
It should be noted that union types may actually work quite well in Dart, especially because the assignability rules (rather than subtype rules) in the type system allows a value with a union type to be used where any of the operand types can be used.
Dart does not currently support generic methods (aka polymorphic methods, i.e., methods taking type arguments), because of the strong expectation that they will be supported by type inference, which would add substantial complexity to the language and create conflicts with the basic design of Dart (e.g., the VM might be forced to perform inference at run time at heavy cost, or the reification of types would give user code access to compiler-selected type values, which could change over time due to seemingly remote and insignificant changes in the code). So the generic methods in Dart will not be supported by type inference, all type arguments must be given explicitly or they will be implicitly provided by the compiler as <dynamic..dynamic>. The syntax is not yet settled, and in particular there are ambiguity problems with several proposals (foo(a<b, c>(d)) may be seen as foo(_) or foo(_,_)).
The property extraction mechanism (aka closurization or tear-offs) creates some problems in the language: the current syntax does not work for operators, getters, setters, and constructors, and it is even creating problems for optimization because it is not known before runtime whether ‘a.m’ will need to be executed as a property extraction or as a getter invocation. New syntax is proposed for tear-offs, generally using ‘#’ rather than ‘.’ to separate the receiver and the selector. No particular difficulties are foreseen after an initial review. For backward compatibility, the old syntax and the new will coexist.
This feature has been requested for a long time! It is simply a small amount of syntactic sugar, but it may be quite convenient and it may be good for code readability. We propose a?.b (the Elvis operator), which just nulls out the result when a is null; a??b which evaluates to the value of b as a default when a evaluates to null; and a ?= b, which sets a to the value of b iff a is null.
Improvements to Type Promotion
This is purely a static type system issue, concerned with the typing of variables for which there is a type test in the preceding control flow. We currently have a few rules about type promotion, deliberately avoiding the highly elaborate versions that so many participants in this debate have requested. These rules are sound, but this is actually not particularly well motivated in a language like Dart. In many cases, users consider the results counterintuitive (“Why can’t it see that x is an int here, I just tested!?”). We may choose to use an unsound approach where the implied intentions of programmers are taken much more for granted, even though there can be exceptions at runtime.
Erik mentioned that if a pluggable type checker could remove certain type warnings then it could be delegated to a pluggable type checker (or several) to perform arbitrarily fancy flow analyses, and do extra type promotion. This means that type promotion in the spec can be very simple, and all the tricky special cases can be handled in a pluggable manner.
Minor Adjustments to the Existing Specification
We may change ‘await throw’ to throw immediately. The rules about type checking usages of objects whose class declares ‘noSuchMethod’ need generalization. The name 'main' should be allowed to be other things than a top-level-function (e.g., a const variable whose value is a suitable closure). Finally, allow doc comments to access imported scope.
Erik mentioned that there is a proposal to revise function type subtyping, and Gilad responded that there may be a need to adjust the specification in this respect, to be discussed at the next meeting.
Friday, January 30, 2015
Thursday, January 29, 2015
There are many books about the Dart language and libraries, but most assume some knowledge of programming. For people that are brand new to software development and want to learn Dart, there is now Dart for Absolute Beginners (Apress).We sat down with author David Kopec, to learn how people can begin their programming journey with Dart.
Q) On behalf of the Dart team, thanks for writing Dart for Absolute Beginners! So, how did you discover Dart?
David: Working in the startup world, I always try to keep abreast of exciting emerging technologies in the sphere of software development that may ease the lives of developers like myself. I first came across Dart in late 2012 while trying to get a consumer automotive web startup in LA off the ground. Dart was still in its early phases, but I was quickly enamored with its clean design and potential to ease Web development for both professionals and novices alike. I took a mental note and thought — this is something I need to come back to!
Q) What made you want to write a book about Dart?
David: I think when one is the solo author of a book about an emerging language/platform, more than anything else, you need to believe in its potential. I see Dart as an opportunity for a clean slate. It’s a fresh start incorporating all that we’ve learned about best practices for language design over the past 20 years. I see the industry spending a lot of time shoehorning older web technologies into places that they don’t necessarily fit well at scale. Dart is a better approach.
Clearly, I wanted to be a Dart advocate, because I truly believed that it’s a better way forward for the Web. The book was the natural offspring of my belief in Dart, desire to write a beginner’s book, and opportunity in my career time-wise to do it.
Q) Who should read the book? Who is the book for?
David: Dart for Absolute Beginners is truly designed for absolute beginners - individuals with no programming experience. It aims to be a broad introduction to programming, the Dart language, selected parts of the Dart platform, and the technologies behind the Web. In short, readers who want to learn Dart as a first programming language are the intended audience.
With that said, I have also received positive feedback from programmers with some experience that seek a Dart book with an eased learning curve.
Q) Why should people new to software development start with Dart?
Dart delivers all of the benefits of developing for the Web (immediacy, compatibility) but in an elegant, consistent package. New programmers don’t need to worry about language gotchas, because the language is clean and consistent. They don’t need to worry about what libraries they need for their project, because the Dart standard library is comprehensive. They don’t struggle with including additional functionality, because pub is so easy-to-use. They don’t need to worry about browser compatibility (too much) because the Dart team handles that for them as part of the unified platform. They don’t even need to think about which IDE/text editor to use because the platform comes with an easy-to-use one.
Q) What makes Dart for Absolute Beginners special?
David: Dart for Absolute Beginners is the only book about Dart as a first programming language. All of the other books on the market assume at least a little bit of knowledge about another programming language. They are introductions to Dart, but not introductions to programming, Web technologies, and modern software development techniques for absolute beginners.
Beyond being an introduction to programming, Dart for Absolute Beginners also aims to be a broad introduction to modern Web software development techniques, in the sense that by the time the reader is done he or she will get a taste of version control with Git, unit testing, and even a basic understanding of HTTP. But my favorite feature is an included interview with the Dart project’s founders.
Q) How do you use Dart today?
David: I use Dart for client-side Web projects. I encourage consulting clients to have their projects built in Dart. I have not yet fully explored server-side Dart but it’s an area of future interest for me.
Q) What advice would you give to a developer learning Dart for the first time?
David: Beginning programmers often get frustrated by how far it is from Hello World to say making a graphical game. Don’t give up! Like anything else in life, programming takes time, practice, and dedication. Also, make sure you can walk before you attempt to run. I’ve seen beginners try to jump right into making a complicated Web app before they have mastered the basics of loops, data structures, and functions. That only leads to frustration. No matter what language you’re learning, the key is to have a solid foundation that you can build from. It’s not important to memorize all of the API calls in dart:html. You can always look those up. Memorization in programming isn’t especially helpful in the age of the search engine. Instead, beginners should work on building an understanding of language concepts.
Q) Where can developers follow you and your work?
David: My blog is Observational Hazard and I’m available for consulting projects through Oak Snow Consulting. You can also follow me on Twitter, G+, and GitHub.
Thanks David! Developers, new and experienced, can find Dart for Absolute Beginners at Amazon or Apress.