[dart-misc] Proposal: More number types and a reliable "int" type

[Gen]

Hi,

I think it might to good to make these changes:
1) Introduce number types or numeric types like in Go.
These types tell the programmer what kind of number is required and
expected.
Numbers might be used in a more efficient and familiar way for people
coming from typed languages.
No need to hide a Uint8List as List<int> in dart:io.
AFAIK, the []= operation even truncates the bound number without notice in
the documentation. This is bad documentation and API design, IMHO.
No need to import "dart:typed_data" for basic use of numbers.
2) Implement the "int" type as arbitrary size integer even when compiled to
Javascript or any other language or platform.

[Jim Trainor]

Post by Gen
2) Implement the "int" type as arbitrary size integer even when compiled

to Javascript or any other language or platform.

+1

Post by Gen
Hi,
1) Introduce number types or numeric types like in Go.
These types tell the programmer what kind of number is required and
expected.
Numbers might be used in a more efficient and familiar way for people
coming from typed languages.
No need to hide a Uint8List as List<int> in dart:io.
AFAIK, the []= operation even truncates the bound number without notice in
the documentation. This is bad documentation and API design, IMHO.
No need to import "dart:typed_data" for basic use of numbers.
2) Implement the "int" type as arbitrary size integer even when compiled
to Javascript or any other language or platform.
--
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

[Filipe Morgado]

+1 for fixed numeric types (i32, u32, i64, f32, f64, etc).

But I'm afraid it would require a sound static type system, if we don't wanna box everything.

I guess Dart is just not the right choice for any serious numerical computation.

WRT to "implement 'int' as arbitrary size integer when compiled to javascript", isn't that the case already?

I would't like to see bigints being messed with, they're too valuable, IMO.

Maybe we should propose bigints to JS instead. (Nevermind, they would be implemented somewhere in 2030, optimistically)

[Filipe Morgado]

(misunderstood point 2 and, although I'm not a dart2js user, I kinda agree with Bob)

['Bob Nystrom' via Dart Misc]

Post by Gen
1) Introduce number types or numeric types like in Go.

I like the idea of introducing these as type *annotations* so that users
can express size expectations for Dart implementations where that's
meaningful.

I'm less clear on what that should say about the semantics of variables
annotated with that type. Having it actually affect the arithmetic behavior
(overflow) would go against Dart's fundamental property that type
annotations do not affect runtime behavior.

I think it opens up some questions about size-annotated number literals
too, like 123ul in C. Those could be useful for bottom-up type inference.

I've thought about writing this up as a proposal but I don't know if it
will just open a giant unproductive can of worms. I was planning to sit on
it until we have a platform team really asking for it.

These types tell the programmer what kind of number is required and

Post by Gen
expected.
Numbers might be used in a more efficient and familiar way for people
coming from typed languages.
No need to hide a Uint8List as List<int> in dart:io.
AFAIK, the []= operation even truncates the bound number without notice in
the documentation. This is bad documentation and API design, IMHO.
No need to import "dart:typed_data" for basic use of numbers.
2) Implement the "int" type as arbitrary size integer even when compiled
to Javascript or any other language or platform.

-1.

The default "int" type should be large *and fast* enough for most uses.
Bigints are more than large enough but not fast enough. 32-bit ints get you
surprisingly far.

If you do need something bigger than that, you probably also have other
numeric requirements: units of measure, currency, banker's rounding,
rationals, etc. If you care enough about numerics that you need
arbitrary-precision, I don't think any one-size-fits-all number type in the
language will be good enough. We have operator overloading. Use a bignum
library that does *exactly* what you need.

– bob

[Gen]

I agree with the reasoning.
It is just that I do not know what can be expected from the VM or the
compiler.
Even in 2015 for Java, people advice to use int[] instead of
ArrayList<Integer> and to think about Boxing/Unboxing if memory and
performance is of importance.
It would be unfortunate to waste technical resources just because different
number classes are not available.
Maybe Dart's special implementation of integers does not work well with
serialization or interaction with databases.

A quote from https://github.com/dartist/dart-bignum

