Dart spec 0.02

[Michael Hendricks]

I just noticed that the Dart Programming Language Specification was updated today to version 0.02  I've scoured the repository and commit history but haven't found the spec source code (looks like LaTeX).  Is the source available?  More importantly, is a change log for 0.02 available?

-- 

Michael

[Gilad Bracha]

Hi,

Yes, it is LaTeX.  No, the source isn't in the repo. And I haven't put a change list in yet. So far, it's mostly typos.

--
Cheers, Gilad

[⚛]

When I compare the introduction of Go language (www.golang.org) with
the introduction of Dart, I have the feeling that Go was more mature.
You could install it, you could read the spec (it wasn't tagged 0.01,
and it wasn't a PDF), there was the "Effective Go" document, you could
watch a 1 hour video introducing Go to the world, the run-time library
already contained a non-trivial amount of *working* code written in
Go, etc.

I respect Dart as such, but if you consider what I mentioned in the
previous paragraph - what do you think?

On Oct 15, 5:59 am, Gilad Bracha <gbra...@google.com> wrote:
> Hi,
>
> Yes, it is LaTeX.  No, the source isn't in the repo. And I haven't put a
> change list in yet. So far, it's mostly typos.
>

[Colin Putney]

On Sat, Oct 15, 2011 at 12:42 AM, ⚛ <0xe2.0x...@gmail.com> wrote:
> When I compare the introduction of Go language (www.golang.org) with
> the introduction of Dart, I have the feeling that Go was more mature.
> You could install it, you could read the spec (it wasn't tagged 0.01,
> and it wasn't a PDF), there was the "Effective Go" document, you could
> watch a 1 hour video introducing Go to the world, the run-time library
> already contained a non-trivial amount of *working* code written in
> Go, etc.
>
> I respect Dart as such, but if you consider what I mentioned in the
> previous paragraph - what do you think?

Sounds like Dart was introduced earlier in its development than Go.
This is a *good thing*.

Colin

[Damien Pollet]

On 15 October 2011 05:59, Gilad Bracha <gbr...@google.com> wrote:
> Yes, it is LaTeX.  No, the source isn't in the repo. And I haven't put a
> change list in yet. So far, it's mostly typos.

Can I recommend a \usepackage{hyperref}, if only for getting a
hyperlinked table of contents?

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

[Gilad Bracha]

On Sat, Oct 15, 2011 at 4:41 AM, Damien Pollet <damien...@gmail.com> wrote:

Can I recommend a \usepackage{hyperref}, if only for getting a
hyperlinked table of contents?

It's been on my todo list since day 1.   I've been more focused on content, but it'll happen soon.

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

--
Cheers, Gilad

[Bob Nystrom]

Yes, that's our belief too. I think Go's choice makes a lot of sense for a server-side back-end language. (And, in general, I think those guys do a fantastic job of building and polishing the language and the ecosystem around it. Everything I see from them just seems solid and well put together.)

Since Dart is aiming for the client-side web community, it will ultimately take wider adoption for the language to really succeed. To get that, we wanted to get it in front of people as soon as possible and start getting feedback. We're trying really hard to make Dart an open language that's embraced by the larger web world so we wanted to get you all involved as soon as we could, even if that meant raising the curtain a bit before we all had our costumes on and the sets nicely painted.

- bob

[Ladislav Thon]

> I think Go's choice makes a lot of sense for a server-side back-end language.
>

> Since Dart is aiming for the client-side web community

I personally like to think of Go as a system programming language, while Dart is an application programming language. I'd certainly love to do server-side programming in Dart (and I even think that Dart would be suitable for teaching programming!).

(And btw, while thinking about doing some real stuff, I quickly came up with a conclusion that the sole really missing thing now is reflection. Everything else -- I hope to write a mail about my opinions to the list soon -- can come later, but you can't even write a decent unit testing framework now. And yes, I've seen the one in samples.)

LT

[Bob Nystrom]

On Mon, Oct 17, 2011 at 3:14 PM, Ladislav Thon <lad...@gmail.com> wrote:

> I think Go's choice makes a lot of sense for a server-side back-end language.
>

> Since Dart is aiming for the client-side web community

I personally like to think of Go as a system programming language, while Dart is an application programming language. I'd certainly love to do server-side programming in Dart (and I even think that Dart would be suitable for teaching programming!).

Agreed on server-side Dart. I didn't mean to imply that we want Dart to only be a client-side language, but being on the client is important, and I think that requires broader user support than a strictly server-side language needs. 

(And btw, while thinking about doing some real stuff, I quickly came up with a conclusion that the sole really missing thing now is reflection. Everything else -- I hope to write a mail about my opinions to the list soon -- can come later, but you can't even write a decent unit testing framework now. And yes, I've seen the one in samples.)

I'm working on the unit test lib right now (it creaks under the weight of an old Java-style API). What don't you like about it?

For a point of reference, the new API I'm working on is:

main() {

  test('addition', () {

    expect(1 + 2).equals(3);

    expect(1 + 3).equals(4);

  });

  group('unary', () {

    test('postfix increment', () {

      var i = 3;

      expect(i++).equals(3);

      expect(i).equals(4);

    });

    test('prefix increment', () {

      var i = 3;

      expect(++i).equals(4);

      expect(i).equals(4);

    });

  });

}

If you have ideas for improving that, I'm interested to hear them.

- bob

[Dirk Detering]

Ha! That is a kind of style I'd wanted to see in the main samples!  Nice.

[Ladislav Thon]

main() {

  test('addition', () {

    expect(1 + 2).equals(3);

    expect(1 + 3).equals(4);

  });

  group('unary', () {

    test('postfix increment', () {

      var i = 3;

      expect(i++).equals(3);

      expect(i).equals(4);

    });

    test('prefix increment', () {

      var i = 3;

      expect(++i).equals(4);

      expect(i).equals(4);

    });

  });

}

Yeah, this looks pretty neat (I admit I was thinking too much Java-style), and it's completely different from what I've seen. But I guess you'd need a little more, at least before/after (setup/teardown), or JUnit-like "rules"... well, I assume you've already got that :-)

If matchers were an independent and extensible library (like Hamcrest in Java world), that would be great!

LT

[Bob Nystrom]

On Tue, Oct 18, 2011 at 1:23 AM, Ladislav Thon <lad...@gmail.com> wrote:

main() {

  test('addition', () {

    expect(1 + 2).equals(3);

    expect(1 + 3).equals(4);

  });

  group('unary', () {

    test('postfix increment', () {

      var i = 3;

      expect(i++).equals(3);

      expect(i).equals(4);

    });

    test('prefix increment', () {

      var i = 3;

      expect(++i).equals(4);

      expect(i).equals(4);

    });

  });

}

Yeah, this looks pretty neat (I admit I was thinking too much Java-style), and it's completely different from what I've seen. But I guess you'd need a little more, at least before/after (setup/teardown), or JUnit-like "rules"... well, I assume you've already got that :-)

