DEP meeting notes

[Bob Nystrom]

Sorry I've been behind on meeting notes. Here are the notes from last week's meeting:

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-11-11%20DEP%20Committee%20Meeting.md

The week before that, we met informally but didn't discuss any concrete proposals. It was more process administrivia, so I didn't write up notes. There was no DEP meeting this week.

Cheers!

– bob

[Jan Mostert]

Binary: 01001b
Octal: 74346o
Hex: 35535FA4x

This would also useful, 3E2 == 300

Also, what would the downside of doing 1,300,588 instead of 1_300_588 or will this screw with type inference?

--
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
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Harry Terkelsen]

I think that would make the grammar ambiguous for lists of expressions, eg in a function call. What would f(1,300,588) mean?

[Jan Mostert]

True, I agree with that and underscores are certainly better than spaces.

[Lasse R.H. Nielsen]

On Fri, Nov 20, 2015 at 6:16 AM, Jan Mostert <jan.m...@gmail.com> wrote:

Binary: 01001b
Octal: 74346o
Hex: 35535FA4x

That's not really the C-language style. 0b01001, 0o74346 and 0x35535fa4 is more consistent with the existing 0x prefiox.

 

This would also useful, 3E2 == 300

3e2 already means 300.0

 

An alternative is to introduce "p" as the exponent for integers:

   3p2 => 300

   0x3p2 => 0x300

   0b1p5 => 0b100000

(no negative powers allowed).

Also, what would the downside of doing 1,300,588 instead of 1_300_588 or will this screw with type inference?

As Harry pointed out, it will screw with parsing.

/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

[Jan Mostert]

"That's not really the C-language style. 0b01001, 0o74346 and 0x35535fa4 is more consistent with the existing 0x prefiox."

Ah, misread the meeting notes, for a moment thought the suggestion was 0b or 1b or 010101b
Also prefer the 0b10101 style.

"3e2 already means 300.0"

Awesome!

"An alternative is to introduce "p" as the exponent for integers"

Power and exponent are not the same things.
I'd rather let 3p2 => 9 (or alternatively 3^2) and 3e2 => 300

--

[Lasse R.H. Nielsen]

On Fri, Nov 20, 2015 at 7:45 AM, Jan Mostert <jan.m...@gmail.com> wrote:

"3e2 already means 300.0"

Awesome!

"An alternative is to introduce "p" as the exponent for integers"

Power and exponent are not the same things.
I'd rather let 3p2 => 9 (or alternatively 3^2) and 3e2 => 300

We can't use 3e2 as an integer since it's already defined syntax for a double. We need another syntax.

Using "p" is an option, "e" is not. It means the same, it's just for integers instead of doubles.

Also "3^2" already means something else, so we can't use that for power.

If we wanted to add a power operator, it would have to be a new operator, most likely "**".

[Jan Mostert]

Just think it would be strange to have a different operator for a different type, it's not like you use a + sign for integers and another symbol to add up floats ... wouldn't this solve it?

float f1 = 300e3; // this would give 300000 and since the type is float, casts it to 300000.0

float f2 = 300.0e3; // this would give 300000.0 and no casting needed.

or the Java equivalent of 300.0 would be 300f, but that would look weird doing 300fe3

int i1 = 300e3; this would  give 300000;

int i2 = 300.0e3; this would give 300000.0 which would fail with some sort of loss of precision exception when trying to cast it;

So the type before the e would transferred to the result.

If you're doing 0x1A1e3, would that mean
  1A1 (hexadecimal) x (10 x 10 x 10 dec)
  or
  1A1 (hexadecimal) x (F x F x F hex)

Or would you have to specify the type of both sides, eg 0x1A1e0x3 to mean the former and 0x1A1e3 to mean the latter?

--

[Lasse R.H. Nielsen]

On Fri, Nov 20, 2015 at 10:41 AM, Jan Mostert <jan.m...@gmail.com> wrote:

Just think it would be strange to have a different operator for a different type, it's not like you use a + sign for integers and another symbol to add up floats ... wouldn't this solve it?

float f1 = 300e3; // this would give 300000 and since the type is float, casts it to 300000.0

Not in Dart. There is no automatic conversion anywhere, objects have the type they have. Also, Dart does not have "float" as a type :)

In this case 300e3 is defined to be the double value 300000.0, changing that is a breaking change at the language level. It's also different from pretty much any other language. I don't know any languages where 300e3 is not a double (some of them have automatic conversion - but the literal is a double literal).

 

float f2 = 300.0e3; // this would give 300000.0 and no casting needed.

or the Java equivalent of 300.0 would be 300f, but that would look weird doing 300fe3

