Dart on JVM

[Rémi Forax]

I'm please to announce that Dart (a small subset in fact) run on the JVM.
https://code.google.com/p/jdart

I've implemented new, constructor call (super/this), function call,
method call, assignation, return, print and
boolean, integer, double and String constants.
So helloword works !

to run it:
java -jar jdartc.jar foo.dart
generates a jar file foo.jar that can be run like this:
java -jar foo.jar

I will be please to give the commiter role to anyone that want to contribute
(don't forget that my brother is a psychopath).

R�mi
PS: jdart.jar is very big 7 megs because it also contains the Dart to JS
compiler,
I haven't taken the time to separate it from the Dart frontend.

[Gilad Bracha]

Impressive.  I assume invokedynamic came in handy?

On Mon, Oct 17, 2011 at 1:44 PM, Rémi Forax <fo...@univ-mlv.fr> wrote:

I'm please to announce that Dart (a small subset in fact) run on the JVM.
 https://code.google.com/p/jdart

I've implemented new, constructor call (super/this), function call,
method call, assignation, return, print and
boolean, integer, double and String constants.
So helloword works !

to run it:
 java -jar jdartc.jar foo.dart
generates a jar file foo.jar that can be run like this:
 java -jar foo.jar

I will be please to give the commiter role to anyone that want to contribute
(don't forget that my brother is a psychopath).

Rémi

PS: jdart.jar is very big 7 megs because it also contains the Dart to JS compiler,
 I haven't taken the time to separate it from the Dart frontend.

--
Cheers, Gilad

[Rémi Forax]

On 10/17/2011 11:04 PM, Gilad Bracha wrote:

Impressive.  I assume invokedynamic came in handy?

I've posted two examples of the bytecode generated on the site.
Yes, half of the generated instructions are invokedynamic :)

Rémi

[Chanwit Kaewkasi]

You're fast, Remi !

Cheers,

Chanwit

On Tue, Oct 18, 2011 at 03:44, Rémi Forax <fo...@univ-mlv.fr> wrote:
> I'm please to announce that Dart (a small subset in fact) run on the JVM.
>  https://code.google.com/p/jdart
>
> I've implemented new, constructor call (super/this), function call,
> method call, assignation, return, print and
> boolean, integer, double and String constants.
> So helloword works !
>
> to run it:
>  java -jar jdartc.jar foo.dart
> generates a jar file foo.jar that can be run like this:
>  java -jar foo.jar
>
> I will be please to give the commiter role to anyone that want to contribute
> (don't forget that my brother is a psychopath).
>

> Rémi

[arul]

You rock in Dart world too! Can't wait to try this out on the JVM.

On Mon, Oct 17, 2011 at 2:44 PM, Rémi Forax <fo...@univ-mlv.fr> wrote:

I'm please to announce that Dart (a small subset in fact) run on the JVM.
 https://code.google.com/p/jdart

I've implemented new, constructor call (super/this), function call,
method call, assignation, return, print and
boolean, integer, double and String constants.
So helloword works !

to run it:
 java -jar jdartc.jar foo.dart
generates a jar file foo.jar that can be run like this:
 java -jar foo.jar

I will be please to give the commiter role to anyone that want to contribute
(don't forget that my brother is a psychopath).

Rémi

PS: jdart.jar is very big 7 megs because it also contains the Dart to JS compiler,
 I haven't taken the time to separate it from the Dart frontend.

--

Arul

http://expertstalk.org

@dartdeveloper

[Charles Oliver Nutter]

I knew it wouldn't take long :) Over the weekend perhaps?

Awesome work Remi...maybe more people will start to realize what power we have in invokedynamic.

-  Charlie (mobile)

On Oct 17, 2011 3:43 PM, "Rémi Forax" <fo...@univ-mlv.fr> wrote:

I'm please to announce that Dart (a small subset in fact) run on the JVM.
 https://code.google.com/p/jdart

I've implemented new, constructor call (super/this), function call,
method call, assignation, return, print and
boolean, integer, double and String constants.
So helloword works !

to run it:
 java -jar jdartc.jar foo.dart
generates a jar file foo.jar that can be run like this:
 java -jar foo.jar

I will be please to give the commiter role to anyone that want to contribute
(don't forget that my brother is a psychopath).

Rémi

PS: jdart.jar is very big 7 megs because it also contains the Dart to JS compiler,
 I haven't taken the time to separate it from the Dart frontend.

--
You received this message because you are subscribed to the Google Groups "JVM Languages" group.
To post to this group, send email to jvm-la...@googlegroups.com.
To unsubscribe from this group, send email to jvm-languages+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.

[Rémi Forax]

On 10/18/2011 10:11 AM, Charles Oliver Nutter wrote:
>
> I knew it wouldn't take long :) Over the weekend perhaps?
>

Friday night and Sunday night indeed.

> Awesome work Remi...maybe more people will start to realize what power
> we have in invokedynamic.
>

shh, I prefer to think I'm awesome :)
invokedynamic() => merge(swiss_knife, ligth_saber);

> - Charlie (mobile)
>

R�mi

[James Abley]

Rémi

--
You received this message because you are subscribed to the Google Groups "JVM Languages" group.
To post to this group, send email to jvm-la...@googlegroups.com.
To unsubscribe from this group, send email to jvm-languages+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.

Rémi,

I like your nullable choice. Are you planning to take that discussion forward?

Cheers,

James

[Rémi Forax]

[...]

Rémi,

I like your nullable choice. Are you planning to take that discussion forward?

Cheers,

James

Better to answer latter than never :)

I think that int and double should be not nullable by default
just because the JIT can emit a simple iadd/dadd in case where you know
that both arguments are int/double.
It's important in my opinion because a fully typed Dart application
should be as fast as if it was written in Java.

For the same reason, I really think it's a bad idea(tm) to let the integer
to overflow to some kind of bigint like python or ruby does.
In practice, it never appears (JRuby guys has done some stats showing that
it only happens in their regression tests :) but you add a runtime cost for each operations.

Rémi

[Ladislav Thon]

For the same reason, I really think it's a bad idea(tm) to let the integer
to overflow to some kind of bigint like python or ruby does.

I've always been a fan of Groovy's math (http://groovy.codehaus.org/Groovy+Math). Native numeric types are fast, yes, but should implementation ease drive the language? Are you going to use Dart (or Ruby, Python, Groovy etc.) for heavily numeric algorithms (simulations)? Probably not.

Now thinking about it a little more... you ARE probably going to use Dart for in-browser games, so I see the case for native types (well, double only, because of compilation to JavaScript). But I'd still love Dart to have not only "real integers", but also "real decimals". Native types should be available, but default numeric types should be sane.

And by sane, I of course mean that

main() {

  print(0.1 + 0.1 == 0.2);

  print(0.1 + 0.1 + 0.1 == 0.3);

}

really should NOT result in

true

false

And yes, I've heard about IEEE's double, but I still hate it for most of the time I spend programming.

LT

P.S.: well, we have real integers, so we can do fixed-point arithmetics in library... probably worth implementing!

[Rémi Forax]

Ladislav,
as you said, I really expect to see games in the browser written in Dart.
And I also want to use for-loop what works well if the loop variable is declared int :)

To answer to your question, "should implementation ease drive the language ?",
I think that for Dart the answer is yes, beacuse if Dart is not faster that JS, there is no point to use Dart.

The current incarnations of the scripting languages are slow,
we know that a lot of developers will never use them at work just because they are slow.
What is the point to create another slow dynamic language in 2011 ?

That said, I'm a big fan of Ioke.

Rémi

[Ladislav Thon]

To answer to your question, "should implementation ease drive the language ?",

I think that for Dart the answer is yes, beacuse if Dart is not faster that JS, there is no point to use Dart.

Well, I know that there are already some performance-driven desicions in Dart, but...

 

The current incarnations of the scripting languages are slow,
we know that a lot of developers will never use them at work just because they are slow.

... while I completely agree with this, are you really going to get significant speedup just because of native integers? I bet this exact question was raised on Dart team internally like a bazillion times before the language went public, and the answer is obvious. I think that there are other performance boosts in Dart already -- for example, classes are closed, which is probably great for method invocations (you don't need to look them up by name), and _that_ is a huge factor. (Hmm... V8 has these hidden classes exactly for this, right? At least you don't have to rebuild them...) But I'm just guessing here (I have very little to none experience with implementing languages), you obviously know better.

LT

[Hank G.]

This is great. I was afraid I'd have to spend all that time compiling
and building Chromium just so I can start playing with Dart. This,
embedded in Eclipse perhaps, is exactly what I was looking for! You
guys looking for contributors to your project?

[Florian Loitsch]

On Fri, Oct 21, 2011 at 09:09, Rémi Forax <fo...@univ-mlv.fr> wrote:

[...]

Rémi,

I like your nullable choice. Are you planning to take that discussion forward?

Cheers,

James

Better to answer latter than never :)

I think that int and double should be not nullable by default

It just falls apart when you use generics.

class A<T> {

  T x = null;

  ...

}

If T is a number type your class would not work. With all other types it works.

The biggest example is List. new List<int>(10) would be illegal, since a new List<int> initializes its elements with 'null'.

There is currently no way to specialize a generic class depending on its generic type. So specializing List<T> (or any other class) for specific Ts is not possible (and I don't see this change in the near future).

// florian

just because the JIT can emit a simple iadd/dadd in case where you know
that both arguments are int/double.
It's important in my opinion because a fully typed Dart application
should be as fast as if it was written in Java.

For the same reason, I really think it's a bad idea(tm) to let the integer
to overflow to some kind of bigint like python or ruby does.
In practice, it never appears (JRuby guys has done some stats showing that
it only happens in their regression tests :) but you add a runtime cost for each operations. 

Rémi

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[John Tamplin]

On Fri, Oct 21, 2011 at 4:54 PM, Florian Loitsch <floi...@google.com> wrote:

It just falls apart when you use generics.

class A<T> {

  T x = null;

  ...

}

If T is a number type your class would not work. With all other types it works.

I don't believe this is correct -- I believe you could have generics that define whether the type parameter must be nullable, must not be nullable, or don't care, plus you can override the default.  This was mentioned in the other thread.

For example:

class A<T?> {

  T x = null;

}

would require that T be nullable, so A<int> would be a type error.

class A<T> {

  T? x = null;

}

would declare x of the nullable version of T, regardless of whether T was nullable or not.  Nullability is just a runtime type check like any other type annotation.

 

The biggest example is List. new List<int>(10) would be illegal, since a new List<int> initializes its elements with 'null'.

As nullability is just a type annotation (that can cause compilers to produce different output), this would throw an exception with --enable_type_checks, but otherwise work as expected.  You could also require that T is nullable, or the values within List could be declared as T? and accept nulls.

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

[Rémi Forax]

I agree with John, nullable is just a runtime typecheck.

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

Rémi

[Peter Ahé]

I'm not sure I understand how you plan to generate JVM byte codes in
jdart. How would the byte codes for this look:

int add(int i, int j) => i + j;

Cheers,
Peter

[Rémi Forax]

I suppose add is a lambda and sorry by advance, it will be a little
technical :)
A lambda is represented at runtime by a java.lang.invoke.MethodHandle,
when a lambda is created, I use invokedynamic to intern it
if it's possible (if it doesn't capture scope variables).
The lambda is desugared as a static method that will
be loaded by the runtime (using MethodHandles.Lookup.findStatic())
when invokedynamic loadConst is called
(you can specify bytecode constants as parameters of the bootstrap method
of invokedynamic, I also plan to use the same mechanism for const object).

static int $lambda1(int i, int j) {
iload 0
iload 1
iadd
ireturn
}
...
invokedynamic loadConst() Ljava/lang/invoke/MethodHandle; [$lambda(int,int)]
astore add // with add the slot of add

and when a lambda is call, I use invokedynamic to do the runtime
signature adaptation
(so specific for a callsite) and delegate to MethodHandle.invokeExact
after the adaptation
so var foo = add(2, 2.3) is compiled to something like this:

aload add
iconst_2
ldc 2.3
invokedynamic lambdaCall (ID)Ljava/lang/Object;
astore foo

>
> Cheers,
> Peter

cheers,
Rémi

[Peter Ahé]

Well, it could just as well be top-level method. My example above is a
complete Dart program (except there is no main method).

> A lambda is represented at runtime by a java.lang.invoke.MethodHandle,
> when a lambda is created, I use invokedynamic to intern it
> if it's possible (if it doesn't capture scope variables).
> The lambda is desugared as a static method that will
> be loaded by the runtime (using MethodHandles.Lookup.findStatic())
> when invokedynamic loadConst is called
> (you can specify bytecode constants as parameters of the bootstrap method
> of invokedynamic, I also plan to use the same mechanism for const object).
>
> static int $lambda1(int i, int j) {
>  iload 0
>  iload 1
>  iadd
>  ireturn
> }
> ...

