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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
