----- Original Message -----
From: "Waldemar Kornewald" <[email protected]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Friday, October 08, 2010 11:38 AM
Subject: Re: [fonc] On inventing the computing microscope/telescope for
thedynamic semantic web
On Fri, Oct 8, 2010 at 8:28 PM, John Zabroski <[email protected]>
wrote:
Why are we stuck with such poor architecture?
A bad language attracts bad code. ;)
well, JS could be better...
for example, my custom variant (BGBScript) supports multiple delegates,
ability to handle delegation loops, ... (however, working with them requires
at present using non-standard syntax).
it also uses a different scoping model than proper JS as well:
a lexical scope is used for locals;
there is object based scoping via 'this';
there is also a toplevel scope 'top', which is also an object (most of the
toplevel is implemented in terms of objects linked together by delegation
chains).
originally, this and top were the same (there was only this, which would
need to delegate to the toplevel);
however, a split was added later, mostly because this had created problems
with using objects created outside the BS interpreter.
granted, there are many other minor variations (numeric types are
implemented and work differently than in the standard, as it has separate
integer and real types rather than a unified 'number' type, ...), so it is
not really a true JS/ES implementation, but at least most simple JS code
seems to work (apart from stuff which assumes a browser or similar).
"typeof(expr)" is also an issue, as it currently doesn't return what
ECMA-262 says it should (it currently returns the internal type names), ...
some additional non-standard features exist, but are mostly related to
interfacing with C and Java code (and their respective typesystems, but this
is mostly internal and doesn't add new syntax), and some syntax elements
adapted from ActionScript and similar.
package MyApp
{
class Bar extends Foo implements IBaz
{
function foo():void //base-types are lowercase, unlike AS
{
var x:byte[]; //syntax works, but the type is
presently ignored in this case
x=new byte[256]; //likely later, incomplete though (more
awkward syntax currently used)
x=dycNewArray("h", 256); //current syntax (uses C interface)
...
}
...
}
}
however, generally the above style is not used (nor will this example work
in the current VM), so it is more generally used similarly to JS (but with
the ability to see into C land, which is mostly how I use it).
actually, it was me adding the ability to (mostly) transparently see into
C-land which revived my interest in using/maintaining the language (this is
done with a lot of ugly hackery, involving parsing headers to mine metadata,
and auto-generating native-code thunks to glue together the interpreter and
C land, as well as a few other hacks to make C preprocesser definitions
visible, ...).
note that the C interface is largely implemented in terms of a special
object type, and hence, if this object is not part of the scope (say, using
a 'top' object which doesn't delegate to it), then C functions are not
visible (it was done this way so that the interpreter would not "inherently"
violate security by always having direct visibility of C land).
for example:
function foo()
{
printf("%f\n", M_PI); //this will actually work...
}
foo();
implemented, but largely untested, facilities also exist for the ability to
directly work with C structures, as well as the ability to shove BS
functions into C-side function pointers (this also involves generating
thunks).
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