int i1 = 300e3; this would  give 300000;

Yeah, it would be nice, but we can't do that without changing the language, and I don't think that's likely to happen for something like this.

 

int i2 = 300.0e3; this would give 300000.0 which would fail with some sort of loss of precision exception when trying to cast it;

Again, not in Dart. It will fail with a type error in checked mode because a double is not an integer.

 

So the type before the e would transferred to the result.

If you're doing 0x1A1e3, would that mean
  1A1 (hexadecimal) x (10 x 10 x 10 dec)
  or
  1A1 (hexadecimal) x (F x F x F hex)

1A1 (hexadecimal) x (10 x 10 x 10 hex)  more likely.

I would let:

   integerLiteral 'p' decimalLiteral

be (the value of integerLiteral) * (the base of integerLiteral) ** (the value of decimalLiteral) so

 0xABCDp4 is 0xABCD * (16 ** 4)

and

 0b1101p4  is  0b1101 * (2 ** 4)  // aka 0b1001 << 4

Maybe we only need this for decimal literals, because base 2 and 16 can both be handled by shifts instead.

 

Or would you have to specify the type of both sides, eg 0x1A1e0x3 to mean the former and 0x1A1e3 to mean the latter?

Ick, no.

And this also brings up another problem with 'e' that I forgot to mention: It doesn't work with hex numbers: 0x1A1e3 is already a valid hex-literal, where the 'e' means something. That's another reason for using, for example, 'p' instead for literals. 

 

[Jan Mostert]

Exponent is probably not that useful for integers in any case, interesting discussion though :-)

--

[Anders Holmgren]

> From talking to users, his impression is that users are reaching for const because they really want 

> immutable objects. So maybe the real problem we should be tackling is explicitly supporting objects that 

> are deeply immutable after construction.

Want muchos ^^

[Anders Holmgren]

Bob,

Do you have a rough roadmap for the ghost of DEPs past. Something like

1/ DEPs we plan to implement soon

2/ DEPs we plan to implement in the medium term

3/ DEPs we plan to implement in the long term

4/ DEPs we accepted but have no idea whether we will implement them.

I suspect many are like me and read these posts with interest and get excited when their pet DEPs (pet features) are discussed and make their way through this process, only to get disheartened as the DEPs disappear from sight when they come out the other end.

There are many DEPs that I have gotten excited about such as NNBD and generic methods, that I'd love to know where they fit into the rough scheme of things

A

[Bob Nystrom]

+floitsch

On Fri, Nov 20, 2015 at 12:43 PM, Anders Holmgren <andersm...@gmail.com> wrote:

Do you have a rough roadmap for the ghost of DEPs past. Something like

1/ DEPs we plan to implement soon

2/ DEPs we plan to implement in the medium term

3/ DEPs we plan to implement in the long term

4/ DEPs we accepted but have no idea whether we will implement them.

I don't, at least not anything very formal. One of the things we're still figuring out is how to track proposals effectively without adding a lot of overhead to the process.

Florian is probably the best person to ask about priority and stuff like that.

 

I suspect many are like me and read these posts with interest and get excited when their pet DEPs (pet features) are discussed and make their way through this process, only to get disheartened as the DEPs disappear from sight when they come out the other end.

I feel your pain.

There are many DEPs that I have gotten excited about such as NNBD and generic methods, that I'd love to know where they fit into the rough scheme of things

Generic methods are being very actively worked on by the DDC and analyzer folks. If you read Vijay's status updates on the dev-compiler list, you'll see they generally talk about progress on generic methods.

My understanding—and don't hold me to this—is that when/if that is done, then they'll move on to NNBD.

Those two features are the highest priority for a lot of people on the team (including me).

Cheers!

– bob

[Anders Holmgren]

On Saturday, 21 November 2015 10:00:17 UTC+11, Bob wrote:

+floitsch

On Fri, Nov 20, 2015 at 12:43 PM, Anders Holmgren <andersm...@gmail.com> wrote:

Do you have a rough roadmap for the ghost of DEPs past. Something like

1/ DEPs we plan to implement soon

2/ DEPs we plan to implement in the medium term

3/ DEPs we plan to implement in the long term

4/ DEPs we accepted but have no idea whether we will implement them.

I don't, at least not anything very formal. One of the things we're still figuring out is how to track proposals effectively without adding a lot of overhead to the process.

Sure I don't want it to slow down getting the features out

 

Florian is probably the best person to ask about priority and stuff like that.

 

I suspect many are like me and read these posts with interest and get excited when their pet DEPs (pet features) are discussed and make their way through this process, only to get disheartened as the DEPs disappear from sight when they come out the other end.

