Google Dart

[BGB]

On 10/11/2011 2:03 AM, Rémi Forax wrote:
> On 10/10/2011 08:58 PM, Charles Oliver Nutter wrote:
>> I agree it would be an interesting language on the JVM. It may be the
>> "dynamic Java" I've wanted to make for a long time, with the added
>> bonus of optional static types.
>>
>> This could almost be a weekend project atop invokedynamic.
> The type system is not that simple if you want to avoid
> to do one cast for each assignation (and for each method call arguments).
> I think you need one supplementary day :)

IMO, I can see a few (possibly technical) reasons for designing it the 
way they did:
a trivial implementation using dynamic types can ignore the types and 
still work.

however, I don't like it per-se, as the way it leaves open the case that 
an implementation may be forced to use dynamially-typed references even 
when using declared types, which IMO partly defeats the point of using 
declared types.


I more prefer it when declared types are a bit stronger, as in:
if you declare the type of a variable, then the value in the variable 
*will* be that type.

so, I think preferably this boils down to one of several major options:
type-check the assignment (or pass as argument), and 
balk/reject-the-code if it will fail;
implicitly coerce the value to the target type (maybe warn if unsafe, or 
balk if it is not a valid type conversion).

(some prior versions of my language had it more as "undefined", as in, 
if there is a type mismatch, one is liable to find their variable filled 
with garbage, as the type was treated mostly as an optimizer hint, but I 
later added implicit type coercion and made this the defined semantics).

also, as for declared-type = physical-type, this more easily allows for 
the (efficient) implementation of variables as native machine types when 
applicable (such as in stack-frames or in objects), and one can save 
references mostly for other things. it also saves from endlessly 
marshaling values to/from reference types as part of performing 
operations (such as arithmetic).

not that it has to be strictly this way though, for example, one can 
allow conversion to/from dynamic/variant types to involve implicit 
boxing/unboxing.


but, anyways, one can be careful not to underestimate the amount of 
time/effort some things will take: for example, a recent idea of mine 
was to essentially shove a WAD2 variant into PE/COFF images post-link 
(for storing additional lumps, generally for VM metadata and bytecode).

(note: WAD2 was a format used in Quake/Half-Life for storing textures. 
my variant is similar except that the header has a different/longer 
magic number, and optional indirect-names which allow for lump-names 
longer than 16 characters, also compression methods 8/9 are defined as 
Deflate and Deflate64). (there were technical reasons for me not 
choosing a ZIP variant here).

I initially estimated this to be an approx 2 hour project. the project 
in-fact took a good portion of 2 days: the former night, mostly for 
writing out most of the code, and the next morning/afternoon mostly for 
debugging it all and making it work.


>> - Charlie
> Rémi
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev