Re: target platforms and .NET, was GCC is 25 years old today

On 3/30/2012 1:33 PM, BGB wrote:


<snip>


> either way, it wouldn't work with Mono.
> theoretically, a .NET port of the VM could be made, but I am not
> personally inclined to bother with this.
> [Porting to .NET would be a challenge, since you'd have to graft on
> the whole .NET type system. -John]


yes, granted.


me wandering off pretty far from the original topic here, oh well.




I can imagine bigger issues though:
be lazy, port to C++/CLI, live with the issue that it wont work on Mono;
or, having to largely re-implement the VM in C# (would likely be a huge
pain, and would likely almost be better off as a largely ground-up
reimplementation).


the type-system shouldn't be as much of a challenge, since technically
.NET can do vaguely similar stuff to what my typesystem does, and other
parts of the design were partly inspired by C# anyways (the static type
hierarchy is fairly similar).


a few major influences: ECMAScript, ActionScript, Java, C#, C, and C++,
as well as lesser influences: Scheme, Self, Erlang, ... the language
roughly implements ECMA-262, but deviates in some cases.




similarly, BGBScript already supports Class/Instance OO, references,
properties, ...


note: it also still has Prototype-OO, internally a "hybrid" object model
is used. externally, this is exposed similar to in ActionScript3,
whereby using a "dynamic" modifier on a class declaration allows
addition of new fields at runtime (otherwise, a fixed layout is used).
objects created ex-nihilo are implicitly both dynamic and lack a parent
class (internally, there are about 3 different "types" of object, with
the "dynamic class" case being a class/instance object daisy-chained
with a prototype/"dictionary" object, which is apparently different from
how it works in ActionScript, but then again, I also implemented
interfaces via a large hash-table as well...).




note: there is a partial split between static and dynamic types, as the
"static type system" vaguely represents a Java/C# style type-system, and
the "dynamic type system" uses a different set of types (so, it is not
strictly 1:1, unlike Java or C#).


hence:
var i:int; //integer variable (32-bit range)
var j:fixnum; //fixnum variable (currently 28 or 48 bit range)
car k:long; //long variable (64-bit range)
var v; //variant (default type)


v=i; //may convert to fixnum or a boxed int (depending on range)
v=j; //copied directly (may be slightly cheaper in some cases)
v=k; //currently converts to boxed long


note that type coercion works more like C, with most types converting
freely when possible, although potentially implicit down-casting could
be made to generate a warning.


var b:bool;
b=i; //"warn: implicit type conversion from int to bool" or similar.


variant is not exactly the same as "object" in C#, differing mostly in
fine details (in certain cases, type-inference is allowed to convert it
to a static type, although it will always be a variant/reference if used
as an explicit storage type).


note that the default array type is "variant[]", and arrays will be this
type except in certain cases (creation via "new type[size]", array-type
suffixes, or being used to initialize a variable with a declared array
type "var arr:int[]=[1,2,3];").




struct Foo {
var obj:variant; //will not be inferred
var obj2; //likewise
}


note: structs have similar behavior to C#, and are pass-by-value /
pass-by-copy. there is also "value_class", which is conceptually similar
(but is a full class type, sort of like in C++, but lacking MI).
internally, structs and value-classes are aliases (but, they are not
strictly equivalent regarding their semantics).


note: the same basic mechanism is used to access C structs, and could
potentially be extended to support C++ classes, but more work would be
needed for this (mostly for supporting vtables and similar, but it has
not been a high priority).


extra note: "dynamic value_class" is not allowed, maybe for obvious
enough reasons. value-classes have a fixed memory layout.




example:
value_class Foo {
...
}


var obja:Foo; //value class
var objb:*Foo; //pointer to value class
var objc:Foo; //value class


obja=new Foo(); //init obja (1)
objb=&obja; //pointer to obja (2)
objc=obja; //copy of obja (may invoke copy-constructor, 3)


...


note 1: value classes are implemented differently than in C++ or
similar, in that they are still handled as reference-types (to heap
allocated instances). their primary difference is that they are subject
to copy/delete semantics (they are deleted when they go out of scope,
which will call the destructor if one exists). granted, this isn't
particularly efficient, but whatever.


note 2: currently, there is no construct to directly initialize a
"pointer to a value-class", but something like "new *Foo()" or similar
is a possible syntax. technically, "&obja" creates a reference, but
references may be implicitly converted to pointers.


note 3: functionally similar to "objc=new Foo(obja);" if a valid
constructor exists (otherwise, a raw copy is made).




side node, the syntax:
int i;
string str;
...
is supported, just it is harder to claim that the language is still an
ECMAScript variant, if one is sitting around using lots of declarations
which are clearly a different style from ECMAScript. these cases are
parsed more like in Java/C# than like in C or C++ though. also, unlike C
or C++, pointers are declared with '*' in prefix position "*int pi;"
rather than "int *pi;", this change having been made to avoid
potentially ambiguous syntax (for a similar reason, the language doesn't
use C style cast syntax, instead using a different syntax: "x as type"
and "x as! type").


by convention, I am typically staying closer to ECMAScript style.




a bigger challenge (if trying to produce CIL) could be the scoping
model, where my language uses a scoping model partly influenced by Self,
which is relatively uncommon and lacks .NET support.


lesser worries are that .NET lacks direct fixnum and flonum analogues,
and they would instead have to be implemented via boxed types, which
would be more expensive (a boxed type being generally a heap-allocated
object, vs a value encoded directly into the pointer).


this is also one point (among others) where my language fails regarding
ECMA-262 conformance: I don't default to using double for numbers,
because I would have to box doubles, and this would be expensive. so,
cheaper fixnums and flonums are used, but flonums are considerably less
accurate than a double (on 32-bit targets, they are a 32-bit float with
the low-order bits shaved off, and on 64-bit targets is a 64-bit double
with low-order bits shaved).




luckily, I have no plans to port to .NET, and am not at present all that
concerned even with making a nice C#/BS interface.




likely higher priorities:
finish implementing the new JIT / native-compiler;
implement some good way to directly produce (native friendly) DLLs
without needing to first generate and compile C glue-code (IOW: a custom
static linker);
...


but, as such, these are still not terribly high priorities for my
project as a whole.

Return to the comp.compilers page.
Search the comp.compilers archives again.