Google Dart

[BGB]

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

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