I haven't figured that out yet because we haven't needed it yet, but I'll keep that in mind. I'm trying to keep it as terse as possible for simple cases where you don't need a lot of setup while still allowing that stuff when you do.

It shouldn't be too hard to do. Things get much easier I find when you can safely assume a single thread of control. :)

If matchers were an independent and extensible library (like Hamcrest in Java world), that would be great!

Extensibility here is an excellent idea. Let me give that some thought.

- bob

[John Tamplin]

On Tue, Oct 18, 2011 at 10:55 AM, Bob Nystrom <rnys...@google.com> wrote:

I haven't figured that out yet because we haven't needed it yet, but I'll keep that in mind. I'm trying to keep it as terse as possible for simple cases where you don't need a lot of setup while still allowing that stuff when you do.

It shouldn't be too hard to do. Things get much easier I find when you can safely assume a single thread of control. :)

If matchers were an independent and extensible library (like Hamcrest in Java world), that would be great!

Extensibility here is an excellent idea. Let me give that some thought.

Another consideration is IDE support like Eclipse's JUnit support, and integration with code coverage tools.

--
John A. Tamplin
Software Engineer (GWT), Google

[Bob Nystrom]

I'm definitely keeping that in mind too, though my first goal is a nice API that's usable without tooling.

- bob