Caveats
Currently few known bugs exist while compiling from dart2js. One is
working with bitwise operators, the internal implementation of shift
operators with dart2js does not handle the same way as the VM. Most of this
code was ported from v8 benchmark suite <http://goo.gl/jTEfH>. Tom Wu
<http://www-cs-students.stanford.edu/%7Etjw/jsbn/> is to thank for the
core javascript implementation and the v8 team for optimizations on
different javascript virtual machines.

And yesterday I read
https://medium.com/@c2c/nodejs-a-quick-optimization-advice-7353b820c92e


That is why I prefer that basics, including numbers, are implemented by
experts.

I have no use for bigit and decimal numbers yet.
But should I need them I do not want to implement them myself or wait until
someone else might do the work and with uncertain quality.

Post by Gen
1) Introduce number types or numeric types like in Go.

I like the idea of introducing these as type *annotations* so that users
can express size expectations for Dart implementations where that's
meaningful.
I'm less clear on what that should say about the semantics of variables
annotated with that type. Having it actually affect the arithmetic behavior
(overflow) would go against Dart's fundamental property that type
annotations do not affect runtime behavior.
I think it opens up some questions about size-annotated number literals
too, like 123ul in C. Those could be useful for bottom-up type inference.
I've thought about writing this up as a proposal but I don't know if it
will just open a giant unproductive can of worms. I was planning to sit on
it until we have a platform team really asking for it.
These types tell the programmer what kind of number is required and

Post by Gen
expected.
Numbers might be used in a more efficient and familiar way for people
coming from typed languages.
No need to hide a Uint8List as List<int> in dart:io.
AFAIK, the []= operation even truncates the bound number without notice
in the documentation. This is bad documentation and API design, IMHO.
No need to import "dart:typed_data" for basic use of numbers.
2) Implement the "int" type as arbitrary size integer even when compiled
to Javascript or any other language or platform.

-1.
The default "int" type should be large *and fast* enough for most uses.
Bigints are more than large enough but not fast enough. 32-bit ints get you
surprisingly far.
If you do need something bigger than that, you probably also have other
numeric requirements: units of measure, currency, banker's rounding,
rationals, etc. If you care enough about numerics that you need
arbitrary-precision, I don't think any one-size-fits-all number type in the
language will be good enough. We have operator overloading. Use a bignum
library that does *exactly* what you need.
– bob

['Bob Nystrom' via Dart Misc]

Post by Gen
That is why I prefer that basics, including numbers, are implemented by
experts.

I agree totally, it's just that a language team may not *be* the right
experts. We do coincidentally have a couple of people with expertise on
bigints, but as far as I know, we don't have any expertise on using numbers
for financial calculations or dealing with units of measure.

– bob

[Brian Slesinsky]

Perhaps Go-style typedefs would be a useful compromise. Suppose you could
do this:

typedef meters num;
typedef seconds num;

Then mixing meters and seconds results in a warning, but they're just
treated as numbers underneath.

If you have that then you could also say:

typedef int32 int;

This is weird since it doesn't actually put constraints on what's stored
there, but it's good documentation when you're working with foreign types,
and fits in well with Dart's philosophy about type annotations.

Even better would be a way to associate an assertion with each typedef
that's automatically applied to parameters of that type when in checked
mode. That seems pretty consistent with the Dart philosophy too, since it's
just extending how checked mode works anyway.

The goal, then, is to do occasional checks that you're passing and/or
storing values in the right range, not to pervasively change how arithmetic
operations happen.

- Brian

Post by 'Bob Nystrom' via Dart Misc

Post by Gen
That is why I prefer that basics, including numbers, are implemented by
experts.

I agree totally, it's just that a language team may not *be* the right
experts. We do coincidentally have a couple of people with expertise on
bigints, but as far as I know, we don't have any expertise on using numbers
for financial calculations or dealing with units of measure.
– bob

[Günter Zöchbauer]

+1

