On 10/10/2011 8:42 PM, BGB wrote:
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).
upon further observation (quickly skimming over the Dart language spec,
...) I have noted a number of subtle, but but potentially fundamental,
differences between Dart and my language (BGBScript).
some info:
http://cr88192.dyndns.org/wiki/index.php/BGBScript
http://cr88192.dyndns.org/SilvVMSpec/2011-05-25_BGBScript15.html
I guess, to summarize:
scoping differs (Dart is primarily lexical scoped, mine has a more
complex scoping model);
the semantics for variable type annotations is different (my current
semantics are closer to those in C and C++, namely that there may be an
implicit type coercion);
the object system differs;
blocks and closures work differently (I adopted the semantics that if
the last statement in a block is an expression, then it is itself the
return value).
in general, it appears like mine may be more complex, but then again,
mine was not designed for simplicity, and it has currently been alive
(more or less) for 8 years now (although subject to
extension/tweaking/fiddling/... along the way, some changes of which
have made notable syntax and semantics tweaks, and most features have
been added reflexively rather than the language having been "designed"
up-front).
for example:
"fun(x, y) x+y;", in my language, will return the result of x+y,
including with braces:
"fun(x, y) { x+y }" or "fun(x, y) { x+y; }".
note, this syntax is valid:
"(fun(x,y)x+y)(2,3);", which creates a closure and calls it.
I guess (as can be noted), my language differs from JS proper in that it
includes a numeric tower, rather than a single "number" type.
or such...
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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
