features for es that would make it a perfect intermediate compiler target

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sun Mar 22 03:55:18 PDT 2009


On Sun, Mar 22, 2009 at 12:36 AM, Ash Berlin <ash_es4 at firemirror.com> wrote:
> Comments inline.

 thanks :)


>> 2) undefined.
>>
>> specifically, the lack of exception raising when an undefined variable
>> is encountered.  that is _such_ a disaster it's unreal.  think about
>> how a compiler of a dynamic language such as scheme, ruby and python
>> has to emulate that, by checking _every_ single variable in _every_
>> single instance where it is used (and raise an exception), and you
>> start to realise "oh my god - that's... _awful_".
>
>
> I don't even get what you mean here. Can you provide an example please?

 take following python - execute it:

 x = 5
 print x
 print y

you get NameError: name 'y' is not defined

take following javascript, in a web browser - execute it:

x = 5
alert(x)
alert(y)

you get two popups: one saying "5" and the other "undefined".


question: how does a compiler translate code from python into
javascript which is capable of dealing with this?

answer: with some absolute _nightmare_ code, testing _every_ single
variable before use, resulting in approximately doubling the size of
the compiled code:

if typeof x == undefined { throw NameErrorException("x is undefined"); }
x = 5;
if typeof x == undefined { throw NameErrorException("x is undefined"); }
alert(x);
if typeof y == undefined { throw NameErrorException("y is undefined"); }
alert(y);

because the ECMA specification never _insisted_ on an exception being
raised, no browser ever implemented it.



> See, the problem here is (I think) your are equating ECMAScript to
> ECMAScript running in a browser.

 well, i'm not, but may have given the impression that i am, for which
i apologise.

 i am dealing with one on a daily basis (browser), such that the
issues that pyjamas faces are foremost in my mind.

but i would _also_ like to see ECMAScript extended to be able to take
over from the python-psyco JIT compiler by being a suitable
intermediate compiler target, by being able to run under google V8
engine, spidermonkey and other javascript interpreters.

the JIT psyco compiler can only deal with and accelerate python on
32-bit x86 platforms, whereas V8 can do 32-bit x86 and ARM assembler,
and /usr/bin/smjs will run on absolutely anything.

so once pyjs was good enough, and once someone else did an
experimental combination of python and google v8, i started the
pyv8+pyjs experiment, but _instantly_ ran into problems - like lack of
support for integers.


> This is not the same thing. Thats like
> saying the ECMAScript should mandate the DOM access.

 nehh, the DOM is just an object that's dumped into the global
namespace of an emcascript engine.  well - at least two: one object
named "document" and another named "window".  some browsers dump the
objects in those two into the top-level namespace as well.  ( i
mention this to let you know that i have an understanding about it -
you're no doubt already aware of how it works )

several other things are thrown into the global namespace as well,
such as setTimeout and clearTimeout.

what _isn't_ added - because when the original browser engineers came
up with it they didn't _remotely_ consider it a possibility that
people would try to use javascript for "serious" programming inside
web browsers - is threading, mutexes and semaphores.


> And unless I'm very
> much mistaken, thats not in the spec. That's not to say that I don't think
> there's a need for this sort of common functions/objects in a browser, but
> I'm not sure that ES-3.1/Harmony is the place for such a spec.

  hmm.... good point.... or.... well... you say that... but is it?
you specify base functionality of objects, functions - strings,
numbers, arrays, dictionaries (good addition!) etc.

 why not have a section "if certain functionality is to be defined
e.g. threads e.g. mutexes e.g. semaphores it _must_ be defined this,
this and this way"?

 thus definining a common standard for interoperability, which both
browsers and command-line interpreters would have to sit up and go
"hmmm" over.

> Also a lot of your concerns only address javascript as a language running
> inside a browser - I for one think it has a future as a stand alone
> language.

 for that to happen, you are going to need to define a common set of
functionality such as how to import scripts, how to handle stdin,
stdout, stderr, what exceptions to raise, how to interface to external
libraries (in c, c++ or other languages), how to implement threads,
semaphors, mutexes and much much more.

what happens when scripts are imported: do they have their own
separate and distinct variable scoping (like in python), or are all
variables imported directly into the global namespace (like in
browsers)?  is the script _executed_ on import?  what happens if you
have threads and you do an import in both threads?  is loading of a
script to be done in both threads, or is the load to be treated as a
"singleton", like modules are in python?

all of these things and many more need to be addressed to make
ECMAscript a serious contender.
the "pyv8 + pyjs" experiment, which gave literally a 10-times
performance increase over standard python shows that there are real
exciting possibilities, but you can't leave it up to chance:
implementors will invent their own way of doing things, and that will
cause as much of an interoperability headache as is present with
browsers at the moment.

l.


More information about the Es-discuss mailing list