Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #33440 > unrolled thread

Re: x === x

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-30 14:34 +0100
    Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-30 15:02 +0100
    Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-30 16:22 +0200
      Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-31 01:02 +0100
        Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-31 12:39 +0200
          Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-31 21:52 +0100
            Re: x === x Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-05-31 23:39 +0200
              Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 01:46 +0100
                Re: x === x Julio Di Egidio <julio@diegidio.name> - 2017-06-01 00:14 -0700
                  Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-06-01 10:39 +0100
                    Re: x === x Julio Di Egidio <julio@diegidio.name> - 2017-06-01 03:37 -0700
                      Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-06-01 18:54 +0100
                        Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 21:54 +0100
                          Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-06-02 11:06 +0100
                          Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-06-02 11:08 +0100
                        Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-06-02 10:56 +0100
                          Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-04 12:50 +0100
                            Re: x === x John G Harris <niam@jghnorth.org.uk.invalid> - 2017-06-04 14:30 +0100
                              Re: x === x Dr J R Stockton <J.R.Stockton@physics.org> - 2017-06-04 09:03 -0700
                  Re: x === x Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 14:45 +0100
                    Re: x === x Julio Di Egidio <julio@diegidio.name> - 2017-06-01 07:00 -0700
          Re: x === x Julio Di Egidio <julio@diegidio.name> - 2017-06-01 00:00 -0700

Page 1 of 2  [1] 2  Next page →

#33440 — Re: x === x

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   In mathematics, usually, when »...« is a certain term, we have
>
> ... === ...
>
>   for the same term left and right.
>
>   In JavaScript, this does not always hold for expressions, albeit
>   possibly sometimes for different reasons:
>
> Math.random() === Math.random()
> NaN === NaN
> [] === []
> ( {} === {} )
> ( ()=>0 )===( ()=>0 )
>
>   In the first case, we cannot be sure that it will evaluate to
>   »false«, but this is is possibly.
>
>   The last three cases are similar, but it is also remarkable 
>   how one needs to add parentheses: no parens required for the
>   array, outer parens for the objects,

What's wrong with {} === {}?

> and two pairs of parens for the functions.

This one makes sense.  You are much more likely to want === in the body
of the arrow function so you want the grammar to cause (x) => x ===
... to mean (x) => (x === ...) rather than ((x) => x) === ...

-- 
Ben.

[toc] | [next] | [standalone]

#33443

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>What's wrong with {} === {}?
>
>   It depends on the context.
>
>   In a context, where a statement can begin, an opening
>   brace might be deemed to be the start of a block.