[Ladislav Thon]

If matchers were an independent and extensible library (like Hamcrest in Java world), that would be great!

Extensibility here is an excellent idea. Let me give that some thought.

I was thinking about this today and decided to finally write some code. I won't say that this is idiomatic Dart (it probably looks a lot like Java), but I hope it will be useful to someone. So, this is my attempt at standalone extensible matchers library in Dart: https://github.com/Ladicek/dart-matchers

LT

[Bob Nystrom]

main() {


  expectThat(0, zero());
  expectThat(1, not(zero()));

  expectThat(1, positive());

  expectThat(-1, negative());

  expectThat(1, equals(1));

  expectThat(1, lessThan(2));

  expectThat(1, lessThanOrEqual(1));

  ...


  expectThat("abc", contains("b"));


  expectThat("abc", matches("a.c"));


  expectThat("abc", matches(new RegExp("a.c")));


  expectThat("abcd", not(matches(@"^a.c$")));





  print('ok');
}

That looks pretty nice! The only thing I'm a little iffy on is that it means putting all of the matchers in top-level scope. Things like "zero" and "not" and "contains" seem like there's a decent chance they may collide with a name in the code you're trying to test. That's one of the things I was hoping to avoid by using chaining.

I'd be curious to hear anyone else's opinion on this.

- bob

[Colin Putney]

On Tue, Oct 18, 2011 at 1:27 PM, Bob Nystrom <rnys...@google.com> wrote:

> That looks pretty nice! The only thing I'm a little iffy on is that it means
> putting all of the matchers in top-level scope. Things like "zero" and "not"
> and "contains" seem like there's a decent chance they may collide with a
> name in the code you're trying to test. That's one of the things I was
> hoping to avoid by using chaining.
> I'd be curious to hear anyone else's opinion on this.

+1 on chaining. A library shouldn't pollute the top-level scope.

Colin

[Ladislav Thon]

That looks pretty nice! The only thing I'm a little iffy on is that it means putting all of the matchers in top-level scope. Things like "zero" and "not" and "contains" seem like there's a decent chance they may collide with a name in the code you're trying to test.

Yes, I agree. If Dart had something like "static imports" from Java, these functions could be moved to one class while still allowing this kind of concise code...

 

That's one of the things I was hoping to avoid by using chaining.

Oh, I totally forgot about that. Will have a look at it... but I can only think of noSuchMethod as an extension point.

LT

[Bob Nystrom]

On Tue, Oct 18, 2011 at 1:40 PM, Ladislav Thon <lad...@gmail.com> wrote:

Oh, I totally forgot about that. Will have a look at it... but I can only think of noSuchMethod as an extension point.

I was thinking something along the same lines. A couple of problems I can think of with it:

1. It feels weird to have to go around the type system and go completely dynamic for this. It feels like a fairly straightforward use case so it doesn't seem like you should have to jump through hoops like this.

2. Tests would have to explicitly register the matchers before they run:

  main() {

    addMatcher('isAwesome', new AwesomeMatcher());

    expect('bob').isAwesome();

  }

The nice thing about just using functions or methods is that they are statically/declaratively defined.

So far at least, I haven't really needed extensibility here anyway, so I'll probably just not worry about it for the short term and see if it becomes something I miss.

- bob

[Alan Knight]

If your tests were in test classes as in xUnit, then couldn't you just provide all those as methods on a Test superclass.

---

Bob Nystrom
18 October, 2011 4:27 PM