Post by Brian Slesinsky
typedef meters num;
typedef seconds num;
Then mixing meters and seconds results in a warning, but they're just treated as numbers underneath.
typedef int32 int;
This is weird since it doesn't actually put constraints on what's stored there, but it's good documentation when you're working with foreign types, and fits in well with Dart's philosophy about type annotations.
Even better would be a way to associate an assertion with each typedef that's automatically applied to parameters of that type when in checked mode. That seems pretty consistent with the Dart philosophy too, since it's just extending how checked mode works anyway.
The goal, then, is to do occasional checks that you're passing and/or storing values in the right range, not to pervasively change how arithmetic operations happen.
- Brian
That is why I prefer that basics, including numbers, are implemented by experts.
I agree totally, it's just that a language team may not be the right experts. We do coincidentally have a couple of people with expertise on bigints, but as far as I know, we don't have any expertise on using numbers for financial calculations or dealing with units of measure.
– bob

[Gen]

+1

Post by Brian Slesinsky
Perhaps Go-style typedefs would be a useful compromise. Suppose you could
typedef meters num;
typedef seconds num;
Then mixing meters and seconds results in a warning, but they're just
treated as numbers underneath.
typedef int32 int;
This is weird since it doesn't actually put constraints on what's stored
there, but it's good documentation when you're working with foreign types,
and fits in well with Dart's philosophy about type annotations.
Even better would be a way to associate an assertion with each typedef
that's automatically applied to parameters of that type when in checked
mode. That seems pretty consistent with the Dart philosophy too, since it's
just extending how checked mode works anyway.
The goal, then, is to do occasional checks that you're passing and/or
storing values in the right range, not to pervasively change how arithmetic
operations happen.
- Brian

Post by 'Bob Nystrom' via Dart Misc

Post by Gen
That is why I prefer that basics, including numbers, are implemented by
experts.

I agree totally, it's just that a language team may not *be* the right
experts. We do coincidentally have a couple of people with expertise on
bigints, but as far as I know, we don't have any expertise on using numbers
for financial calculations or dealing with units of measure.
– bob

[Filipe Morgado]

+1 for typedefs

[Patrice Chalin]

+1. In fact, typedefs (potentially with associated runtime checking) is
also something I brought up last month in this Dev Core post
<https://groups.google.com/a/dartlang.org/d/msg/core-dev/ZdEBRgxLb70/a-s-iS6JAAAJ>;

As soon as you have that I'm sure you can use it to provide a very well
performing `int` etc.,