That is what I thought you are doing. Now, what happens if I write:

main() {
print(add(3, 4));
print(add("3", "4"));
print(add(null, 4));
}

For reference, here is what should happen: http://try.dartlang.org/s/tvAc

Cheers,
Peter

[Rémi Forax]

add(3, 4) -> 7 // ok

add("3", "4") -> WrongMethodTypeException
because the compiler find that add is add(String, String) and
there is no conversion between String and int.
This exception should be mapped to TypeError.

add(null, 4) -> WrongMethodTypeException
because null is represened by a special type, here the compiler
find that add is add(type of null, int) and there is no conversion
between type of null and int.

var v = null;
add(v, 3) -> NPE
because add is typed add(Object, int), there is a conversion
from Object to int (Object -> Integer -> int) and during Integer -> int,
intValue is called on null.
Also this error should be mapped to TypeError

> Cheers,
> Peter

cheers,
Rémi

[Peter Ahé]

Not if you're implementing the Dart programming language.

> add(null, 4) ->  WrongMethodTypeException
> because null is represened by a special type, here the compiler
> find that add is add(type of null, int) and there is no conversion
> between type of null and int.
>
> var v = null;
> add(v, 3) -> NPE
> because add is typed add(Object, int), there is a conversion
> from Object to int (Object -> Integer -> int) and during Integer -> int,
> intValue is called on null.
> Also this error should be mapped to TypeError