main() {


  expectThat(0, zero());
  expectThat(1, not(zero()));

  expectThat(1, positive());

  expectThat(-1, negative());

  expectThat(1, equals(1));

  expectThat(1, lessThan(2));

  expectThat(1, lessThanOrEqual(1));

  ...


  expectThat("abc", contains("b"));


  expectThat("abc", matches("a.c"));


  expectThat("abc", matches(new RegExp("a.c")));


  expectThat("abcd", not(matches(@"^a.c$")));





  print('ok');
}

That looks pretty nice! The only thing I'm a little iffy on is that it means putting all of the matchers in top-level scope. Things like "zero" and "not" and "contains" seem like there's a decent chance they may collide with a name in the code you're trying to test. That's one of the things I was hoping to avoid by using chaining.

I'd be curious to hear anyone else's opinion on this.

- bob

---

Ladislav Thon
18 October, 2011 3:59 PM

I was thinking about this today and decided to finally write some code. I won't say that this is idiomatic Dart (it probably looks a lot like Java), but I hope it will be useful to someone. So, this is my attempt at standalone extensible matchers library in Dart: https://github.com/Ladicek/dart-matchers

LT

---

Bob Nystrom
18 October, 2011 1:55 PM

On Tue, Oct 18, 2011 at 1:23 AM, Ladislav Thon <lad...@gmail.com> wrote:

main() {

  test('addition', () {

    expect(1 + 2).equals(3);

    expect(1 + 3).equals(4);

  });

  group('unary', () {

    test('postfix increment', () {

      var i = 3;

      expect(i++).equals(3);

      expect(i).equals(4);

    });

    test('prefix increment', () {

      var i = 3;

      expect(++i).equals(4);

      expect(i).equals(4);

    });

  });

}

Yeah, this looks pretty neat (I admit I was thinking too much Java-style), and it's completely different from what I've seen. But I guess you'd need a little more, at least before/after (setup/teardown), or JUnit-like "rules"... well, I assume you've already got that :-)

I haven't figured that out yet because we haven't needed it yet, but I'll keep that in mind. I'm trying to keep it as terse as possible for simple cases where you don't need a lot of setup while still allowing that stuff when you do.

It shouldn't be too hard to do. Things get much easier I find when you can safely assume a single thread of control. :)

If matchers were an independent and extensible library (like Hamcrest in Java world), that would be great!

Extensibility here is an excellent idea. Let me give that some thought.

- bob

---

Ladislav Thon
18 October, 2011 4:23 AM

Yeah, this looks pretty neat (I admit I was thinking too much Java-style), and it's completely different from what I've seen. But I guess you'd need a little more, at least before/after (setup/teardown), or JUnit-like "rules"... well, I assume you've already got that :-)

If matchers were an independent and extensible library (like Hamcrest in Java world), that would be great!

LT

---

Bob Nystrom
17 October, 2011 6:21 PM

On Mon, Oct 17, 2011 at 3:14 PM, Ladislav Thon <lad...@gmail.com> wrote:

> I think Go's choice makes a lot of sense for a server-side back-end language.
>

> Since Dart is aiming for the client-side web community

I personally like to think of Go as a system programming language, while Dart is an application programming language. I'd certainly love to do server-side programming in Dart (and I even think that Dart would be suitable for teaching programming!).

Agreed on server-side Dart. I didn't mean to imply that we want Dart to only be a client-side language, but being on the client is important, and I think that requires broader user support than a strictly server-side language needs. 

(And btw, while thinking about doing some real stuff, I quickly came up with a conclusion that the sole really missing thing now is reflection. Everything else -- I hope to write a mail about my opinions to the list soon -- can come later, but you can't even write a decent unit testing framework now. And yes, I've seen the one in samples.)

I'm working on the unit test lib right now (it creaks under the weight of an old Java-style API). What don't you like about it?

For a point of reference, the new API I'm working on is:

main() {

  test('addition', () {

    expect(1 + 2).equals(3);

    expect(1 + 3).equals(4);

  });

  group('unary', () {

    test('postfix increment', () {

      var i = 3;

      expect(i++).equals(3);

      expect(i).equals(4);

    });

    test('prefix increment', () {

      var i = 3;

      expect(++i).equals(4);

      expect(i).equals(4);

    });

  });

}

