Prev: How can I get visible area on Android browser?
Next: Singleton vs Singleton
From: John G Harris on 28 Jan 2010 14:29
On Thu, 28 Jan 2010 at 00:47:58, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:

<snip>
>>> A syntax error creates an abrupt completion, that is, (per section 8.9),
>>> a value of the internal Completion type (`(type, value, target)'; it was
>>> asked about yesterday) with the type being any other than `normal'.
>>
>> The type in an abrupt completion doesn't include 'error' (in ES3).
>
>No, but it includes `throw', and if you had read more carefully you would
>have observed several occurrences of `throw' near `SyntaxError' in the
>Specification prose.
<snip>

SyntaxError is specified only for eval, new Function, and regular
expression parsing. In each case there is an ordinary throw action, not
a program-stopping event.

Face it, nowhere in the standard does it say how to evaluate something
like
if () a b;
outside eval and new Function when expecting a statement.

John
--
John Harris
From: Thomas 'PointedEars' Lahn on 28 Jan 2010 16:49
John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>>> A syntax error creates an abrupt completion, that is, (per section
>>>> 8.9), a value of the internal Completion type (`(type, value,
>>>> target)'; it was asked about yesterday) with the type being any other
>>>> than `normal'.
>>>
>>> The type in an abrupt completion doesn't include 'error' (in ES3).
>>
>> No, but it includes `throw', and if you had read more carefully you
>> would have observed several occurrences of `throw' near `SyntaxError'
>> in the Specification prose.
> <snip>
>
> SyntaxError is specified only for eval, new Function, and regular
> expression parsing.

Correct for the first two. Correct for the last one in the widest sense.
Per ES3F, a SyntaxError exception is explicitly thrown in the following
algorithms:

- eval() [15.1.2.1]
- new Function() [15.3.2.1]
- Regular expression parsing [15.10.2.x]
- new RegExp() [15.10.4.1]

> In each case there is an ordinary throw action, not a program-stopping
> event.

Incorrect.

| 5.2 Algorithm Conventions
| [...]
| If an algorithm is defined to “throw an exception”, execution of the
| algorithm is terminated and no result is returned. The calling
| algorithms are also terminated, until an algorithm step is reached that
| explicitly deals with the exception, using terminology such as “If an
| exception was thrown…”. Once such an algorithm step has been encountered
| the exception is no longer considered to have occurred.

Then, by

| The production StatementList : Statement is evaluated as follows:
|
| 1. Evaluate Statement.
| 2. If an exception was thrown, return (throw, V, empty) where V is the
| exception. (Execution now proceeds as if no exception were thrown.)

an abrupt completion is returned. Then, by step 2 of

| The production StatementList : StatementList Statement is evaluated as
| follows:
|
| 1. Evaluate StatementList.
| 2. If Result(1) is an abrupt completion, return Result(1).
| 3. Evaluate Statement.

that Completion value is returned to

| The production SourceElements : SourceElements SourceElement is evaluated
| as follows:
|
| 1. Evaluate SourceElements.
| 2. If Result(1) is an abrupt completion, return Result(1)
| 3. Evaluate SourceElement.
| 4. Return Result(3).

where in step 2 it causes the algorithm to return the Completion value
before /SourceElement/ is evaluated, to

| The production Program : SourceElements is evaluated as follows:
|
| 1. Process SourceElements for function declarations.
| 2. Evaluate SourceElements.
| 3. Return Result(2).

which causes the /Program/ to end (prematurely). (That is, of course, if
the exception is not handled before.)

> Face it, nowhere in the standard does it say how to evaluate something
> like
> if () a b;
> outside eval and new Function when expecting a statement.

Incorrect.

| 5.1.4 The Syntactic Grammar
|
| [...]
| When a stream of Unicode characters is to be parsed as an ECMAScript
| program, it is first converted to a stream of input elements by repeated
| application of the lexical grammar; this stream of input elements is then
| parsed by a single application of the syntax grammar. The program is
| syntactically in error if the tokens in the stream of input elements
| cannot be parsed as a single instance of the goal nonterminal Program,
| with no tokens left over.

The relevant productions here are:

| Program :
| SourceElements
| [...]
| SourceElements :
| SourceElements SourceElement
| [...]
| SourceElements :
| SourceElement
| [...]
| SourceElement :
| Statement
| [...]
| Statement :
| IfStatement
| [...]
| IfStatement :
| [...]
| if ( Expression ) Statement

The last two productions are not applicable because the empty string cannot
be produced by /Expression/ -- the relevant production is

| Expression :
| AssignmentExpression
| Expression , AssignmentExpression

--, and backtracking results in no other productions being applicable.
Therefore, the program is syntactically in error.

I am willing to concede that the Completion type might not be involved in
that case. However, there can be no doubt that a program that is
syntactically in error cannot be executed after the point at which the
syntax error occurs, if it can be executed at all.

For example, a conforming implementation could, per section 16, defer
reporting the syntax error in a function declaration until the
corresponding function is called, provided that the syntax error does not
make it impossible to evaluate the function identifier and so to recognize
the subsequent call; by contrast, your code cannot be executed at all
because neither the basic Statement nor the FunctionDeclaration production
is applicable -- not even the /Program/ production is applicable.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: John G Harris on 29 Jan 2010 15:21
On Thu, 28 Jan 2010 at 22:49:45, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

<snip>
>by contrast, your code cannot be executed at all
>because neither the basic Statement nor the FunctionDeclaration production
>is applicable -- not even the /Program/ production is applicable.

Did you not know that paid-for compilers aimed at professionals try to
detect as many syntax errors as possible in one pass through the
program?

I see nothing in the ECMAScript standard to prevent that happening. As
for execution after seeing a syntax error, it may not be common practice
but I've seen it happen in a professional context, even though I hate
the idea.

John
--
John Harris
From: Thomas 'PointedEars' Lahn on 29 Jan 2010 16:03
John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> <snip>
>> by contrast, your code cannot be executed at all because neither the
>> basic Statement nor the FunctionDeclaration production is applicable --
>> not even the /Program/ production is applicable.
>
> Did you not know that paid-for compilers aimed at professionals try to
> detect as many syntax errors as possible in one pass through the
> program?

I did not know that. I am a professional (software developer) and never
had to pay for a compiler to date. Regardless, static code analysis cannot
detect all syntax errors. If the evaluation context cannot be determined
because a syntax error occurred before, it may not be possible to say
whether code following it contains a syntax error or not. Surely that
applies to many productions of ECMAScript.

> I see nothing in the ECMAScript standard to prevent that happening.

And I did not say that there would. I fact, I said explicitly that
reporting syntax errors early is allowed by the Specification, possible
in some cases, and I explained one example (that you snipped).

> As for execution after seeing a syntax error, it may not be common
> practice but I've seen it happen in a professional context, even though
> I hate the idea.

Your feelings aside, relying on inherently unreliable results like those
gained from syntactically incorrect code can hardly be considered
professional behavior.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or anothr network. -- Tim Berners-Lee
First  |  Prev  | 
Pages: 1 2 3
Prev: How can I get visible area on Android browser?
Next: Singleton vs Singleton