Not in the Dart programming language.

Cheers,
Peter

>
>> Cheers,
>> Peter
>
> cheers,
> Rémi
>
>

[Rémi Forax]

On 10/21/2011 08:40 PM, Hank G. wrote:
> This is great. I was afraid I'd have to spend all that time compiling
> and building Chromium just so I can start playing with Dart. This,
> embedded in Eclipse perhaps, is exactly what I was looking for! You
> guys looking for contributors to your project?

yes, I look for contributors.
and yes being able to run the jdart from Eclipse is a nice idea.
In fact, jdart is just another backend of the dart-to-JavaScript compiler,
it reuse the same frontend and just add one pass to convert Dart type to
Java one
and a bytecode generator powered by ASM.
So I don't expect the integration to the already existing eclipse Dart
plugin to be hard.

I will add this to the TODO list to the project.

If anyone is interested to contribute to jdart, just send me an email
with your google id, and I will add you as commiter.

R�mi

[Rémi Forax]

Correct me if I'm wrong, it does depend on the execution mode.
My plan is just to add the developer mode because I strongly believe
that the runtime cost of the check is not awful. I may be wrong.

> add(null, 4) -> WrongMethodTypeException
> because null is represened by a special type, here the compiler
> find that add is add(type of null, int) and there is no conversion
> between type of null and int.
>
> var v = null;
> add(v, 3) -> NPE
> because add is typed add(Object, int), there is a conversion
> from Object to int (Object -> Integer -> int) and during Integer -> int,
> intValue is called on null.
> Also this error should be mapped to TypeError
> Not in the Dart programming language.

