[pypy-dev] Fwd: New Javascript parser in the works

Carl Friedrich Bolz cfbolz at gmx.de
Sat Apr 28 19:25:43 CEST 2007

Laura Creighton wrote:
 > In a message of Sat, 28 Apr 2007 18:22:50 +0200, Carl Friedrich Bolz 
 >> would be valid. This opens its own set of problems such as:
 >>     a = b
 >>     ++ c
 >> Which would most likely be parsed to be equivalent to:
 >>     a = b++;
 >>     c;
 >> Whereas with the spec it is:
 >>     a = b;
 >>     ++c;
 >> No clue how to fix that, yet.
 >> Cheers,
 >> Carl Friedrich
 > In the Canadian military for an analagous set of problems we did the
 > following:
 > First of all you do the laxness move -- i.e.  you get rid of the
 > semicolon restictions.  Then you get a big a sample space of the
 > problem you have as you are willing to deal with.  In some way
 > determine that it is 'typical' -- which is a research topic in itself,
 > but if you are not in the field, then the rule is 'make a good guess,
 > refine it later when you are wrong'.  Then determine where it is
 > better to stick in the semi based on how the language is actually
 > used.  So, should the spec differ from what you do, that is actually
 > of no problem until you find that people really write code like the
 > above and want the spec, not the way you parsed it.

Very good points, all. Of course the real plan is to find a behavior
that works in most cases and is easy to parse. Afterwards we make our
interpreter very successful and people will be forced to comply with the
behavior because they want to be compatible, thereby training the
JavaScript programmers to write better code :-).

 > You would be surprised at how many of those problems go away because
 > no human ever writes things like that.  Should your problem space
 > be dominated by machine-generated code, though, your personal
 > ideas of 'how often will somebody write this' goes out the window.

I think that computer generated code is often more explicit since it has
advantages and does not cost too much. Also, fixing a code-generator is
easier than fixing handwritten code.


Carl Friedrich

More information about the Pypy-dev mailing list