Google Dart

[BGB]

On 10/10/2011 6:56 PM, John Rose wrote:
> On Oct 10, 2011, at 6:48 PM, Krystal Mok wrote:
>
>> It's cute when you can find DartEntry::InvokeDynamic(...) in Dart 
>> VM's code [1] :-)
>> (Just for fun; doesn't imply any connection with JVM's invokedynamic)
>
> It's not derivative, and not very surprising to me:  I took over JSR 
> 292 from Gilad after he left Sun.  -- John
>

yep.


I will see, my message will probably be rejected by the list (I am no 
longer able to send emails from hotmail, so using gmail...).


sorry if there is no reason to care...
I am mostly describing a personal/hobby project below.


but, this thread seemed a little interesting, as from what little I have 
looked at it, Dart seems similar to some of my own efforts in language 
design (note: I am using a custom VM architecture for this, not 
particularly JVM-based).

essentially, my own effort has a currently JavaScript and ActionScript 
like core syntax (so a bit different from Dart here I guess), retaining 
optional dynamic types (and prototype objects + "dynamic classes"), 
while supporting explicit types (via annotations), and also type-inference.

unlike AS, it retains a fully-functional eval, and supports loading from 
source (these are presently its main use-cases, mostly it is a scripting 
language for a 3D engine written mostly in C and some C++ and ASM).

at the same time, it goes the other direction, and has "value classes", 
which support pass-by-value, copy-constructors, destructors, ... so can 
do the whole "RAII" thing (technically, they can also be 
dynamic-classes). sadly, "value classes" currently use a "value_class" 
keyword, which is ugly, but I lack any particularly better options at 
the moment.

this is an outgrowth of a prior "struct" feature, except that (formally) 
struct disallows inheritence or virtual methods (these are allowed for 
value-classes, whereas struct is intended for POD-types).

technically, they are still implemented as heap-allocated 
object-instances at run-time, but with the special feature that the VM 
will implicitly "delete" them whenever they go out of scope or are 
assigned-away (and create copies when passed/assigned/...). if no 
copy-constructor is defined, the object will simply be "cloned".

sadly, this feature is partly a way around the use of a slow 
conservative GC, but also has semantic uses.


there are some "original" features as well (mostly in terms of the 
scoping semantics and the C FFI). one feature I call "delegation" (which 
was sort of more inspired by Self) is used to implement many parts of 
the system (and is also a language feature).

basically, fields can be created and marked "delegate" which means 
accesses to fields/methods may go through them (transparently), and as 
such will not require being explicitly qualified. technically, 
delegated-to methods will retain the "this" from the source object, but 
may access their own fields via the "this" object (depending on 
specifics, delegation may also override methods or shadow fields). a 
delegate variable may also be accessed directly (like a normal field).

technically, the language has a toplevel and packages, but in another 
sense, neither exist:
both are presently implemented internally using objects and delegation.


also, most binding and type-specialization is handled late (for example, 
during "link-time" or at run-time), which allows for some semantic edge 
cases not so easily handled if this is done earlier (in the language 
frontend).

personally I don't think either delegation or the C FFI could likely be 
handled nearly as effectively if traditional early-bound semantics were 
required.

misc: the C FFI tries to be reasonably transparent (as-in, free of 
boilerplate) by importing metadata directly from C headers, and then 
generating glue-code as-needed at link-time/run-time. it is not perfect 
(still has some special 
annotations/heuristics/nasty-hacks/stupid-edge-cases/...), but it mostly 
works ok (it currently supports: 
functions/structs/typedefs/function-pointers/value-macros/... not fully 
supported: nested structs/unions, complex or function-like macros, 
certain cases involving lambdas and C function pointers, ...).

a tool and auto-generated code is also needed for exporting structs or 
functions to C (because, sadly, C doesn't have late-binding...).

ideally, in the future, there would be a direct C++ FFI, but this is a 
much more complex issue.


however, the technology is still far from mature, and I have no idea 
if/when/ever it will be sufficiently mature for "production use" (it 
works ok for my own uses, but then again I can also fix any problems 
which I run into as well, but people expecting a mature technology are 
likely not so forgiving towards bugs or incomplete/missing features in 
the VM/compiler/libraries/...).


not that it all really matters, it is just nice to see the world moving 
forwards...


or such...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20111010/b23f2c26/attachment.html