Well, we've had consistent, well-understood semantics for Dart for a long
time now, and we still don't have great performance around numbers on all
of the implementations. Still waiting on that Sufficiently Smart Compiler™.
:(

Compiler optimizations are easier to design when given appropriate
developer guidance --- e.g., non-null types help the compiler know when a
developer *intends* a type to be non-null. I think that we have the right
basis for a workable approach: keep the base int type as arbitrary
precision and then let developers provide guidance to the compiler, *as
needed*, via subrange types that are *application specific*: e.g., (let
me just invented some notation)
typedef [1..12] Month;
Most consistent with the current Dart philosophy would be to treat Month
as an int with extra runtime checks in checked mode. A compiler can then do
a much better job at figuring out how to optimally represent a Month.

Cf. Ada which has a base "universal integer" type that effectively
corresponds to the mathematical integers. Every programatic integer type is
a "subtype" of the universal integers (with either standard or modulo
arithmetic).

FYI, examples of Ada range types:

*type* Column *is range* 1 .. 72;
*subtype* Small_Int *is* Integer *range* -10 .. 10;
*subtype* Up_To_K *is* Column *range* 1 .. K;

And examples of (the more expressive Ada 2012 <http://www.ada2012.org>) subtype
predicates feature
<http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html> (both static
and dynamic variants):


*subtype* Even *is* Integer
*with* Dynamic_Predicate => Even *mod* 2 = 0;
*subtype* Winter *is* Month
*with* Static_Predicate => Winter *in* Dec | Jan | Feb;


In addition to its niche of (safety and security critical) embedded
systems, it seems that Ada is making forays into:

- *IoT*: AdaCore Introduces GNAT GPL 2015 for the Raspberry Pi 2
<http://www.adacore.com/press/adacore-introduces-gnat-gpl-2015-for-the-raspberry-pi-2/>
.
- Space :). Ada running in a CubeSat
<http://www.adacore.com/press/cubesat> (launched in 2013), and a Lunar
IceCube satellite <http://www.adacore.com/press/spark-going-to-the-moon/>
has a planned launch for 2018.

Pretty cool.

Cheers,
Patrice

p.s. For those interested, here <http://www.ada2012.org/comparison.html> is
a compact summary of Ada language features up to and including the Ada 2012
standard.

Perhaps Go-style typedefs would be a useful compromise. Suppose you could
typedef meters num;
typedef seconds num;
Then mixing meters and seconds results in a warning, but they're just
treated as numbers underneath.
typedef int32 int;
This is weird since it doesn't actually put constraints on what's stored
there, but it's good documentation when you're working with foreign types,
and fits in well with Dart's philosophy about type annotations.
Even better would be a way to associate an assertion with each typedef
that's automatically applied to parameters of that type when in checked
mode. That seems pretty consistent with the Dart philosophy too, since it's
just extending how checked mode works anyway.
The goal, then, is to do occasional checks that you're passing and/or
storing values in the right range, not to pervasively change how arithmetic
operations happen.
- Brian

That is why I prefer that basics, including numbers, are implemented by
experts.

I agree totally, it's just that a language team may not *be* the right
experts. We do coincidentally have a couple of people with expertise on
bigints, but as far as I know, we don't have any expertise on using numbers
for financial calculations or dealing with units of measure.
– bob

[David Morgan ☯]

If we go in that direction it's not a huge stretch to talk about contract
programming.

https://github.com/dart-lang/sdk/issues/3049

Many years ago I was involved in a library for contract programming in
Java: https://github.com/nhatminhle/cofoja

The idea is foremost around powerful runtime checks that can be turned on
for development and disabled for production. Of course one you have
contracts they open up lots of fun avenues for optimization and static
checking.

Post by Patrice Chalin
+1. In fact, typedefs (potentially with associated runtime checking) is
also something I brought up last month in this Dev Core post
<https://groups.google.com/a/dartlang.org/d/msg/core-dev/ZdEBRgxLb70/a-s-iS6JAAAJ>;

As soon as you have that I'm sure you can use it to provide a very well
performing `int` etc.,

Well, we've had consistent, well-understood semantics for Dart for a
long time now, and we still don't have great performance around numbers on
all of the implementations. Still waiting on that Sufficiently Smart
Compiler™. :(

Compiler optimizations are easier to design when given appropriate
developer guidance --- e.g., non-null types help the compiler know when a
developer *intends* a type to be non-null. I think that we have the
right basis for a workable approach: keep the base int type as arbitrary
precision and then let developers provide guidance to the compiler, *as
needed*, via subrange types that are *application specific*: e.g., (let
me just invented some notation)
typedef [1..12] Month;
Most consistent with the current Dart philosophy would be to treat Month
as an int with extra runtime checks in checked mode. A compiler can then do
a much better job at figuring out how to optimally represent a Month.

Cf. Ada which has a base "universal integer" type that effectively
corresponds to the mathematical integers. Every programatic integer type is
a "subtype" of the universal integers (with either standard or modulo
arithmetic).
*type* Column *is range* 1 .. 72;
*subtype* Small_Int *is* Integer *range* -10 .. 10;
*subtype* Up_To_K *is* Column *range* 1 .. K;
And examples of (the more expressive Ada 2012 <http://www.ada2012.org>) subtype
predicates feature
<http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html> (both
*subtype* Even *is* Integer
*with* Dynamic_Predicate => Even *mod* 2 = 0;
*subtype* Winter *is* Month
*with* Static_Predicate => Winter *in* Dec | Jan | Feb;
In addition to its niche of (safety and security critical) embedded
- *IoT*: AdaCore Introduces GNAT GPL 2015 for the Raspberry Pi 2
<http://www.adacore.com/press/adacore-introduces-gnat-gpl-2015-for-the-raspberry-pi-2/>
.
- Space :). Ada running in a CubeSat
<http://www.adacore.com/press/cubesat> (launched in 2013), and a Lunar
IceCube satellite
<http://www.adacore.com/press/spark-going-to-the-moon/> has a planned
launch for 2018.
Pretty cool.
Cheers,
Patrice
p.s. For those interested, here <http://www.ada2012.org/comparison.html>
is a compact summary of Ada language features up to and including the Ada
2012 standard.

Perhaps Go-style typedefs would be a useful compromise. Suppose you could
typedef meters num;
typedef seconds num;
Then mixing meters and seconds results in a warning, but they're just
treated as numbers underneath.
typedef int32 int;
This is weird since it doesn't actually put constraints on what's stored
there, but it's good documentation when you're working with foreign types,
and fits in well with Dart's philosophy about type annotations.
Even better would be a way to associate an assertion with each typedef
that's automatically applied to parameters of that type when in checked
mode. That seems pretty consistent with the Dart philosophy too, since it's
just extending how checked mode works anyway.
The goal, then, is to do occasional checks that you're passing and/or
storing values in the right range, not to pervasively change how arithmetic
operations happen.
- Brian

That is why I prefer that basics, including numbers, are implemented by
experts.

I agree totally, it's just that a language team may not *be* the right
experts. We do coincidentally have a couple of people with expertise on
bigints, but as far as I know, we don't have any expertise on using numbers
for financial calculations or dealing with units of measure.
– bob

[Günter Zöchbauer]

You won't give up? ;-)
https://groups.google.com/a/dartlang.org/d/msg/misc/NvhIGdYNn2g/zK7sQgKMU0sJ

+1 I'd like that a lot as well

Post by David Morgan ☯
If we go in that direction it's not a huge stretch to talk about contract
programming.
https://github.com/dart-lang/sdk/issues/3049
Many years ago I was involved in a library for contract programming in
Java: https://github.com/nhatminhle/cofoja
The idea is foremost around powerful runtime checks that can be turned on
for development and disabled for production. Of course one you have
contracts they open up lots of fun avenues for optimization and static
checking.

Post by Patrice Chalin
+1. In fact, typedefs (potentially with associated runtime checking) is
also something I brought up last month in this Dev Core post
<https://groups.google.com/a/dartlang.org/d/msg/core-dev/ZdEBRgxLb70/a-s-iS6JAAAJ>;

As soon as you have that I'm sure you can use it to provide a very
well performing `int` etc.,

Well, we've had consistent, well-understood semantics for Dart for a
long time now, and we still don't have great performance around numbers on
all of the implementations. Still waiting on that Sufficiently Smart
Compiler™. :(

Compiler optimizations are easier to design when given appropriate
developer guidance --- e.g., non-null types help the compiler know when a
developer *intends* a type to be non-null. I think that we have the
right basis for a workable approach: keep the base int type as arbitrary
precision and then let developers provide guidance to the compiler, *as
needed*, via subrange types that are *application specific*: e.g., (let
me just invented some notation)
typedef [1..12] Month;
Most consistent with the current Dart philosophy would be to treat Month
as an int with extra runtime checks in checked mode. A compiler can then do
a much better job at figuring out how to optimally represent a Month.

Cf. Ada which has a base "universal integer" type that effectively
corresponds to the mathematical integers. Every programatic integer type is
a "subtype" of the universal integers (with either standard or modulo
arithmetic).
*type* Column *is range* 1 .. 72;
*subtype* Small_Int *is* Integer *range* -10 .. 10;
*subtype* Up_To_K *is* Column *range* 1 .. K;
And examples of (the more expressive Ada 2012 <http://www.ada2012.org>) subtype
predicates feature
<http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html> (both
*subtype* Even *is* Integer
*with* Dynamic_Predicate => Even *mod* 2 = 0;
*subtype* Winter *is* Month
*with* Static_Predicate => Winter *in* Dec | Jan | Feb;
In addition to its niche of (safety and security critical) embedded
- *IoT*: AdaCore Introduces GNAT GPL 2015 for the Raspberry Pi 2
<http://www.adacore.com/press/adacore-introduces-gnat-gpl-2015-for-the-raspberry-pi-2/>
.
- Space :). Ada running in a CubeSat
<http://www.adacore.com/press/cubesat> (launched in 2013), and a Lunar
IceCube satellite
<http://www.adacore.com/press/spark-going-to-the-moon/> has a planned
launch for 2018.
Pretty cool.
Cheers,
Patrice
p.s. For those interested, here <http://www.ada2012.org/comparison.html>
is a compact summary of Ada language features up to and including the Ada
2012 standard.

Perhaps Go-style typedefs would be a useful compromise. Suppose you
typedef meters num;
typedef seconds num;
Then mixing meters and seconds results in a warning, but they're just
treated as numbers underneath.
typedef int32 int;
This is weird since it doesn't actually put constraints on what's stored
there, but it's good documentation when you're working with foreign types,
and fits in well with Dart's philosophy about type annotations.
Even better would be a way to associate an assertion with each typedef
that's automatically applied to parameters of that type when in checked
mode. That seems pretty consistent with the Dart philosophy too, since it's
just extending how checked mode works anyway.
The goal, then, is to do occasional checks that you're passing and/or
storing values in the right range, not to pervasively change how arithmetic
operations happen.
- Brian

That is why I prefer that basics, including numbers, are implemented
by experts.

I agree totally, it's just that a language team may not *be* the right
experts. We do coincidentally have a couple of people with expertise on
bigints, but as far as I know, we don't have any expertise on using numbers
for financial calculations or dealing with units of measure.
– bob

['David "Morgan" Morgan' via Dart Misc]

Indeed, I will continue to mention contract programming at every
opportunity ;)

I believe, but have not yet had a chance to prove, that it's a good match
for UI code. UI code tends to be about interaction between loosly coupled
pieces, it's often hard to write meaningful small tests. Contract
programming gives you detailed checks that get exercised during your large
tests, providing similar coverage at a lower cost.

That's the dream ;)

Post by Günter Zöchbauer
You won't give up? ;-)
https://groups.google.com/a/dartlang.org/d/msg/misc/NvhIGdYNn2g/zK7sQgKMU0sJ
+1 I'd like that a lot as well

Post by David Morgan ☯
If we go in that direction it's not a huge stretch to talk about contract
programming.
https://github.com/dart-lang/sdk/issues/3049
Many years ago I was involved in a library for contract programming in
Java: https://github.com/nhatminhle/cofoja
The idea is foremost around powerful runtime checks that can be turned on
for development and disabled for production. Of course one you have
contracts they open up lots of fun avenues for optimization and static
checking.

Post by Patrice Chalin
+1. In fact, typedefs (potentially with associated runtime checking) is
also something I brought up last month in this Dev Core post
<https://groups.google.com/a/dartlang.org/d/msg/core-dev/ZdEBRgxLb70/a-s-iS6JAAAJ>;

As soon as you have that I'm sure you can use it to provide a very
well performing `int` etc.,

Well, we've had consistent, well-understood semantics for Dart for a
long time now, and we still don't have great performance around numbers on
all of the implementations. Still waiting on that Sufficiently Smart
Compiler™. :(

Compiler optimizations are easier to design when given appropriate
developer guidance --- e.g., non-null types help the compiler know when a
developer *intends* a type to be non-null. I think that we have the
right basis for a workable approach: keep the base int type as arbitrary
precision and then let developers provide guidance to the compiler, *as
needed*, via subrange types that are *application specific*: e.g.,
(let me just invented some notation)
typedef [1..12] Month;
Most consistent with the current Dart philosophy would be to treat
Month as an int with extra runtime checks in checked mode. A compiler can
then do a much better job at figuring out how to optimally represent a
Month.

Cf. Ada which has a base "universal integer" type that effectively
corresponds to the mathematical integers. Every programatic integer type is
a "subtype" of the universal integers (with either standard or modulo
arithmetic).
*type* Column *is range* 1 .. 72;
*subtype* Small_Int *is* Integer *range* -10 .. 10;
*subtype* Up_To_K *is* Column *range* 1 .. K;
And examples of (the more expressive Ada 2012 <http://www.ada2012.org>) subtype
predicates feature
<http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html> (both
*subtype* Even *is* Integer
*with* Dynamic_Predicate => Even *mod* 2 = 0;
*subtype* Winter *is* Month
*with* Static_Predicate => Winter *in* Dec | Jan | Feb;
In addition to its niche of (safety and security critical) embedded
- *IoT*: AdaCore Introduces GNAT GPL 2015 for the Raspberry Pi 2
<http://www.adacore.com/press/adacore-introduces-gnat-gpl-2015-for-the-raspberry-pi-2/>
.
- Space :). Ada running in a CubeSat
<http://www.adacore.com/press/cubesat> (launched in 2013), and a Lunar
IceCube satellite
<http://www.adacore.com/press/spark-going-to-the-moon/> has a
planned launch for 2018.
Pretty cool.
Cheers,
Patrice
p.s. For those interested, here <http://www.ada2012.org/comparison.html>
is a compact summary of Ada language features up to and including the Ada
2012 standard.

Perhaps Go-style typedefs would be a useful compromise. Suppose you
typedef meters num;
typedef seconds num;
Then mixing meters and seconds results in a warning, but they're just
treated as numbers underneath.
typedef int32 int;
This is weird since it doesn't actually put constraints on what's
stored there, but it's good documentation when you're working with foreign
types, and fits in well with Dart's philosophy about type annotations.
Even better would be a way to associate an assertion with each typedef
that's automatically applied to parameters of that type when in checked
mode. That seems pretty consistent with the Dart philosophy too, since it's
just extending how checked mode works anyway.
The goal, then, is to do occasional checks that you're passing and/or
storing values in the right range, not to pervasively change how arithmetic
operations happen.
- Brian

That is why I prefer that basics, including numbers, are implemented
by experts.

I agree totally, it's just that a language team may not *be* the
right experts. We do coincidentally have a couple of people with expertise
on bigints, but as far as I know, we don't have any expertise on using
numbers for financial calculations or dealing with units of measure.
– bob
--

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

[George Moschovitis]

Post by Brian Slesinsky
Perhaps Go-style typedefs would be a useful compromise. Suppose you could
typedef meters num;
typedef seconds num;

YES!
+1

[Daniel Joyce]

What's the type of meters time seconds? ;)

Or meters times meters. ;)

Terrible idea to use them this way.

Post by Brian Slesinsky
Perhaps Go-style typedefs would be a useful compromise. Suppose you could

Post by Brian Slesinsky
typedef meters num;
typedef seconds num;

YES!
+1
--
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

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[tatumizer-v0.2]

+Megaparsec
Let's add units of measurement, write a Mars Lander and fly away from this
inhospitable planet!
BTW, meters^2 is a solved problem:
http://www.dmitry-kazakov.de/ada/units.htm

The meek shall inherit the Earth, for the brave will be among the stars!

[tatumizer-v0.2]

Just in case: it was a joke.

[Günter Zöchbauer]

Post by Daniel Joyce
What's the type of meters time seconds? ;)
Or meters times meters. ;)

This should require an explicit cast, either for one of the factors or the result.

Post by Daniel Joyce
Terrible idea to use them this way.
typedef meters num;
typedef seconds num;
YES!
+1
--
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
--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.

[Rob Bishop]

https://pub.dartlang.org/packages/quantity

You're welcome.

Post by Günter Zöchbauer

Post by Daniel Joyce
What's the type of meters time seconds? ;)
Or meters times meters. ;)

This should require an explicit cast, either for one of the factors or the result.

Post by Daniel Joyce
Terrible idea to use them this way.
Perhaps Go-style typedefs would be a useful compromise. Suppose you
typedef meters num;
typedef seconds num;
YES!
+1
--
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

Post by Daniel Joyce
To unsubscribe from this group and stop receiving emails from it, send
--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.