What should be the result in developer mode ?

>
> Cheers,
> Peter

cheers,
Rémi

[Gilad Bracha]

Remi,

As you can clearly see from Peter's example, you aren't implementing Dart. 

Even in checked mode the behavior you describe does not match the spec.  One should not be thinking in terms of a traditional mandatory typed language like Java.

On Sat, Oct 22, 2011 at 5:29 AM, Rémi Forax <fo...@univ-mlv.fr> wrote:

On 10/22/2011 01:17 PM, Peter Ahé wrote:

On Sat, Oct 22, 2011 at 13:06, Rémi Forax<fo...@univ-mlv.fr>  wrote:

On 10/22/2011 12:38 PM, Peter Ahé wrote:

 what happens if I write:

main() {
  print(add(3, 4));
  print(add("3", "4"));
  print(add(null, 4));
}

For reference, here is what should happen: http://try.dartlang.org/s/tvAc

add(3, 4)  -> 7                       // ok

add("3", "4") -> WrongMethodTypeException

34. Type annotations don't change behavior except in checked mode. You need to support both checked mode and production mode.  In checked mode, ths would lead to a dynamic type error (though not for the reasons you describe).

 

because the compiler find that add is add(String, String) and
there is no conversion between String and int.
This exception should be mapped to TypeError.

