Laura Creighton wrote:

In a message of Sat, 28 Apr 2007 18:22:50 +0200, Carl Friedrich Bolz writes:

...

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. Cheers, Carl Friedrich

Laura Creighton wrote:

In a message of Sat, 28 Apr 2007 18:22:50 +0200, Carl Friedrich Bolz writes:

...

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. Cheers, Carl Friedrich