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