add(null, 4) ->  WrongMethodTypeException

NPE, in both modes.

 

because null is represened by a special type, here the compiler
find that add is add(type of null, int) and there is no conversion
between type of null and int.

var v = null;
add(v, 3) -> NPE

True, but not for the reasons you describe.  

because add is typed add(Object, int),

The type Object doesn't come into play here at all. Dyanmic is not Object.

 

there is a conversion
from Object to int (Object -> Integer -> int) and during Integer -> int,
intValue is called on null.
Also this error should be mapped to TypeError

The point is, the type annotations don't have any effect except in checked mode. The static type of the incoming value has no effect even in checked mode - it is its dynamic type that matters.

--
Cheers, Gilad

[Rémi Forax]

On 10/22/2011 02:49 PM, Gilad Bracha wrote:

Remi,

As you can clearly see from Peter's example, you aren't implementing Dart. 

Even in checked mode the behavior you describe does not match the spec.  One should not be thinking in terms of a traditional mandatory typed language like Java.

I know, it's just hard for me.

Currently, my typechecker tries to do it's best to propagate the types
in order to implement the checked mode. The idea is that if I use
a lazy typechecker that consider everything as a Dynamic, I will
be able to reuse the same runtime because the bytecode will not
provide any type information to the runtime.

On Sat, Oct 22, 2011 at 5:29 AM, Rémi Forax <fo...@univ-mlv.fr> wrote:

On 10/22/2011 01:17 PM, Peter Ahé wrote:

On Sat, Oct 22, 2011 at 13:06, Rémi Forax<fo...@univ-mlv.fr>  wrote:

On 10/22/2011 12:38 PM, Peter Ahé wrote:

 what happens if I write:

main() {
  print(add(3, 4));
  print(add("3", "4"));
  print(add(null, 4));
}

For reference, here is what should happen: http://try.dartlang.org/s/tvAc

add(3, 4)  -> 7                       // ok

add("3", "4") -> WrongMethodTypeException

34. Type annotations don't change behavior except in checked mode. You need to support both checked mode and production mode.