[Bob Nystrom]

On Tue, Oct 18, 2011 at 2:46 PM, Alan Knight <kni...@acm.org> wrote:

If your tests were in test classes as in xUnit, then couldn't you just provide all those as methods on a Test superclass.

Yup. That's actually the old API works:

void main() {

  new SwarmTests().run();

}

class SwarmTests extends UnitTestSuite {

  SwarmTests() : super() {}

  void setUpTestSuite() {

    addTest(testBackButton);

    addTest(testStoryView);

    addTest(testSliderMenu);

  }

  ...

  void testSliderMenu() {

    Expect.equals(getView(swarm.sections[0]), swarm.frontView.currentSection);

    // Find the first slider menu item, and click on the one next after it.

    _click(document.queryAll('.${CSS.SM_ITEM}')[1]);

    Expect.equals(getView(swarm.sections[1]), swarm.frontView.currentSection);

    // Find the first menu item again and click on it.

    _click(document.query('.${CSS.SM_ITEM}'));

    Expect.equals(getView(swarm.sections[0]), swarm.frontView.currentSection);

  }

}

I'm trying to move away from that style because it's a bit painfully verbose, especially when you have a small test suite. It's a lot of boilerplate to define and instantiate a subclass of UnitTestSuite. It's also a bit trickier to split suites across multiple files (though the TestSet stuff I added alleviates that).

My goal is a lighter-weight less... uh... Java-like API. The above with the new API would be:

void main() {

  test('BackButton', () { ... });

  test('StoryView', () { ... });

  test('SliderMenu', () {

    expect(swarm.frontView.currentSection).equals(getView(swarm.sections[0]));

    // Find the first slider menu item, and click on the one next after it.

    _click(document.queryAll('.${CSS.SM_ITEM}')[1]);

    expect(swarm.frontView.currentSection).equals(getView(swarm.sections[1]));

    // Find the first menu item again and click on it.

    _click(document.query('.${CSS.SM_ITEM}'));

    expect(swarm.frontView.currentSection).equals(getView(swarm.sections[0]));

  });

}

The main thing you lose with this is an implicit this that you can hang methods off of. Instead, those become top-level functions, or methods on the result of expect(). I think this is a net win, but (like everything so far) this is fairly experimental.

- bob

 

[Ladislav Thon]

> If your tests were in test classes as in xUnit, then couldn't you just provide all those as methods on a Test superclass.

I certainly could, but:

1. Inheritance is bad :-)

2. Matchers are useful for more things than just testing (think validation etc.)

LT

[John Tamplin]

On Tue, Oct 18, 2011 at 1:44 PM, Bob Nystrom <rnys...@google.com> wrote:

1. It feels weird to have to go around the type system and go completely dynamic for this. It feels like a fairly straightforward use case so it doesn't seem like you should have to jump through hoops like this.

It seems like you would want to use code generation and mirrors for this, to achieve an effect like JUnit.

[Alan Knight]

John Tamplin wrote:

On Tue, Oct 18, 2011 at 1:44 PM, Bob Nystrom <rnys...@google.com> wrote:

1. It feels weird to have to go around the type system and go completely dynamic for this. It feels like a fairly straightforward use case so it doesn't seem like you should have to jump through hoops like this.

It seems like you would want to use code generation and mirrors for this, to achieve an effect like JUnit.

Yes, I'd think this is very obvious use for reflection. And the comment that there's an awful lot of boilerplate to create and instantiate a test class seems like it might be saying the language has too much boilerplate text to do what seems like a trivial operation.  But with a reflection based mechanism you shouldn't have to do this. The typical thing is that you find all the TestCase subclasses and find all the methods on them that are marked as tests (by naming convention that they start with test, by an annotation mechanism, or whatever) and invoke them.

That does leave the question of how to do the test framework when there isn't any reflection available yet. But the code I've seen so far seems like something I'd consider a stopgap until better facilities became available.