I feel your pain.

There are many DEPs that I have gotten excited about such as NNBD and generic methods, that I'd love to know where they fit into the rough scheme of things

Generic methods are being very actively worked on by the DDC and analyzer folks. If you read Vijay's status updates on the dev-compiler list, you'll see they generally talk about progress on generic methods.

I heard that they were working on an annotation based mechanism (which I understand is an interim solution). Are they also working on direct language support already or is that still in the future?

My understanding—and don't hold me to this—is that when/if that is done, then they'll move on to NNBD.

OK I'll try to contain my excitement and not get my hopes up but I have to say that just made my day. Dart is gonna be so awesome once those two features land IMO

[Florian Loitsch]

On Fri, Nov 20, 2015 at 3:08 PM Anders Holmgren <andersm...@gmail.com> wrote:

On Saturday, 21 November 2015 10:00:17 UTC+11, Bob wrote:

+floitsch

On Fri, Nov 20, 2015 at 12:43 PM, Anders Holmgren <andersm...@gmail.com> wrote:

Do you have a rough roadmap for the ghost of DEPs past. Something like

1/ DEPs we plan to implement soon

2/ DEPs we plan to implement in the medium term

3/ DEPs we plan to implement in the long term

4/ DEPs we accepted but have no idea whether we will implement them.

I don't, at least not anything very formal. One of the things we're still figuring out is how to track proposals effectively without adding a lot of overhead to the process.

Sure I don't want it to slow down getting the features out

 

Florian is probably the best person to ask about priority and stuff like that.

It doesn't look that way, but my highest priority is configuration-specific imports.

They have nice benefits, and are non-breaking.

My current plan is to bundle breaking chances (like generic methods and NNBD) and release them in a bigger release.

The scope of that release isn't completely defined yet, but those two features have a good chance of getting in. They are mostly gated by tooling support and our experience when migrating old code to it.

If it's a painless experience (which requires good tools), then they have a higher chance, than if it is a real pain.

A few people here are still busy with other tasks, so we haven't had a lot of time to experiment with tools, user experience and prototypes.

Over time, more people will work on those.

[Anders Holmgren]

Thanks a lot for the update Florian

[Don Olmstead]

With the NNBD are union types in play? Its always sounded like those would go well together.

[Filipe Morgado]

Unfortunately, I don't think so, even though it be would useful for JS/TS-interop.

They not only go well together, they're fundamentally the same feature.

[Anders Holmgren]

Yeah union types would be very nice too. I never thought of it that way but I guess they can be viewed as essentially the same feature

On Sun, 22 Nov 2015 at 09:16 Filipe Morgado <pix...@gmail.com> wrote:

Unfortunately, I don't think so, even though it be would useful for JS/TS-interop.

They not only go well together, they're fundamentally the same feature.

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

You received this message because you are subscribed to a topic in the Google Groups "Dart Misc" group.
To unsubscribe from this topic, visit https://groups.google.com/a/dartlang.org/d/topic/misc/aadjSmvmi8Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to misc+uns...@dartlang.org.

[Ladislav Thon]

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-11-11%20DEP%20Committee%20Meeting.md

I had a working implementation of binary literals in the VM years ago, and it took me just a few hours. And that was probably the biggest piece of C++ code I ever wrote, in a codebase I was never really familiar with.

What I'm saying is that 1. these small pieces really are quite small :-), 2. the community might help with them.

LT

P.S.: sorry for being terse, need to run.

[kc]

On Friday, November 20, 2015 at 8:43:32 PM UTC, Anders Holmgren wrote:

Bob,

Do you have a rough roadmap for the ghost of DEPs past. Something like

1/ DEPs we plan to implement soon

2/ DEPs we plan to implement in the medium term

3/ DEPs we plan to implement in the long term

4/ DEPs we accepted but have no idea whether we will implement them.

Something like this:

https://github.com/dotnet/roslyn/issues/2136

 

I suspect many are like me and read these posts with interest and get excited when their pet DEPs (pet features) are discussed and make their way through this process, only to get disheartened as the DEPs disappear from sight when they come out the other end.

There are many DEPs that I have gotten excited about such as NNBD and generic methods, that I'd love to know where they fit into the rough scheme of things

Communication for Dart 1.x was poor.

K.

 

[kc]

Would, for example, we rather have the team implementing for binary literals—including parser support in the analyzer, dart2js, VM, syntax highlighters, tests, specification, etc.—or should we spend that time doing things like making analyzer faster or adding VM features the Flutter folks want?

The latter is Darts opportunity to become relevant outside Google.

K.