In production mode, the result will be "34" because add will be add(Dynamic, Dynamic).
I was only talking about the checked mode (see above).

 In checked mode, ths would lead to a dynamic type error (though not for the reasons you describe).

Could you explain the reason ?

 

because the compiler find that add is add(String, String) and
there is no conversion between String and int.
This exception should be mapped to TypeError.

add(null, 4) ->  WrongMethodTypeException

NPE, in both modes.

I can generate NPE in that case, not a big deal.

 

because null is represened by a special type, here the compiler
find that add is add(type of null, int) and there is no conversion
between type of null and int.

var v = null;
add(v, 3) -> NPE

True, but not for the reasons you describe.  

because add is typed add(Object, int),

The type Object doesn't come into play here at all. Dyanmic is not Object.

Sorry, I'm not clear here, the Java signature is Object but the runtime consider
it as Dynamic. For my runtime, Object, Dynamic and java.lang.Object share the same
runtime Object but have different behaviour (different vtables/map-tables).

 

there is a conversion
from Object to int (Object -> Integer -> int) and during Integer -> int,
intValue is called on null.
Also this error should be mapped to TypeError

The point is, the type annotations don't have any effect except in checked mode. The static type of the incoming value has no effect even in checked mode - it is its dynamic type that matters.

Is it ok to say, that null is a special case where even if you can detect a type error
you should report a NPE first.

--
Cheers, Gilad

cheers,
Rémi

[John Tamplin]

On Sat, Oct 22, 2011 at 8:49 AM, Gilad Bracha <gbr...@google.com> wrote:

The point is, the type annotations don't have any effect except in checked mode. The static type of the incoming value has no effect even in checked mode - it is its dynamic type that matters.

Just like the Dart->JS compiler makes use of type information to produce efficient code and the code will be fail if the type annotations are wrong, I would assume a Dart->JVM compiler would be free to make the same assumptions (clearly if there are no types you have to generate the slow but correct code).

In JS, we don't want to turn x+y into a method call for efficiency reasons, so if you declare x and y are of type num and they are really something else, then you will get the wrong result as it will just use the JS + operator rathar than x.operator$ADD.

int vs bigint will be an even bigger problem when compiling to the JVM than to JS -- if you really have to implement everything as BigInteger, performance will be tremendously slower.  I strongly feel that the answer here is to define bigint as int is currently defined, and leave the definition of int loose enough so that it can use the fastest option the target platform -- it could be implemented on top of bigint in the vm, Number in JS, or a 32-bit int in the JVM.  Since the actual need for arbitrary precision is rare, you shouldn't pay the cost for all the simple for loops that will never need it, and you shouldn't have silently incorrect behavior at runtime for the cases that actually do require arbitrary precision.

[Peter Ahé]

On Sat, Oct 22, 2011 at 16:34, John Tamplin <j...@google.com> wrote:
> On Sat, Oct 22, 2011 at 8:49 AM, Gilad Bracha <gbr...@google.com> wrote:
>>
>> The point is, the type annotations don't have any effect except in checked
>> mode. The static type of the incoming value has no effect even in checked
>> mode - it is its dynamic type that matters.
>
> Just like the Dart->JS compiler makes use of type information to produce
> efficient code and the code will be fail if the type annotations are wrong,
> I would assume a Dart->JVM compiler would be free to make the same
> assumptions (clearly if there are no types you have to generate the slow but
> correct code).

You would be assuming wrong. The exception is specifically for
generating JavaScript code.

If you want to run Java programs on a JVM, we recommend that you write
your programs in the Java programming languages. It is well-suited for
that particular task.

Cheers,
Peter

[Rémi Forax]

On 10/22/2011 04:34 PM, John Tamplin wrote:

On Sat, Oct 22, 2011 at 8:49 AM, Gilad Bracha <gbr...@google.com> wrote:

The point is, the type annotations don't have any effect except in checked mode. The static type of the incoming value has no effect even in checked mode - it is its dynamic type that matters.