[Dirk Detering]

Am 18.10.2011 22:40 schrieb "Ladislav Thon" <lad...@gmail.com>:

> Yes, I agree. If Dart had something like "static imports" from Java, these functions could be moved to one class while still allowing this kind of concise code...

Seems much more this is a call for mix-ins again.

[Dirk Detering]

Am 19.10.2011 04:33 schrieb "Alan Knight" :
> That does leave the question of how to do the test
> framework when there isn't any reflection available yet.
>But the code I've seen so far seems like something I'd
> consider a stopgap until better facilities became available.

It is a more functional approach and I would prefer such over reflection, so perhaps more than only a stopgap.

Looking at
Void main() {
     test('somename', () {...} );

I wonder what 'test' is.   If it's a function only or perhaps a method on an already instanciated and configured test frame.

var test = new Tester()
  test.setup = () => //some preparation here

  test.add('test',  (ctx) {  do something, use ctx } );

  test.run()

BTW:  Groovy has a very nice feature. It allows for setting the delegate on a closure, such that it builds the scope on which free method calls are searched.

[Dirk Detering]

Regarding Delegate:  Ladislav Thon formulated the same idea in a PM I read afterwards.   So perhaps a valid point for consideration?

[Ladislav Thon]

Regarding Delegate:  Ladislav Thon formulated the same idea in a PM I read afterwards.   So perhaps a valid point for consideration?

Hah, sorry, didn't mean that to be a PM -- a hate these mailing lists with Reply-To not set to the main list address...

LT 

[Bob Nystrom]

On Wed, Oct 19, 2011 at 3:06 AM, Dirk Detering <mail...@googlemail.com> wrote:

Am 19.10.2011 04:33 schrieb "Alan Knight" :

> That does leave the question of how to do the test
> framework when there isn't any reflection available yet.
>But the code I've seen so far seems like something I'd
> consider a stopgap until better facilities became available.

It is a more functional approach and I would prefer such over reflection, so perhaps more than only a stopgap.

Looking at
Void main() {
     test('somename', () {...} );

I wonder what 'test' is.   If it's a function only or perhaps a method on an already instanciated and configured test frame.

It's just a function.

 

var test = new Tester()
  test.setup = () => //some preparation here

  test.add('test',  (ctx) {  do something, use ctx } );

  test.run()

That style works too, and our current API does actually support that right now. You could/can do:

var suite = new UnitTestSuite();

suite.addTest(() { ... });

suite.run();

It doesn't take in a test context argument to the tests. Instead, that stuff is just available in lexical scope. I'm trying to move away from this style for a few reasons:

1. It's more verbose. With unit tests in particular, the easier they are to write, the more likely I think people are to actually write them.

2. You can forget to call addTest(). Sounds dumb, I know, but for a while, our style was to define named test functions like 'testFoo' like you would in xUnit and then call addTest() to register it (since we don't have reflection yet). It was an all-too-common error to forget to actually add the test, and then it looks like everything passes.

3. Worse, you can forget to call run(). Then it looks like everything passes but it's because you didn't run anything at all. (Though a best test runner would catch this.)

I think Dart in general is smarter about top-level scope than most dynamic languages, so I wanted to try out a test API that relies on that and is as light-weight as possible. We'll see how it goes.

BTW:  Groovy has a very nice feature. It allows for setting the delegate on a closure, such that it builds the scope on which free method calls are searched.

Like a lot of things in Groovy, I find that feature fascinating. But it is a bit scary to me. I'm not a VM person, but I would worry that being able to change the name resolution strategy might have heinous performance implications.

I also worry that it makes it harder for a reader to understand how a name is being resolved. If I see this in Groovy:

{ foo }

I can't, statically, just by reading the program text, tell where foo is going to be looked up. It depends on where that closure is being invoked and whether or not its resolution strategy is being changed. I think that's a really cool feature for Groovy, but Dart is probably too conservative to go in that direction.

- bob