Oh, I see.  I though you meant they were required (your use of "needs"
suggested that that's what you meant).

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#33445

Stefan Ram wrote:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> What's wrong with {} === {}?
> 
>   It depends on the context.

No, it does not.  “===” *makes* the (expression) context.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33447

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Stefan Ram wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> What's wrong with {} === {}?
>> 
>>   It depends on the context.
>
> No, it does not.  “===” *makes* the (expression) context.

$ nodejs -c -e '[] === [];' && echo "ok" 
ok
$ nodejs -c -e '{} === {};' && echo "ok" 
[eval]:1
{} === {};
   ^^^

SyntaxError: Unexpected token ===
<snip trace-back>
$ nodejs -c -e '({} === {});' && echo "ok"                        ✘
ok

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#33448

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Stefan Ram wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> What's wrong with {} === {}?
>>>   It depends on the context.
>> No, it does not.  “===” *makes* the (expression) context.
> 
> $ nodejs -c -e '[] === [];' && echo "ok"
> ok
> $ nodejs -c -e '{} === {};' && echo "ok"
> [eval]:1
> {} === {};
>    ^^^
> 
> SyntaxError: Unexpected token ===
> <snip trace-back>
> $ nodejs -c -e '({} === {});' && echo "ok"                        ✘
> ok

Fascinating.  I had tried in the Chrome DevTools Console, and there the 
trailing semicolon makes the difference:

| > {} === {}
| <- false
| {} === {};
| (x) Uncaught SyntaxError: Unexpected token ===

I assume that the explicit semicolon there is considered an /EmptyStatement/ 
that switches back to statement context.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33458

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Stefan Ram wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> What's wrong with {} === {}?
>>>>   It depends on the context.
>>> No, it does not.  “===” *makes* the (expression) context.
>> 
>> $ nodejs -c -e '[] === [];' && echo "ok"
>> ok
>> $ nodejs -c -e '{} === {};' && echo "ok"
>> [eval]:1
>> {} === {};
>>    ^^^
>> 
>> SyntaxError: Unexpected token ===
>> <snip trace-back>
>> $ nodejs -c -e '({} === {});' && echo "ok"                        ✘
>> ok
>
> Fascinating.  I had tried in the Chrome DevTools Console, and there the 
> trailing semicolon makes the difference:
>
> | > {} === {}
> | <- false
> | {} === {};
> | (x) Uncaught SyntaxError: Unexpected token ===
>
> I assume that the explicit semicolon there is considered an /EmptyStatement/ 
> that switches back to statement context.

I can't find any reference to "statement context" or "expression
context" in the language standard.  I assume it's your own terminology,
but I don't see how it helps explain why [] === []; is OK but {} === {};
is a syntax error.  (I know why, I'm just wondering how talking about
=== making expression context and ; switching back helps to explain this
difference.)

Just

  {} === {}

both on it's own and with a semicolon, is a syntax error because it is
not a /Script/ (or a /Module/).  It's not a /Script/ because none of the
options for a /Statement/ apply.  There is an explicit exemption that
prevents an /ExpressionStatement/ (the only reasonable candidate[1])
from staring with a {.  On the other hand

  [] === []

(again, with or without a semicolon) does parse as a /Script/ because it
*is* an /ExpressionStatement/.

The trouble with testing witch a REPL is that there is no standard that
mandates what the reader in such a loop should be expecting.

[1] Unfortunately, when explaining why something isn't valid syntax, you
should, formally, say why it is not any of the possible options.  I hope
it's clear that I'm just applying a short-cut by talking about "the only
reasonable candidate".  It's obviously not a /BlockStatement/ or a
/VariableStatement/ or a ... and so on but, were it not for the
exemption, it looks most like an /ExpressionStatement/.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#33460

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> | > {} === {}
>> | <- false
>> | {} === {};
>> | (x) Uncaught SyntaxError: Unexpected token ===
>>
>> I assume that the explicit semicolon there is considered an
>> /EmptyStatement/ that switches back to statement context.
> 
> I can't find any reference to "statement context" or "expression
> context" in the language standard.  I assume it's your own terminology,
> but I don't see how it helps explain why [] === []; is OK but {} === {};
> is a syntax error.  (I know why, I'm just wondering how talking about
> === making expression context and ; switching back helps to explain this
> difference.)

Simply put, ECMAScript syntax is ambiguous, and it depends on the context 
how it is parsed.  For example, “{}” can be parsed either as an empty 
/Block/ *statement* (which can only be produced by the /Statement/ 
production) or as an empty Object initializer; the latter is an *expression* 
(it can only be produced by the /Expression/ production).  A further 
complication is the /ExpressionStatement/ production (IIRC).
 
I will consider the rest of your posting later.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#33462

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> | > {} === {}
>>> | <- false
>>> | {} === {};
>>> | (x) Uncaught SyntaxError: Unexpected token ===
>>>
>>> I assume that the explicit semicolon there is considered an
>>> /EmptyStatement/ that switches back to statement context.
>> 
>> I can't find any reference to "statement context" or "expression
>> context" in the language standard.  I assume it's your own terminology,
>> but I don't see how it helps explain why [] === []; is OK but {} === {};
>> is a syntax error.  (I know why, I'm just wondering how talking about
>> === making expression context and ; switching back helps to explain this
>> difference.)
>
> Simply put, ECMAScript syntax is ambiguous, and it depends on the context 
> how it is parsed.  For example, “{}” can be parsed either as an empty 
> /Block/ *statement* (which can only be produced by the /Statement/ 
> production) or as an empty Object initializer; the latter is an *expression* 
> (it can only be produced by the /Expression/ production).  A further 
> complication is the /ExpressionStatement/ production (IIRC).

I am reasonably sure that ECMAScript syntax is not ambiguous (at least
on this matter).  Can you cite the parts of the syntax that leads to it
being ambiguous?  Alternatively, can you give an ECMAScript script which
is ambiguous?  The grammar is gruesome, so maybe they committee did slip
up.

> I will consider the rest of your posting later.

This part of my post was about what you mean by "=== *makes* the
(expression) context" and what "switches back to statement context"
means (or, more specifically, how those phrases help explain what's
going on).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#33468

On Thursday, 1 June 2017 02:46:08 UTC+2, Ben Bacarisse  wrote:

> I am reasonably sure that ECMAScript syntax is not ambiguous (at least
> on this matter).

You just don't know shit, certainly on this matter.

Julio

[toc] | [prev] | [next] | [standalone]

#33469

On Thu, 1 Jun 2017 00:14:10 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Thursday, 1 June 2017 02:46:08 UTC+2, Ben Bacarisse  wrote:
>
>> I am reasonably sure that ECMAScript syntax is not ambiguous (at least
>> on this matter).
>
>You just don't know shit, certainly on this matter.

The syntax specification is unambiguous if you include the parts of
the specification that are outside the formal BNF notation.

For instance, the rule about
  if then if then else
that says which if the else belongs to.

Some ignorant people think that if it isn't in BNF then it isn't a
syntax rule. They are wrong.

  John

[toc] | [prev] | [next] | [standalone]

#33470

On Thursday, June 1, 2017 at 11:39:16 AM UTC+2, John G Harris wrote:
> On Thu, 1 Jun 2017 00:14:10 -0700 (PDT), Julio Di Egidio
> <julio@diegidio.name> wrote:
> >On Thursday, 1 June 2017 02:46:08 UTC+2, Ben Bacarisse  wrote:
> >
> >> I am reasonably sure that ECMAScript syntax is not ambiguous (at least
> >> on this matter).
> >
> >You just don't know shit, certainly on this matter.
> 
> The syntax specification is unambiguous

It isn't: the most obvious example being the optionality of the semi-colon
to end statements, which makes some constructs indeed ambiguous.  But this
is well known among the practitioners, hence best practices like "always
use the semi-colon", "never put a newline after a 'return'", and similar,
which indeed work around the (few) inconsistencies in the language.

> if you include the parts of
> the specification that are outside the formal BNF notation.

Eh?

Julio

[toc] | [prev] | [next] | [standalone]

#33483

On Thu, 1 Jun 2017 03:37:49 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Thursday, June 1, 2017 at 11:39:16 AM UTC+2, John G Harris wrote:
>> On Thu, 1 Jun 2017 00:14:10 -0700 (PDT), Julio Di Egidio
>> <julio@diegidio.name> wrote:
>> >On Thursday, 1 June 2017 02:46:08 UTC+2, Ben Bacarisse  wrote:
>> >
>> >> I am reasonably sure that ECMAScript syntax is not ambiguous (at least
>> >> on this matter).
>> >
>> >You just don't know shit, certainly on this matter.
>> 
>> The syntax specification is unambiguous
>
>It isn't: the most obvious example being the optionality of the semi-colon
>to end statements, which makes some constructs indeed ambiguous.  But this
>is well known among the practitioners, hence best practices like "always
>use the semi-colon", "never put a newline after a 'return'", and similar,
>which indeed work around the (few) inconsistencies in the language.
>
>> if you include the parts of
>> the specification that are outside the formal BNF notation.
>
>Eh?

It seems I have to say it again :

Some ignorant people think that if it isn't in BNF then it isn't a
syntax rule. They are wrong.

That's why the behaviour of newline after 'return' isn't an ambiguity.
The rule for this case is clearly stated in the specification. 

Etc. Etc.

  John

[toc] | [prev] | [next] | [standalone]

#33485

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> John G Harris <niam@jghnorth.org.uk.invalid> writes:
>>It seems I have to say it again :
>>Some ignorant people think that if it isn't in BNF then it isn't a
>>syntax rule. They are wrong.
>
>   Depending on the definition of »syntax rule«, you might
>   be right with this.

Most languages have two grammars -- a simple grammar for tokens (it is
often "regular" in the technical sense) and a more complex grammar of
tokens that describes the syntax of the larger units -- programs in
effect.

ECMAScript is one of these.  The semicolon insertion rules operate at
the lexical level.  The tokens seen by the parser will, logically,
already include any added semicolons.

Finally, ECMAscript also has lookahead conditions that direct the
parse.  These are a convenience (just like its labeled EBNF) that means
the EBNF rules can be much shorter.

There may also be rules that are written out only in English.  C and C++
have these, and ECMAScript /might/ have -- I've not checked the whole
document.

All of these contribute to "the syntax".

>>That's why the behaviour of newline after 'return' isn't an ambiguity.
>
>   But the behavior clearly is part of the semantics 
>   (not of the syntax) of a programming language.
>
>   (Also, I am not aware of a definition of »ambiguity«
>   in this thread. When does one say that a behavior is
>   an ambiguity? [intended as a rhetorical question - 
>   so it would not be considered impolite by me if you
>   do not respond to it.])

No, that is a problem.  I'd like to see examples because that would help
clarify what people mean, both by "the syntax" and "ambiguous".
Obviously no serious programming language has an ambiguous syntax when
all the parts above are considered.

None the less it's not unreasonable to say that C's grammar (note the
term) is ambiguous, because

  x(y);

could be a function call or declaration if f is a typedef name.  The
EBNF grammar is not enough to resolve the ambiguity.

>   By your spelling of »behavior« you seem to indicate
>   that you might come from England. I used to believe
>   that englishmen always try to be extraordinarily
>   courteous. In this case the following hint might help:
>
>   The paragraph 
>
>       »Some ignorant people think that if it isn't in 
>       BNF then it isn't a syntax rule. They are wrong.«
>
>   can be reworded (removing "ignorant people") as
>
>       »Not all syntax rules are expressed in BNF.«

True.  I suspect John G Harris is simply fed up with Julio Di Egidio
habit of spinning off into abuse at the first sign of disagreement.  I
try to remain civil, but that in itself probably comes over as rude
since it can appear to be passive-aggressive.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#33489

On Thu, 01 Jun 2017 21:54:08 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

  <snip>
>There may also be rules that are written out only in English.  C and C++
>have these, and ECMAScript /might/ have -- I've not checked the whole
>document.

See, for instance, ES7, section 11, second sentence :

"The source text is scanned from left to right, repeatedly taking the
longest possible sequence of code points as the next input element."

Also section 13.6 :

"Each else for which the choice of associated if is ambiguous shall be
associated with the nearest possible if that would otherwise have no
corresponding else."

It's using ambiguous to mean BNF ambiguous :-(


  <snip>
>True.  I suspect John G Harris is simply fed up with Julio Di Egidio
>habit of spinning off into abuse at the first sign of disagreement.  I
>try to remain civil, but that in itself probably comes over as rude
>since it can appear to be passive-aggressive.

Yup. I felt I was being remarkably polite.

  John

[toc] | [prev] | [next] | [standalone]

#33490

On 1 Jun 2017 21:41:58 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

  <snip>
>  (I should have written "Englishmen", with an upper-case E.)

"English people" would have been less sexist :-)

  John

[toc] | [prev] | [next] | [standalone]

#33488

On 1 Jun 2017 18:21:12 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>John G Harris <niam@jghnorth.org.uk.invalid> writes:
>>It seems I have to say it again :
>>Some ignorant people think that if it isn't in BNF then it isn't a
>>syntax rule. They are wrong.
>
>  Depending on the definition of »syntax rule«, you might
>  be right with this.

The way I see it is this : The BNF selects a subset of all possible
finite character strings, including all valid programs and some that
aren't; then additional rules select a sub-subset comprising all the
syntactically valid programs.

I define the "syntax rules" to be the collection of rules that
describe valid syntax.


>>That's why the behaviour of newline after 'return' isn't an ambiguity.
>
>  But the behavior clearly is part of the semantics 
>  (not of the syntax) of a programming language.

I was using "behaviour" to describe programmers' behaviour, as
mentioned by Julio. Here it would be clearer to say "rule about"
instead.


>  (Also, I am not aware of a definition of »ambiguity«
>  in this thread. When does one say that a behavior is
>  an ambiguity? [intended as a rhetorical question - 
>  so it would not be considered impolite by me if you
>  do not respond to it.])

Again, Julio was complaining about programmers having to do something
because semicolons can be left out.

For a definition, a language is ambiguous if two conforming
implementations give different results without that being explicitly
sanctioned by the specification.


>  By your spelling of »behavior« you seem to indicate
>  that you might come from England. I used to believe
>  that englishmen always try to be extraordinarily
>  courteous. In this case the following hint might help:
>
>  The paragraph 
>
>      »Some ignorant people think that if it isn't in 
>      BNF then it isn't a syntax rule. They are wrong.«
>
>  can be reworded (removing "ignorant people") as
>
>      »Not all syntax rules are expressed in BNF.«.

Ignorant can be a description, as here. It doesn't have to be an
insult.

  John

[toc] | [prev] | [next] | [standalone]

#33499

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>Brendan Eich still thinks today that this was a good idea.
>
>   (automatic semicolon insertion)
>
>       »But insisting on Java's class and type declarations, or
>       on a semicolon after each statement when a line ending
>       would do, was out of the question - scripting for most
>       people is about writing short snippets of code, quickly
>       and without fuss«
>
>     Brendan Eich, 2001

I'm sure you are right, but the quote does not support the claim.  It's
in the past tense so in 2001 he thought it *was* the right thing to do.
It's also a rather old quote in that the rules have since got more
complicated.  One can imagine (note: only imagine -- I doubt this is his
opinion at all) an update to that quote:

  "scripting ... is about writing short snippets of code, quickly and
  without fuss" <fake quote:> and the syntax that has since been added
  means that writing scripts without fuss is now much easier with
  explicit semicolons.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#33500

On Sun, 04 Jun 2017 12:50:18 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

  <snip>
>  "scripting ... is about writing short snippets of code, quickly and
>  without fuss" <fake quote:> and the syntax that has since been added
>  means that writing scripts without fuss is now much easier with
>  explicit semicolons.

Alternatively, nowadays ECMAScript is very seldom used to write
*short* snippits of code. (See almost any website).

  John

[toc] | [prev] | [next] | [standalone]

#33502

On Sunday, June 4, 2017 at 2:30:34 PM UTC+1, John G Harris wrote:
> On Sun, 04 Jun 2017 12:50:18 +0100, Ben Bacarisse wrote:
> 
>   <snip>
> >  "scripting ... is about writing short snippets of code, quickly and
> >  without fuss" <fake quote:> and the syntax that has since been added
> >  means that writing scripts without fuss is now much easier with
> >  explicit semicolons.
> 
> Alternatively, nowadays ECMAScript is very seldom used to write
> *short* snippits of code. (See almost any website).


Undoubtedly.  The Web is, however, not the only place where JavaScript is used.  I wrote the insertion code referred to at the end of the current last article in thread "Instead of iframe onload?" using under 30 lines of script - admittedly, that runs in WSH, and thus is presumably JScript.

-- 
  (c) John Stockton, near London, UK.  Using Google, no spell-check. |
 Mail: J.R.""""""""@physics.org                                      |

[toc] | [prev] | [next] | [standalone]

#33473

Julio Di Egidio <julio@diegidio.name> writes:

> On Thursday, 1 June 2017 02:46:08 UTC+2, Ben Bacarisse  wrote:
>
>> I am reasonably sure that ECMAScript syntax is not ambiguous (at least
>> on this matter).
>
> You just don't know shit, certainly on this matter.

On this matter specifically (the interpretation of { at the start of an
ExpressionStatement), the syntax appears to be very clear and
unambiguous.

Can you give an example of a Script (or Module) where the syntax permits
more than one valid parse?  That would clarify what you consider to be
"the syntax".  Presumably you are discounting, as syntax, one or more of
the rules that I consider to part of it.

Alternatively you could be rude again, and I'll know not to try to
understand your position.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web