Just like the Dart->JS compiler makes use of type information to produce efficient code and the code will be fail if the type annotations are wrong, I would assume a Dart->JVM compiler would be free to make the same assumptions (clearly if there are no types you have to generate the slow but correct code).

I agree again :)

And Gilad is right that the current runtime of jdart sometimes propagate type info
too aggressively and generate a type error instead of a NPE, but it will be fixed.

In JS, we don't want to turn x+y into a method call for efficiency reasons, so if you declare x and y are of type num and they are really something else, then you will get the wrong result as it will just use the JS + operator rathar than x.operator$ADD.

int vs bigint will be an even bigger problem when compiling to the JVM than to JS -- if you really have to implement everything as BigInteger, performance will be tremendously slower.  I strongly feel that the answer here is to define bigint as int is currently defined, and leave the definition of int loose enough so that it can use the fastest option the target platform -- it could be implemented on top of bigint in the vm, Number in JS, or a 32-bit int in the JVM.  Since the actual need for arbitrary precision is rare, you shouldn't pay the cost for all the simple for loops that will never need it, and you shouldn't have silently incorrect behavior at runtime for the cases that actually do require arbitrary precision.

Javascript has no bigint, it does int to double overflow at some point depending on the implementation.
I can implement exactly the same thing in the JVM for Dart.
It's just I think it doesn't worth it. The spec should be changed to say that int can be mapped
to a fixed number of bits (>= 32) that will overflow (and not null by default).

Also it's better to have a bigint.dart in core library exactly like you can find bigint.js on the web
because there will be no surprise.

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

Rémi

[John Tamplin]

On Sat, Oct 22, 2011 at 11:07 AM, Rémi Forax <fo...@univ-mlv.fr> wrote:

int vs bigint will be an even bigger problem when compiling to the JVM than to JS -- if you really have to implement everything as BigInteger, performance will be tremendously slower.  I strongly feel that the answer here is to define bigint as int is currently defined, and leave the definition of int loose enough so that it can use the fastest option the target platform -- it could be implemented on top of bigint in the vm, Number in JS, or a 32-bit int in the JVM.  Since the actual need for arbitrary precision is rare, you shouldn't pay the cost for all the simple for loops that will never need it, and you shouldn't have silently incorrect behavior at runtime for the cases that actually do require arbitrary precision.

Javascript has no bigint, it does int to double overflow at some point depending on the implementation.
I can implement exactly the same thing in the JVM for Dart.
It's just I think it doesn't worth it. The spec should be changed to say that int can be mapped
to a fixed number of bits (>= 32) that will overflow (and not null by default).

