The syntax for the do..while statement (ECMA-262 12.6.1[1]) is:
do /Statement/ while ( /Expression/ );
Noting the trailing semicolon, I expected the following to throw an
error:
do {} while (false) var x = 3;
since there is no semicolon to separate the two statements. However,
I've tested a number of browsers and no error is thrown. So either the
browsers I tested are all tolerant of the error (possible in one or
two but unlikely in half a dozen) or automatic semicolon insertion is
at work.
But my understanding of automatic semicolon insertion (ECMA-262
7.9[2]) doesn't cover this case.
Can someone please explain why no error is thrown and it seems that a
semicolon is inserted?
On Tue, 28 Aug 2012 at 23:56:36, in comp.lang.javascript, RobG wrote:
>The syntax for the do..while statement (ECMA-262 12.6.1[1]) is:
> do /Statement/ while ( /Expression/ );
>Noting the trailing semicolon, I expected the following to throw an
>error:
> do {} while (false) var x = 3;
>since there is no semicolon to separate the two statements. However,
>I've tested a number of browsers and no error is thrown. So either the
>browsers I tested are all tolerant of the error (possible in one or
>two but unlikely in half a dozen) or automatic semicolon insertion is
>at work.
>But my understanding of automatic semicolon insertion (ECMA-262
>7.9[2]) doesn't cover this case.
<snip>
ECMA 262 section 7.9 on semicolon insertion confirms that a semicolon is
expected :
"Certain ECMAScript statements (empty statement, variable statement,
expression statement, do-while statement, continue statement, break
statement, return statement, and throw statement) must be terminated
with semicolons."
It looks as though it's a quirk on some famous browser that all the
others feel they must copy. (Because some idiot might be relying on it).
> The syntax for the do..while statement (ECMA-262 12.6.1[1]) is:
> do /Statement/ while ( /Expression/ );
> Noting the trailing semicolon, I expected the following to throw an
> error:
> do {} while (false) var x = 3;
> since there is no semicolon to separate the two statements. However,
> I've tested a number of browsers and no error is thrown. So either the
> browsers I tested are all tolerant of the error (possible in one or
> two but unlikely in half a dozen) or automatic semicolon insertion is
> at work.
maybe?... (speculation here, based partly on my own implementation).
because some implementations don't actually "insert" semicolons, rather they "eat" them (check for semicolon, and if-seen, it is discarded). (this would be because it is faster and easier to treat the semicolon as a break and then eat it, than it is to figure out how to write logic to accurately figure out where to insert them, the "semicolon insertion" may then be generally interpreted as "if we may see a semicolon here, and see a newline or similar instead, interpret it as if it were a semicolon").
but, upon trying to eat the semicolon, there is none there for it to eat, so it continues on as normal (and since the do/while statement is otherwise self-terminating, it does not lead to an ambiguity).
> But my understanding of automatic semicolon insertion (ECMA-262
> 7.9[2]) doesn't cover this case.
> Can someone please explain why no error is thrown and it seems that a
> semicolon is inserted?
standards are not always interpreted as an exact definition of the mechanisms, rather, of their externally perceived interface and behavior.
in edge cases though, one may find things where the behavior of actual implementations differs in minor ways from the mechanism which may be implied by the wording of a standard (though usually implementations will usually try to avoid this where possible).
BGB wrote:
> On 8/29/2012 1:56 AM, RobG wrote:
>> The syntax for the do..while statement (ECMA-262 12.6.1[1]) is:
>> do /Statement/ while ( /Expression/ );
>> Noting the trailing semicolon, I expected the following to throw an
>> error:
>> do {} while (false) var x = 3;
>> since there is no semicolon to separate the two statements. However,
>> I've tested a number of browsers and no error is thrown. So either the
>> browsers I tested are all tolerant of the error (possible in one or
>> two but unlikely in half a dozen) or automatic semicolon insertion is
>> at work.
> maybe?... (speculation here, based partly on my own implementation).
Did you mean _interpretation_? If not, your implementation is borken.
> because some implementations don't actually "insert" semicolons, rather
> they "eat" them (check for semicolon, and if-seen, it is discarded).
> (this would be because it is faster and easier to treat the semicolon as
> a break and then eat it, than it is to figure out how to write logic to
> accurately figure out where to insert them, the "semicolon insertion"
> may then be generally interpreted as "if we may see a semicolon here,
> and see a newline or similar instead, interpret it as if it were a
> semicolon").
> but, upon trying to eat the semicolon, there is none there for it to
> eat, so it continues on as normal (and since the do/while statement is
> otherwise self-terminating, it does not lead to an ambiguity).
I realize that you said "maybe?" and "speculation", but still…
Utter nonsense.
What actually happens is very simple:
,-[ECMA-262, 5.1 Edition]
| | 7.9 Automatic Semicolon Insertion
| | Certain ECMAScript statements (empty statement, variable statement,
| expression statement, do-while statement, continue statement, break
| statement, return statement, and throw statement) must be terminated with
| semicolons. Such semicolons may always appear explicitly in the source
^^^ ^^^^^^^^^^^^^^^^^
| text. For convenience, however, such semicolons may be omitted from the
^^^^^^^^^^^^^^
| source text in certain situations. These situations are described by
| saying that semicolons are automatically inserted into the source code
^^^^^^^^^^^^^^^^^^^^^^^^^^ (MUST)
| token stream in those situations.
^^^^^^^^^^^^^^^^^^^
IOW,
do {} while (false) var x = 3;
*is* equivalent to
do {} while (false); var x = 3;
because `var' delimits a /VariableStatement/ and the parser is allowed, in order to produce
/Program/
→ /SourceElements_opt/
→ /SourceElements/ /SourceElement/
→ /SourceElement/ /SourceElement/
→ /Statement/ /Statement/
→ /IterationStatement/ /VariableStatement/
→ do /Statement/ while ( /Expression/ ); /VariableStatement/
→ do /Block/ while ( /Expression/ ); /VariableStatement/
→ …
→ do {} while ( true ); var x = 3;
to insert the semicolon before the /VariableStatement/. It's not a bug, it's a feature, and a standards-compliant feature at that.
> standards are not always interpreted as an exact definition of the
> mechanisms, rather, of their externally perceived interface and behavior.
> in edge cases though, one may find things where the behavior of actual
> implementations differs in minor ways from the mechanism which may be
> implied by the wording of a standard (though usually implementations
> will usually try to avoid this where possible).
Again, utter nonsense. Instead, this particular standard gives its conforming implementations a wide latitude (see "Conformance"); in addition, some of its implementations are simply not conforming in some features.
PointedEars
-- Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300d...@news.demon.co.uk> (2004)
BTW, this is a *non-normative* *private*, *anonymous* (and privately annotated) rendering of the 5.1 Edition of ECMAScript. It should not be used as reference material.
Use the official HTML rendering of the 5.1 Edition (by Allen Wirfs-Brock [TC39], AFAIK) instead, or the normative PDF version. Both are linked to from <http://ecmascript.org/>, and indeed, from <http://es5.github.com/>
as well.
PointedEars
-- realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
>> On 8/29/2012 1:56 AM, RobG wrote:
>>> The syntax for the do..while statement (ECMA-262 12.6.1[1]) is:
>>> do /Statement/ while ( /Expression/ );
>>> Noting the trailing semicolon, I expected the following to throw an
>>> error:
>>> do {} while (false) var x = 3;
>>> since there is no semicolon to separate the two statements. However,
>>> I've tested a number of browsers and no error is thrown. So either the
>>> browsers I tested are all tolerant of the error (possible in one or
>>> two but unlikely in half a dozen) or automatic semicolon insertion is
>>> at work.
>> maybe?... (speculation here, based partly on my own implementation).
> Did you mean _interpretation_? If not, your implementation is borken.
this particular implementation is in the gray area between being "not exactly conformant" and "an entirely different language" (it is used mostly for application-level scripting, currently within a 3D game engine).
>> because some implementations don't actually "insert" semicolons, rather
>> they "eat" them (check for semicolon, and if-seen, it is discarded).
>> (this would be because it is faster and easier to treat the semicolon as
>> a break and then eat it, than it is to figure out how to write logic to
>> accurately figure out where to insert them, the "semicolon insertion"
>> may then be generally interpreted as "if we may see a semicolon here,
>> and see a newline or similar instead, interpret it as if it were a
>> semicolon").
>> but, upon trying to eat the semicolon, there is none there for it to
>> eat, so it continues on as normal (and since the do/while statement is
>> otherwise self-terminating, it does not lead to an ambiguity).
> I realize that you said "maybe?" and "speculation", but still…
> Utter nonsense.
actually, the implementation in question does actually work this way.
it seemed at least possible that other implementations could have worked in a similar way.
> ,-[ECMA-262, 5.1 Edition]
> |
> | 7.9 Automatic Semicolon Insertion
> |
> | Certain ECMAScript statements (empty statement, variable statement,
> | expression statement, do-while statement, continue statement, break
> | statement, return statement, and throw statement) must be terminated with
> | semicolons. Such semicolons may always appear explicitly in the source
> ^^^ ^^^^^^^^^^^^^^^^^
> | text. For convenience, however, such semicolons may be omitted from the
> ^^^^^^^^^^^^^^
> | source text in certain situations. These situations are described by
> | saying that semicolons are automatically inserted into the source code
> ^^^^^^^^^^^^^^^^^^^^^^^^^^ (MUST)
> | token stream in those situations.
> ^^^^^^^^^^^^^^^^^^^
in this case, it only behaves as if this were happening, but the actual logic is instead based on noticing certain patterns, and eating the tokens.
the reason was partly because this could be done directly within the parser logic, without needing to actually "insert" anything (there is no separate lexer or parser stages either, FWIW, just a single-pass recursive descent parser).
> BGB wrote:
> > On 8/29/2012 1:56 AM, RobG wrote:
> >> The syntax for the do..while statement (ECMA-262 12.6.1[1]) is:
> >> do /Statement/ while ( /Expression/ );
> >> Noting the trailing semicolon, I expected the following to throw an
> >> error:
> >> do {} while (false) var x = 3;
> >> since there is no semicolon to separate the two statements. However,
> >> I've tested a number of browsers and no error is thrown. So either the
> >> browsers I tested are all tolerant of the error (possible in one or
> >> two but unlikely in half a dozen) or automatic semicolon insertion is
> >> at work.
> ,-[ECMA-262, 5.1 Edition]
> |
> | 7.9 Automatic Semicolon Insertion
> |
> | Certain ECMAScript statements (empty statement, variable statement,
> | expression statement, do-while statement, continue statement, break
> | statement, return statement, and throw statement) must be terminated with
> | semicolons. Such semicolons may always appear explicitly in the source
> ^^^ ^^^^^^^^^^^^^^^^^
> | text. For convenience, however, such semicolons may be omitted from the
> ^^^^^^^^^^^^^^
> | source text in certain situations. These situations are described by
> | saying that semicolons are automatically inserted into the source code
> ^^^^^^^^^^^^^^^^^^^^^^^^^^ (MUST)
> | token stream in those situations.
> ^^^^^^^^^^^^^^^^^^^
Since "certain situations" are not explained (other than by the
circuitous logic that they're those where semicolons are inserted), I
understood that section as a preamble to 7.9.1 which sets out a number
of "certain situations" and 3 rules for insertion. It is those 3 rules
that don't cover the do..while case I posted, they seem to require
either a new line or that a '}' is involved in order to insert a
semicolon.
e.g. 7.9.1 #1 covers the following cases:
var x = 3
var y = 4
A semicolon is inserted after the first line because it's followed by
a newline character and then something that can't be part of the
variable declaration statement.
The missing semicolon indicated is inserted because the following
character is '}' and a semicolon is inserted at the end because it's
the end of the input stream.
> because `var' delimits a /VariableStatement/ and the parser is allowed, in
> order to produce
> /Program/
> → /SourceElements_opt/
> → /SourceElements/ /SourceElement/
> → /SourceElement/ /SourceElement/
> → /Statement/ /Statement/
> → /IterationStatement/ /VariableStatement/
> → do /Statement/ while ( /Expression/ ); /VariableStatement/
> → do /Block/ while ( /Expression/ ); /VariableStatement/
> → …
> → do {} while ( true ); var x = 3;
> to insert the semicolon before the /VariableStatement/. It's not a bug,
> it's a feature, and a standards-compliant feature at that.
I suppose I'm still missing something because my understanding of this
explanation is that a semicolon should be inserted for
/VariableStatement/ /VariableStatement/
as it's one of the "certain statements", but it isn't. If the newline
is removed from the variable statement example above:
var x = 3 var y = 4
then a syntax error is thrown. I can't see how the second "var" can be
interpreted as anything other than the start of a variable statement,
and therefore that a semicolon can (or should) be inserted before it
(per your logic above).
The only explanation I can think of is that the "v" at the start of
the second "var" is interpreted as the start of an identifier, so
either a semicolon, comma[1] or newline (which would force semicolon
insertion) is required. Because of the ambiguity, an error results, so
the whole "var" token is not read and the second variable statement
isn't identified.
1. Allowing for the fact that if a comma is inserted, it only gets one
step further because the var keyword can only appear at the start of a
variable declaration statement.
Regarding references, I use the Github version of ES5 because it also
links to other resources and has some handy features that aren't
available in the ECMA version. As far as I know, the text is unaltered
from the official version.
>> because `var' delimits a /VariableStatement/ and the parser is allowed,
>> in order to produce
>> /Program/
>> → /SourceElements_opt/
>> → /SourceElements/ /SourceElement/
>> → /SourceElement/ /SourceElement/
>> → /Statement/ /Statement/
>> → /IterationStatement/ /VariableStatement/
>> → do /Statement/ while ( /Expression/ ); /VariableStatement/
>> → do /Block/ while ( /Expression/ ); /VariableStatement/
>> → …
>> → do {} while ( true ); var x = 3;
>> to insert the semicolon before the /VariableStatement/.
To be precise, after the closing parenthesis of a supposed do-while statement. Function serialization, although implementation-dependent, can show this:
$ js
Rhino 1.7 release 2 2010 02 06
js> (function () { do {} while (true) var x = 3; }).toString()
function () {
do {
} while (true);
var x = 3;
}
>> It's not a bug,>it's a feature, and a standards-compliant feature at
>> that.
> I suppose I'm still missing something because my understanding of this
> explanation is that a semicolon should be inserted for
> /VariableStatement/ /VariableStatement/
> as it's one of the "certain statements", but it isn't. If the newline
> is removed from the variable statement example above:
> var x = 3 var y = 4
> then a syntax error is thrown.
ACK:
js> (function () { var x = 3 var y = 4; }).toString()
js: "<stdin>", line 3: missing ; before statement
js: (function () { var x = 3 var y = 4; }).toString()
js: ............................^
> I can't see how the second "var" can be interpreted as anything other than
> the start of a variable statement, and therefore that a semicolon can (or
> should) be inserted before it (per your logic above).
Good "question". I do not have a good answer to it yet. However:
> The only explanation I can think of is that the "v" at the start of
> the second "var" is interpreted as the start of an identifier, so
> either a semicolon, comma[1] or newline (which would force semicolon
> insertion) is required. Because of the ambiguity, an error results, so
> the whole "var" token is not read and the second variable statement
> isn't identified.
I think we can exclude that possibility. `var' is a /ReservedWord/, in particular a /Keyword/, so explicitly _not_ an /Identifier/:
| 7.6.1 Reserved Words
| | A reserved word is an IdentifierName that cannot be used as an Identifier.
| | Syntax
| | ReservedWord ::
| Keyword
| FutureReservedWord
| NullLiteral
| BooleanLiteral
| | 7.6.1.1 Keywords
| | The following tokens are ECMAScript keywords and may not be used as
| Identifiers in ECMAScript programs.
| | Syntax
| | Keyword :: one of
| break do instanceof typeof
| case else new var
| catch finally return void
| continue for switch while
| debugger function this with
| default if throw delete
| in try
On Wed, 29 Aug 2012 at 22:20:21, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
<snip>
>IOW,
> do {} while (false) var x = 3;
>*is* equivalent to
> do {} while (false); var x = 3;
>because `var' delimits a /VariableStatement/ and the parser is allowed, in
>order to produce
...
>to insert the semicolon before the /VariableStatement/. It's not a bug,
>it's a feature, and a standards-compliant feature at that.
<snip>
This is not true. If you read ECMA 262 section 7.9.1 you will see that
the gap between (false) and var does not match *any* of the
situations where a semicolon can be inserted. The lack of a semicolon is
therefore a syntax error.
Compilers that 'correct' programming errors are not being helpful. It
can take a long time to track down an obscure bug caused by the compiler
guessing wrong.
John G Harris wrote:
> Thomas 'PointedEars' Lahn wrote:
> <snip>
>>IOW,
>> do {} while (false) var x = 3;
>>*is* equivalent to
>> do {} while (false); var x = 3;
>>because `var' delimits a /VariableStatement/ and the parser is allowed, in
>>order to produce
> ...
>>to insert the semicolon before the /VariableStatement/. It's not a bug,
>>it's a feature, and a standards-compliant feature at that.
> <snip>
> This is not true. If you read ECMA 262 section 7.9.1 you will see that
> the gap between (false) and var does not match *any* of the
> situations where a semicolon can be inserted. The lack of a semicolon is
> therefore a syntax error.
> Compilers that 'correct' programming errors are not being helpful. It
> can take a long time to track down an obscure bug caused by the compiler
> guessing wrong.
For crying out loud…
| 2 Conformance
| | […]
| A conforming implementation of ECMAScript is permitted to support program
| and regular expression syntax not described in this specification. […]
This, if nothing else, is sufficient to make it standards-compliant.
PointedEars
-- Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300d...@news.demon.co.uk> (2004)
On Thu, 30 Aug 2012 at 15:59:43, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
<snip>
>For crying out loud…
>| 2 Conformance
>|
>| […]
>| A conforming implementation of ECMAScript is permitted to support program
>| and regular expression syntax not described in this specification. […]
>This, if nothing else, is sufficient to make it standards-compliant.
For crying out loud, it's still a syntax error!
Unless, of course, you have made it clear you are talking about the
syntax spec for the browser, if, of course, the browser maker has
published one that shows this feature, which it hasn't.
If you'd said it's a permitted browser deviation we would have agreed,
and then pointed out that it's a bloody stupid deviation.
John G Harris wrote:
> Thomas 'PointedEars' Lahn wrote:
>> For crying out loud…
>>| 2 Conformance
>>|
>>| […]
>>| A conforming implementation of ECMAScript is permitted to support
>>| program
>>| and regular expression syntax not described in this specification. […]
>> This, if nothing else, is sufficient to make it standards-compliant.
> For crying out loud, it's still a syntax error!
No, it would be "program […] syntax not described in this specification".
> Unless, of course, you have made it clear you are talking about the
> syntax spec for the browser, if, of course, the browser maker has
> published one that shows this feature, which it hasn't.
> If you'd said it's a permitted browser deviation we would have agreed,
> and then pointed out that it's a bloody stupid deviation.
You have no clue what you are talking about. Troll elsewhere.
PointedEars
-- Sometimes, what you learn is wrong. If those wrong ideas are close to the root of the knowledge tree you build on a particular subject, pruning the bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>
> On Thu, 30 Aug 2012 at 15:59:43, in comp.lang.javascript, Thomas
> 'PointedEars' Lahn wrote:
> <snip>
>> For crying out loud…
>> | 2 Conformance
>> |
>> | […]
>> | A conforming implementation of ECMAScript is permitted to support program
>> | and regular expression syntax not described in this specification. […]
>> This, if nothing else, is sufficient to make it standards-compliant.
> For crying out loud, it's still a syntax error!
> Unless, of course, you have made it clear you are talking about the
> syntax spec for the browser, if, of course, the browser maker has
> published one that shows this feature, which it hasn't.
> If you'd said it's a permitted browser deviation we would have agreed,
> and then pointed out that it's a bloody stupid deviation.
my original point could be restated another way:
is it at least possible that people could have implemented their parsers in ways where they didn't notice that the semicolon was missing?...
digging through the V8 source (blarg, the code is hard to read) apparently it is an explicit feature. they eat the semicolon in this case, and then have a big comment to justify doing so (although for whatever reason they use the word "consume" rather than "eat", but either way...).
similarly, their logic for "ExpectSemicolon()" is very similar to what I call "EatSemicolon()".
IOW: no semicolon is (actually) inserted into the token-stream, rather the parser merely behaves as-if the semicolon were present (if it sees a linebreak or similar instead).
reference, in V8 code (at least for the version I have at-hand, dated 2011-03-03):
v8/src/parser.cc:3775
and for the explicit do/while case:
v8/src/parser.cc:2191
checking:
Mozilla apparently also uses the same basic strategy as well:
for function "MatchOrInsertSemicolon()"
mozilla-central/js/src/jsparse.cpp:2020
>Compilers that 'correct' programming errors are not being helpful. It
...unless the compiler states what the correction being done is.
>can take a long time to track down an obscure bug caused by the compiler
>guessing wrong.
It also causes trouble when someone is learning the language.
Consistency is very very useful.
I shot myself in the foot with some very silly errors in my early
JavaScript days. Some of these were not caught very well by
JavaScript or by me. (I once used Visual FoxPro line comments in a
section of code and could not figure why the code was not working. VFP
uses "&&" like JavaScript uses "//". Egg, meet face.)
In comp.lang.javascript message <t98v38tk7cgphbcdn0tua01d87gh6ob6pt@4ax.
com>, Thu, 30 Aug 2012 10:25:45, Gene Wirchenko <ge...@ocis.net> posted:
> I shot myself in the foot with some very silly errors in my early
>JavaScript days. Some of these were not caught very well by
>JavaScript or by me. (I once used Visual FoxPro line comments in a
>section of code and could not figure why the code was not working. VFP
>uses "&&" like JavaScript uses "//". Egg, meet face.)
Reminds me of a problem a colleague had on an HP "midi" computer, using
FORTRAN but with a screen editor rather than a card punch.
One of his long COMMON statements was not working correctly. All of the
variables were in fact COMMONed, except one, at the end of the first
line. He was baffled. We were baffled. It looked fine on the screen.
Then I noticed that the offending variable and its comma were sitting
neatly in columns 73 to 80.
Perhaps you remember 80-column FORTRAN cards, and what is printed on
them? I keep one on my physical desktop for reference on occasions like
this.
>Reminds me of a problem a colleague had on an HP "midi" computer, using
>FORTRAN but with a screen editor rather than a card punch.
>One of his long COMMON statements was not working correctly. All of the
>variables were in fact COMMONed, except one, at the end of the first
>line. He was baffled. We were baffled. It looked fine on the screen.
>Then I noticed that the offending variable and its comma were sitting
>neatly in columns 73 to 80.
If the statement looked fine for syntax, that is the first thing
that I would look at. I heard a lot of these stories, so I am
sensitised to the issue.
>Perhaps you remember 80-column FORTRAN cards, and what is printed on
>them? I keep one on my physical desktop for reference on occasions like
>this.
Quite.
In my computing diploma program, two course had COBOL. I was
very careful about my columns.
>> Thomas 'PointedEars' Lahn wrote:
>>> For crying out loud…
>>>| 2 Conformance
>>>|
>>>| […]
>>>| A conforming implementation of ECMAScript is permitted to support
>>>| program
>>>| and regular expression syntax not described in this specification. […]
>>> This, if nothing else, is sufficient to make it standards-compliant.
>> For crying out loud, it's still a syntax error!
>No, it would be "program […] syntax not described in this specification".
Which is another way of saying "it's a permitted browser deviation" from
the standard.
>> Unless, of course, you have made it clear you are talking about the
>> syntax spec for the browser, if, of course, the browser maker has
>> published one that shows this feature, which it hasn't.
>> If you'd said it's a permitted browser deviation we would have agreed,
>> and then pointed out that it's a bloody stupid deviation.
>You have no clue what you are talking about. Troll elsewhere.
Hurling abuse at everyone who disagrees with you is not the most
convincing way to conduct an argument.
In comp.lang.javascript message <pUtdvpEWYeQQF...@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Sat, 1 Sep 2012 11:40:22, John G Harris
<j...@nospam.demon.co.uk> posted:
>Hurling abuse at everyone who disagrees with you is not the most
>convincing way to conduct an argument.
If you visit Regent's Park, I think you will find that the method is
favoured by /Pan troglodytes/, but perhaps not by /Pan paniscus/.
-- (c) John Stockton, nr London, UK. For Mail, see Home Page. Turnpike, WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.