What I am suggesting is there is a bigint type, and in JS that would get mapped to a tightly optimized implementation on top of double (similar to GWT's long emulation, but extended for arbitrary precision).  In JS, int would be mapped to double just as it is now, and there would be very loose guarantees about exactly what happens around overflow (ie, it is guaranteed to have at least 32 bits and is not required to overflow at any particular bit boundary or even at all -- if you need such behavior, such as for crypto or hashing, you can call int.wrap32 etc [which would be no-op on a platform representing int as a 32-bit 2s-complement value]).  For the JVM, you could map bigint directly to BigInteger.

 

Also it's better to have a bigint.dart in core library exactly like you can find bigint.js on the web
because there will be no surprise.

No, I think you want bigint supported in the language for efficiency, particularly on the VM.

[Rémi Forax]

+1 for having a type bigint.
And it's not because there is a bigint.dart that the VM doesn't replace it
by a built-in type at runtime.

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

Rémi

[John Tamplin]

On Sat, Oct 22, 2011 at 12:54 PM, Rémi Forax <fo...@univ-mlv.fr> wrote:

+1 for having a type bigint.

And it's not because there is a bigint.dart that the VM doesn't replace it
by a built-in type at runtime.

That makes it a little harder, plus num can't be extended by user classes so you would still have to treat it specially there anyway -- must better to just define bigint as a type in the language like int.

[Rémi Forax]

On 10/22/2011 07:23 PM, John Tamplin wrote:

On Sat, Oct 22, 2011 at 12:54 PM, Rémi Forax <fo...@univ-mlv.fr> wrote:

+1 for having a type bigint.

And it's not because there is a bigint.dart that the VM doesn't replace it
by a built-in type at runtime.

That makes it a little harder, plus num can't be extended by user classes so you would still have to treat it specially there anyway -- must better to just define bigint as a type in the language like int.

Ok !

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

Rémi

[Florian Loitsch]

On Sat, Oct 22, 2011 at 16:34, John Tamplin <j...@google.com> wrote:

On Sat, Oct 22, 2011 at 8:49 AM, Gilad Bracha <gbr...@google.com> wrote:

The point is, the type annotations don't have any effect except in checked mode. The static type of the incoming value has no effect even in checked mode - it is its dynamic type that matters.

Just like the Dart->JS compiler makes use of type information to produce efficient code and the code will be fail if the type annotations are wrong, I would assume a Dart->JVM compiler would be free to make the same assumptions (clearly if there are no types you have to generate the slow but correct code).

I completely agree. However the Dart->JS compiler is not spec-compliant, and the Dart->JVM compiler wouldn't be either. It would be still nice to have a decent subset of Dart working on the JVM.

 

In JS, we don't want to turn x+y into a method call for efficiency reasons, so if you declare x and y are of type num and they are really something else, then you will get the wrong result as it will just use the JS + operator rathar than x.operator$ADD.

int vs bigint will be an even bigger problem when compiling to the JVM than to JS -- if you really have to implement everything as BigInteger, performance will be tremendously slower.  I strongly feel that the answer here is to define bigint as int is currently defined, and leave the definition of int loose enough so that it can use the fastest option the target platform -- it could be implemented on top of bigint in the vm, Number in JS, or a 32-bit int in the JVM.  Since the actual need for arbitrary precision is rare, you shouldn't pay the cost for all the simple for loops that will never need it, and you shouldn't have silently incorrect behavior at runtime for the cases that actually do require arbitrary precision.

And again this would not be Dart. A close variant, but not Dart.

// florian

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

[John Tamplin]

On Sat, Oct 22, 2011 at 1:15 PM, Florian Loitsch <floi...@google.com> wrote:

I completely agree. However the Dart->JS compiler is not spec-compliant, and the Dart->JVM compiler wouldn't be either. It would be still nice to have a decent subset of Dart working on the JVM.

If we are saying that the JS implementation is not spec compliant, and yet that is going to be the primary way Dart is used on the client at least for now, then perhaps the spec should be relaxed.  Otherwise, you will wind up a with a defacto subset of Dart that is all that is ever used anyway.

int vs bigint will be an even bigger problem when compiling to the JVM than to JS -- if you really have to implement everything as BigInteger, performance will be tremendously slower.  I strongly feel that the answer here is to define bigint as int is currently defined, and leave the definition of int loose enough so that it can use the fastest option the target platform -- it could be implemented on top of bigint in the vm, Number in JS, or a 32-bit int in the JVM.  Since the actual need for arbitrary precision is rare, you shouldn't pay the cost for all the simple for loops that will never need it, and you shouldn't have silently incorrect behavior at runtime for the cases that actually do require arbitrary precision. 

 

And again this would not be Dart. A close variant, but not Dart.

So are you saying that it is ok that there is no Dart implementation for use in browsers currently, and even once there is a VM implementation available, there will be no Dart implementation for most browsers (since we know some constructs would be too slow to implement in JS exactly)?  If I want to write an application that deals with financial values in Dart, does that mean I have to write my own arbitrary precision math package and use that?  In that case, even if the VM is available for some users, its capability for arbitrary precision int won't be usable anyway.