FAQ Topic - How can I create a Date object from a String? (2011-02-15)

[Evertjan.]

Stefan Weiss wrote on 17 feb 2011 in comp.lang.javascript:

So, if I understand you correctly, you define the term "statement"
according to your own understanding of what a statement ought to be.

"ought"?

Not at all.

I claim that I, with a long time experience with many scripting and
compiling languages, PERSONALLY give a meaning to the word "statement"
but though I think it is a very usable definition, do not say that others
must accept this ["ought"].

I only use this word "statement" to have a word for my explanation that
al of the things in Javascript that I call a "statement" are better off
ALWAYS ending with a ; in the sense that it gives a more understandable
and readable sourse code, readable like indentation does too.

I further prove my point by showing that the if-construct, which is
perhaps [wrongly called an if-statement, wrongly only because it leads
some of you to think the word "statement" is defined by that], quot non
in my opinion, is wrongly implemented, because an inner if-construct
without an else cannot be set inside an outer if-constuct without
aditional {}, which I think is absurt, so the implementation or the specs
are in error in my opinion.

Then you use this personal definition to claim that the language
standard, all of the JS implementations, all the languages from which
the JS-syntax is derived, and all the other people in this thread are
wrong.

I do not claim the standard, but try to show my vision on what the
standard could be.

Is this forbidden to have a view about the standard?

Can a standard evolve without people having a view that differs from the
view that the standard [if it is] is the best achievable for ever after?

I can't really argue against a position like that.

There is no reason to argue against me having that position, however you
are free to state that my view is not a correct view, if you bring in
contradicting arguments or show the falacy of my view.

I think it's a very stubborn way to think,

What is stubborn about having a view of a language and stating that in my
view which is accompanied with valid [to me] arguments?

"Stubbornness" is that one argues against people that have the right to
order one to change meaning [like parents claim to have in some cultures,
or believes] without using reasoning and logic to try to convince.

and also very unpractical if you want to
communicate with other people, but if neither the standard nor
real-life examples will convince you, fine.

Thank you that you say "fine", but it contradicts with "stubbonness".

Why should the standard convince me that is what the language ought to
be?

Why should real-time ecamples of such standard prohibit to have a view
about what the language ought to be?

I gave examples were the implementation is clearly wrong [in my opinion].

What is unpractical about not conforming?

Sure if you want an easy live and not bother with the truth as you see
it, but is that the optimum of practricality?

I hope you understand at least that your idea of "pretty code" is in
the minority,

Since when is truth defined by the ideas of the majority?

"Whenever you find yourself on the side of the majority, it's time to
pause and reflect." - Mark Twain

Truce can only be approximated by discussion of differing arguments,
but consensus is not a necesary endpoint, as differing opinions are
possible.

Beauty is in the eye of the newbie holder or something, but this is not
only about pretty code but about a view how a language should be and how
a language can easily be shown to newbies.

and not supported by anything other than your personal
aesthetic preferences.

Not true, I gave examples that were not contradicted.

But what is wrong with having a language that is both logical consistant
and aesthetic?

It's unlikely that the FAQ examples will be
changed (unless you're appointed as FAQ maintainer, of course .

Which would be a pity, but do you realy think I have a wish to conform
that is so strong that I would relinquish my view of improving Javascript
were it is used inconsistent at present, as in the example of cascading
if-constructs?

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote on 17 feb 2011 in comp.lang.javascript:


Untrue in my view. My definition of statement is not changed by your
definition of the if-statement.

No, but I wrote "in ECMAScript", specifying which definition of
"statement" I was referring to, so it was not about your definition.
I even emphasized this.
In ECMAScript (the language defined by the specification, including
the specification's internal definition of the syntactic category
"Statement") a following semicolon after a block statement is not
part of that statement, nor is it part of an if-statment containing
that block.

That is true, independent of what view you might have on what
statements are, because it's stated in terms of a specific definition
of statements.
You can say it's an implication. Even if you disagree with the
premisse of the implication, the implication can still be true.

Ofcourse, if the de definition of the fi-statement says that the ; is not
a necessary part of such, the if-statement ends without that statement,
and the parser can do without. But that is BECAUSE the language condones
the leaving out of the ; as amatter of leniancy.

Not because of leniancy. The language here follows the languages it
has inherited its syntax from, Java and C, and the C syntax is about
40 years old now, and is used in so many different languages by now
that it's almost ubiquitous
(http://en.wikipedia.org/wiki/List_of_C-based_programming_languages).

You talk about personal experience with different languages, but seem
to miss that your idea of how the syntax of a statement should be is
at odds with the majority of languages that are actually used.

That does not mean it is not an error to leave it out but that the error
will be forgiven.

No, it means that is not an error to leave it out *according to the
language specification*. That means that it's not an error.

You can argue that the specification should be different, but you
can't reasonably argue that the programs written to the specification
are in error if they follow the specification.

So that implmentation is in error,
because the implementors forgot to basic logic of a statement.

No. Your idea of "basic logic of a statement" is simply just not
generally accepted.

Describing a valid if-statement ending without
an "else" is not possible in Javascript!!!

Ofcourse it is. But not the way you want to do it.
People have been doing it for 40 years.

And that is a crazy error of the implementation either of the ECMA-
concept or the implementation!!!!

Again, blame the specification all you want, but remember to blame C
as well.

I will show you this here:

if (b) if (c) { stmt1; } else { stmt3 };

Tha above works ok, the 'else' belongs to the "inner" if.

Let us now try to have the else belong to the outer if by closing the
inner if statement:

if (b) if (c) { stmt1; }; else { stmt3 };

This gives an error while it should be perfectly logical script,
equivalent to:

if (b) { if (c) { stmt1; }; } else { stmt3 };

You say it "should" be equivalent, but that's only because of your
own preconceived ideas of statement syntax.

In the C family of languages, you write:
if (b) { if (c) { stmt1 } } else { stmt3 }
and preferably indented:
if (b) {
if (c) { stmt1 }
} else {
stmt3
}

You can try to write Fortran (or wherever your semicolon ideas come
from) in any language, but it's putting a square peg in a round hole.
Try writing ECMAScript instead.

/L

 

[Evertjan.]

Lasse Reichstein Nielsen wrote on 18 feb 2011 in comp.lang.javascript:

No, but I wrote "in ECMAScript", specifying which definition of
"statement" I was referring to, so it was not about your definition.
I even emphasized this.
In ECMAScript (the language defined by the specification, including
the specification's internal definition of the syntactic category
"Statement") a following semicolon after a block statement is not
part of that statement, nor is it part of an if-statment containing
that block.

That is true, independent of what view you might have on what
statements are, because it's stated in terms of a specific definition
of statements.
You can say it's an implication. Even if you disagree with the
premisse of the implication, the implication can still be true.


Not because of leniancy. The language here follows the languages it
has inherited its syntax from, Java and C, and the C syntax is about
40 years old now, and is used in so many different languages by now
that it's almost ubiquitous
(http://en.wikipedia.org/wiki/List_of_C-based_programming_languages).

You talk about personal experience with different languages, but seem
to miss that your idea of how the syntax of a statement should be is
at odds with the majority of languages that are actually used.


No, it means that is not an error to leave it out *according to the
language specification*. That means that it's not an error.

You can argue that the specification should be different, but you
can't reasonably argue that the programs written to the specification
are in error if they follow the specification.


No. Your idea of "basic logic of a statement" is simply just not
generally accepted.


Ofcourse it is. But not the way you want to do it.
People have been doing it for 40 years.


Again, blame the specification all you want, but remember to blame C
as well.


You say it "should" be equivalent, but that's only because of your
own preconceived ideas of statement syntax.

Anything wrong with "preconceived ideas"?

Should ideas only have value if they are conceived on the spur of the
moment?

Yes, I have ideas about logic in statement syntax. No reason to dismiss
tham just because they are "preconceived", methinks.

Statements and functions are the basic tools of source scripting,
so they better have strict logic in their syntax.

In the C family of languages, you write:
if (b) { if (c) { stmt1 } } else { stmt3 }
and preferably indented:
if (b) {
if (c) { stmt1 }
} else {
stmt3
}

This is as I suggested to overcome the implementation error that the
statemt end is not recognized here.

The indentation is not part of the logic,
but "pretty" important none the less.

You can try to write Fortran (or wherever your semicolon ideas come
from) in any language, but it's putting a square peg in a round hole.
Try writing ECMAScript instead.

You seem to be personally offended that I disagree with the in my view
illogicallities that seem to have found it's way into this [group of?]
languages.

Perhaps you could try to explain that by re-introducing the concept of
new line delimiting, while the whole idea of ; delimitation is to fase
out the new line delimiting once and for all.

Things like "it is also in other languages" and "it has been so for 40
years" only give pressure to conforming, and I do not see any reason to
forgo logic in favour of conforming. Computer languages are not dogmas
but need to evolve and if necessary evolve back to logic wwere they
strayed.

 

[John G Harris]

Let us now try to have the else belong to the outer if by closing the
inner if statement:

if (b) if (c) { stmt1; }; else { stmt3 };

This gives an error while it should be perfectly logical script,
equivalent to:

if (b) { if (c) { stmt1; }; } else { stmt3 };

What about your next example :

if (b) if (c) if (d) { stmt1; }; ; else { stmt3 };


John

 

[John G Harris]

I further prove my point by showing that the if-construct, which is
perhaps [wrongly called an if-statement, wrongly only because it leads
some of you to think the word "statement" is defined by that], quot non
in my opinion, is wrongly implemented, because an inner if-construct
without an else cannot be set inside an outer if-constuct without
aditional {}, which I think is absurt, so the implementation or the specs
are in error in my opinion.

It seems you are not familiar with the history of Algol. At the first
attempt they allowed you to write

if condition1 if condition2 then statement1 else statement2

Which condition does the 'else' belong to? I don't know; you don't know;
perhaps the programmer who wrote it has forgotten by now. Algol got
round this problem by forcing you to write

if condition1 if condition2 then statement1 fi else statement2 fi

or

if condition1 if condition2 then statement1 else statement2 fi fi


Yuk! Pascal got round it by letting you write

if condition1 if condition2 then statement1 else statement2

and then specifying that the else belongs to the nearest 'if condition'
that hasn't already got an else. So it's condition2. ECMAScript has the
same rule.

Which would be a pity, but do you realy think I have a wish to conform
that is so strong that I would relinquish my view of improving Javascript
were it is used inconsistent at present, as in the example of cascading
if-constructs?

Talk about a new language if you want to, but you mustn't ask for the
FAQ to have code that's incompatible with the current language.


John

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote on 18 feb 2011 in comp.lang.javascript:

Anything wrong with "preconceived ideas"?

Should ideas only have value if they are conceived on the spur of the
moment?

Yes, I have ideas about logic in statement syntax. No reason to dismiss
tham just because they are "preconceived", methinks.

Fair enough. You have ideas about how the syntax of statements should be
which are not met by the actual syntax of ECMAScript.

Statements and functions are the basic tools of source scripting,
so they better have strict logic in their syntax.

The logic is strict. A statement can be terminated by a semicolon only
if it ends in something that looks like an expression, and therefore
looks like it could be continued by the syntax of the next statement.

In the C family of languages, you write:
if (b) { if (c) { stmt1 } } else { stmt3 }
and preferably indented:
if (b) {
if (c) { stmt1 }
} else {
stmt3
}

This is as I suggested to overcome the implementation error that the
statemt end is not recognized here.

The indentation is not part of the logic,
but "pretty" important none the less.

You can try to write Fortran (or wherever your semicolon ideas come
from) in any language, but it's putting a square peg in a round hole.
Try writing ECMAScript instead.

You seem to be personally offended that I disagree with the in my view
illogicallities that seem to have found it's way into this [group of?]
languages.

Not as such, but I accept that it can seem that way.
You are free to want any change to the syntax of ECMAScript (the
es-discuss mailing list would be the place to make the suggestion,
although I don't expect much chance of success).
What I am opposing is your suggestions, which you haven't retracted
yet, that the FAQ should write code in your preferred syntax instead
of the actual current syntax of ECMAScript. The two are not compatible.

Perhaps you could try to explain that by re-introducing the concept of
new line delimiting, while the whole idea of ; delimitation is to fase
out the new line delimiting once and for all.

Using semicolon as delimiter does allow you to put statements on
the same line that would otherwise need to be on two.
Basic used ":" for the same thing.
However, you only need the semicolon as separator, not as terminator,
for that, e.g., like Pascal syntax.

My problem is perhaps that I don't know of any language that works
the way you want it. Can you mention a few of the languages you have
experience with that require (or allow) semicolons after all statements?

Things like "it is also in other languages" and "it has been so for 40
years" only give pressure to conforming, and I do not see any reason to
forgo logic in favour of conforming. Computer languages are not dogmas
but need to evolve and if necessary evolve back to logic wwere they
strayed.

There are quite a number of new (or new-ish) languages that try other
approaches. There's Python, where you have semicolon as a separator,
but where newlines are terminators and indentation carries meaning.
(It's really a bad design to have both '{...}' blocks and indentation
to signify containment in C-like languages. That allows you to write
code where the two are out of sync, e.g.,
if (b)
stmt1;
stmt2;
which leads to bugs).

There's functional languages without statements (although they typically
have the equivalent as expressions evaluating to a null-value).

But ECMAScript is not one of these. It has a fairly traditional C-like
syntax, and as long as that stays true, programs should be written to
that syntax, or they won't work.

/L

 

[Dr J R Stockton]

On "statement" : When used in connection with JavaScript, the string
"statement" should only mean what the current ECMA standard says that it
means. For a different meaning, another unmistakably different word
should be used, such as "verklaring".



In comp.lang.javascript message <[email protected]>

Dr J R Stockton wrote on 17 feb 2011 in comp.lang.javascript:

In comp.lang.javascript message <[email protected]>

FAQ server wrote on 15 feb 2011 in comp.lang.javascript:

-----------------------------------------------------------------------
FAQ Topic - How can I create a Date object from a String?
-----------------------------------------------------------------------

An Extended ISO 8601 local Date format `YYYY-MM-DD` can be parsed to a
Date with the following:-

/**Parses string formatted as YYYY-MM-DD to a Date object.
* If the supplied string does not match the format, an
* invalid Date (value NaN) is returned.
* @param {string} dateStringInRange format YYYY-MM-DD, with year in
* range of 0000-9999, inclusive.
* @return {Date} Date object representing the string.
function parseISO8601(dateStringInRange) {
var isoExp = /^\s*(\d{4})-(\d\d)-(\d\d)\s*$/,

What nonsense not to allow a
single month or day character, yyyy-[m]m-[d]d,
and allow for external white space.

The author chose to write a validator, and ISO 8601 *requires* mm & dd.
He did not respect "Be strict in what you emit, liberal in what you
accept".

Yes perhaps, but we are writing the FAQ for newbies [ok?] and the FAQ-Q was
not about strict validation of the ISO [then the external whitespace should
be disalowed btw], but to give an example of a string parser, and in my
view also stress the importancwe of the y m d sequence.

A function called parseISO8601 should accept only what is valid in 8601.
But it ought also to accept all that is valid in 8601, including
2011-W07-5 and 2011-049T11:12:13Z.

Me too.

It will not be accepted due to the month validation statement

if (parts[1] != date.getMonth() + 1) error

I seem to remember we invented this filter years ago in this NG.

If the part matching yyyy-mm-dd is considered, it is a valid 8601 date.

So perhaps there should be a couple of \b there?

Must the Q "How can I create a Date object from a String?"
realy be answered by a strict following of Extended ISO 8601?

really.

One must use some format definition, preferably excluding FFF but
capable of easy adaptation for that.

date = new Date(NaN), month,
parts = isoExp.exec(dateStringInRange);

if(parts) {
month = +parts[2];

The + is not necessary as both following uses do automagic conversion.

Better to do the conversion once, rather than twice.

Better than adding a temporary variable?

The temporary name is quite useful as comment, and without it parts[2]
is indexed twice.

could be bet then we should discuss the meaning of beter in this context.
;-)

date.setFullYear(parts[1], month - 1, parts[3]);
if(month != date.getMonth() + 1) {
date.setTime(NaN);
}

Why not '};' ?

}
return date;
}

I suggest to forget about the rules of ISO 8601,
but to concentrate on it's usefull international acceptance
of the sequence order.

The section should say that YYYY-MM-DD is handled and that it is an
ISO8601 format.

to allow:
yyyy-[m]m-[d]d
yyyy/[m]m/[d]d
yyyy.[m]m.[d]d
yyyymmdd
and not allow external whitespace.

The Object in <http://www.merlyn.demon.co.uk/js-dobj2.htm> does rather
better than that, but uses more code.

If one is writing a liberal function, it should accept any string
containing an ISO 8601 date delimited by \s+ or \b. And a rigorous ISO
8601 Date function should optionally be allowed to accept a date part
followed by a time part, though one must then think more about the
offset from GMT.

=============================================
function parseYyyymmdd(dateString) {
var date = new Date(NaN);
dateString = dateString.replace(/(\d{4})(\d{2})(\d{2})/,'$1-$2-$3')
var parts = dateString.split(/[-/.]/);

if(parts.length==3) {
date.setFullYear(parts[0], parts[1] - 1, parts[2]);
if(parts[1] != date.getMonth() + 1) {
date.setTime(NaN);
};
};
return date;
};

Better to match as below, which is moderately flexible and slightly
tested; but external whitespace should be allowed.

For "better" see above.

We also seem to be married to Javascript for "worse".

DS = "323/11/19";

D = new Date(NaN)
M = DS.match(/\b(\d{3,})(\W)(\d\d?)(\2)(\d\d?)\b/)
if (M) { D.setFullYear(M[1], M[3]-1, M[5])
if (D.getMonth() != +M[3]-1) D.setTime(NaN) }

Personally I prefer my example if it is ment to be understood by newbies.

It could contain a simple form and a longer one. The FAQ needs more
examples of RegExps.

But there is a case not yet considered. The date may have been machine-
generated and therefore be valid and of exactly-known format.

D = new Date(SD.replace(/(....)-(..)-(..)/, "$2/$3/$1"))

??

The Article does not permit the month to be indicated by such as
Augustus or Oktober, so numeric is needed. Nor by such as VIII, so
Arabic is needed. However, since the actual Arabs use different
numbers, perhaps it should say ASCII numbers.

FYI, my js-date4.htm can read dates with months such as VIII, and js-
dobj2.htm can read/write dates with single-character Roman numerals.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Fri, 18 Feb 2011 16:49:06, John G Harris

It seems you are not familiar with the history of Algol.

Unqualified, "Algol" means Algol 60, as specified in (assuming a correct
transcription) <http://www.masswerk.at/algol60/report.htm>, Revised
Report on the Algorithmic Language Algol 60. I have read an Algol 68
book, perhaps the Report, but not recently.

At the first
attempt they allowed you to write

That might be Algol 58.

if condition1 if condition2 then statement1 else statement2

Which condition does the 'else' belong to? I don't know; you don't know;
perhaps the programmer who wrote it has forgotten by now. Algol got
round this problem by forcing you to write

if condition1 if condition2 then statement1 fi else statement2 fi

or

if condition1 if condition2 then statement1 else statement2 fi fi

In Algol 60. 'fi' is not a reserved word. In fact, in the Runge-Kutta
example just before the Index of the Report I see "Boolean fi;".
Moreover, the condition is always followed by a 'then'.

Yuk! Pascal got round it by letting you write

if condition1 if condition2 then statement1 else statement2

In Pascal, according to Jensen and Wirth, and also to Borland, the
condition is always followed by a 'then'.



My own preference, inspired by what DEC's macro-11 could do, would be to
say that a conditional statement always starts with 'if condition' and
ends with 'fi' or 'fi;' (or 'endif'). In between, there can be any
number of 'clause's. A 'clause' starts with 'then', 'else', both', or
'dont', and finishes with the beginning of the next 'clause; or 'fi'. A
'clause' contains any number of statements, including nested 'if' ...
'fi'.

The condition is evaluated and remembered. The 'clause's are handled in
turn; 'then' ones if condition true, 'else' ones if condition false,
'both' ones in either case, and 'dont' ones never. The 'dont' clause is
a form of comment; it is compiled in the usual manner, but its code is
optimised away. It can be useful in development or testing to have
source segments which you are certain will still compile, but are not
currently used; and the cost of implementing it should be insignificant.

For neatness, the clauses are al introduced by reserved words of the
same length; if 'dont' without an internal apostrophe is disliked, then
choose something else : 'nein', 'nono', 'omit', 'skip', 'miss', etc.

 

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Fri, 18 Feb 2011 16:49:06, John G Harris


Unqualified, "Algol" means Algol 60, as specified in (assuming a correct
transcription) <http://www.masswerk.at/algol60/report.htm>, Revised
Report on the Algorithmic Language Algol 60. I have read an Algol 68
book, perhaps the Report, but not recently.

I doubt if Thomas would agree.

There is a family of languages, all called Algol something. It's the
history of the family I'm talking about.

That might be Algol 58.

Well, I'm concentrating on the languages that got issued by an official
standards body : Algol 60 and Algol 68.

In Algol 60. 'fi' is not a reserved word. In fact, in the Runge-Kutta
example just before the Index of the Report I see "Boolean fi;".
Moreover, the condition is always followed by a 'then'.

Algol 60 didn't use 'fi', Algol 68 did.

In Pascal, according to Jensen and Wirth, and also to Borland, the
condition is always followed by a 'then'.

True : a typo, and also earlier. It's a long time since I used a "then"
language.

My own preference, inspired by what DEC's macro-11 could do, would be to
say that a conditional statement always starts with 'if condition' and
ends with 'fi' or 'fi;' (or 'endif'). In between, there can be any
number of 'clause's. A 'clause' starts with 'then', 'else', both', or
'dont', and finishes with the beginning of the next 'clause; or 'fi'. A
'clause' contains any number of statements, including nested 'if' ...
'fi'.

<snip>

Remember the old design principle : Keep It Simple.

The common way to say what an if statement looks like is to say that
given any expression and any two statements then you can construct
another statement by writing
if (expression) statement else statement
and also by writing
if (expression) statement
[with your choice of keywords and other literal symbols, of course].

Other kinds of statement are defined in the same way. These statements
can then be used in the construction of even longer statements. This is
a very respectable mathematical definition technique by the way.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sun, 20 Feb 2011 19:54:53, John G Harris

My own preference, inspired by what DEC's macro-11 could do, would be to
say that a conditional statement always starts with 'if condition' and
ends with 'fi' or 'fi;' (or 'endif'). In between, there can be any
number of 'clause's. A 'clause' starts with 'then', 'else', both', or
'dont', and finishes with the beginning of the next 'clause; or 'fi'. A
'clause' contains any number of statements, including nested 'if' ...
'fi'.

<snip>

Remember the old design principle : Keep It Simple.

The common way to say what an if statement looks like is to say that
given any expression and any two statements then you can construct
another statement by writing
if (expression) statement else statement
and also by writing
if (expression) statement
[with your choice of keywords and other literal symbols, of course].

Many things look simpler when possibilities and details are omitted.
What you have written would not be significantly complicated, from the
explanation point of view, if the "then" were restored and a "fi" put at
the end. As you imply, that covers the usual arrangement.

Once a specific terminator is required, there is then no need to trouble
with making a sequence of simple statements into a compound statement
with "begin" and "end" or "{" and "}". That saves explanation, and
makes it easier for a reader to see where any given "if" is finally
extinguished".

It is then easy to explain the new features; the ability to have any
number of "then" and "else" parts, in any order, between an "if" and its
"fi". Of itself, that adds little benefit; but it's easy to explain the
convenient "both" parts that can be interspersed, after which the "none"
is trivial.

The railway-track diagram, as favoured by Pascal, is then particularly
elegant.

 

[Evertjan.]

Dr J R Stockton wrote on 21 feb 2011 in comp.lang.javascript:

It is then easy to explain the new features; the ability to have any
number of "then" and "else" parts, in any order, between an "if" and its
"fi". Of itself, that adds little benefit; but it's easy to explain the
convenient "both" parts that can be interspersed, after which the "none"
is trivial.

The facultative "else" is a problem in many languages,
it is part of the idea that if is a sort of switch statement with a
restgroup. Early if-constructs did not have an else, since they did not
have a statement, only a "if true goto a numbered or labeled line".

You can imagine that any "if (boolean) statement"
leaves a stack item on an internal stack saying "expect possible else now"
and you will have to define when that stack item can safely be discarded
when not used.

if (boolean1) if (boolean2) statement fi else statement fi;
if (boolean1) if (boolean2) statement else statement fi fi;

... are implementable solutions, but not backwards compatible, so we better
get used to using statemnt levels:

if (boolean1) { if (boolean2) statement } else statement;
if (boolean1) { if (boolean2) statement else statement };

another [programmer error prone] possibility is to use empty else-es:

if (boolean1) if (boolean2) statement else noop else statement;
if (boolean1) if (boolean2) statement else statement else noop;

 

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sun, 20 Feb 2011 19:54:53, John G Harris

My own preference, inspired by what DEC's macro-11 could do, would be to
say that a conditional statement always starts with 'if condition' and
ends with 'fi' or 'fi;' (or 'endif'). In between, there can be any
number of 'clause's. A 'clause' starts with 'then', 'else', both', or
'dont', and finishes with the beginning of the next 'clause; or 'fi'. A
'clause' contains any number of statements, including nested 'if' ...
'fi'.

<snip>

Remember the old design principle : Keep It Simple.

The common way to say what an if statement looks like is to say that
given any expression and any two statements then you can construct
another statement by writing
if (expression) statement else statement
and also by writing
if (expression) statement
[with your choice of keywords and other literal symbols, of course].

Many things look simpler when possibilities and details are omitted.
What you have written would not be significantly complicated, from the
explanation point of view, if the "then" were restored and a "fi" put at
the end. As you imply, that covers the usual arrangement.

The designers of several languages, such as Algol 60 and ECMAScript,
decided to say that the condition/then and else were each followed by
exactly one statement. We hope that this was decided after some thought.

As you say, if an 'if' statement ends with 'fi' or similar then the
condition/then and else can each be followed by none or more statements.

You are now morally obliged to do the same, with different new keywords,
to 'do', 'while', 'for', 'with', and 'try' statements. A lot of people
wouldn't like it, me included.

Once a specific terminator is required, there is then no need to trouble
with making a sequence of simple statements into a compound statement
with "begin" and "end" or "{" and "}". That saves explanation, and
makes it easier for a reader to see where any given "if" is finally
extinguished".

But the fact that a compound statement is a statement has to be
explained anyway, at least in languages that have blocks. Unfortunately,
the weaker students don't understand this, including, I regret to say,
two lecturers who wrote Pascal and C++ textbooks.

It is then easy to explain the new features; the ability to have any
number of "then" and "else" parts, in any order, between an "if" and its
"fi". Of itself, that adds little benefit; but it's easy to explain the
convenient "both" parts that can be interspersed, after which the "none"
is trivial.

The railway-track diagram, as favoured by Pascal, is then particularly
elegant.

Yes, they are elegant and easier to follow, but you can't post them to
this news group. (ASCII art is not acceptable when there's a choice of
fonts).


John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>

You can imagine that any "if (boolean) statement"
leaves a stack item on an internal stack saying "expect possible else now"
and you will have to define when that stack item can safely be discarded
when not used.

Yes. The item can be removed at the end of the statement which the "if"
starts. That must, AFAICS, be true in any structured language.

As an optimisation, it can be removed earlier; after the last "then" of
"else". But little will be gained, and for debugging ISTM that the
Boolean should be inspectable during the entire statement "if" ... "fi".

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Tue, 22 Feb 2011 16:47:26, John G Harris

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Sun, 20 Feb 2011 19:54:53, John G Harris

My own preference, inspired by what DEC's macro-11 could do, would be to
say that a conditional statement always starts with 'if condition' and
ends with 'fi' or 'fi;' (or 'endif'). In between, there can be any
number of 'clause's. A 'clause' starts with 'then', 'else', both', or
'dont', and finishes with the beginning of the next 'clause; or 'fi'. A
'clause' contains any number of statements, including nested 'if' ...
'fi'.
<snip>

Remember the old design principle : Keep It Simple.

The common way to say what an if statement looks like is to say that
given any expression and any two statements then you can construct
another statement by writing
if (expression) statement else statement
and also by writing
if (expression) statement
[with your choice of keywords and other literal symbols, of course].

Many things look simpler when possibilities and details are omitted.
What you have written would not be significantly complicated, from the
explanation point of view, if the "then" were restored and a "fi" put at
the end. As you imply, that covers the usual arrangement.

The designers of several languages, such as Algol 60 and ECMAScript,
decided to say that the condition/then and else were each followed by
exactly one statement. We hope that this was decided after some thought.

In the case of Algol 60, I'm sure you are right, because (after 1960) I
came to know one of the authors of the report. He would not have done
otherwise. I never met Wirth; but the same conclusion must apply to
Pascal.

But ECMAScript is a lash-up of scriptable C; I cannot believe that it
was really designed before it was written.

AISB?, the form I suggest matches that used in DEC Macro-11; and DEC was
a thoughtful company.

As you say, if an 'if' statement ends with 'fi' or similar then the
condition/then and else can each be followed by none or more statements.

You are now morally obliged to do the same, with different new keywords,
to 'do', 'while', 'for', 'with', and 'try' statements. A lot of people
wouldn't like it, me included.

It does not offer much advantage to the writer of code. It would help
the reader of code. When a block grows long, I sometimes make that
discrimination in comment; e.g.
} // end J loop

ISTR using a language in which the keyword "end" opened comment,
terminated only by a semicolon, another "end", or an "else" - Yes, Algol
60 report, 2.3 Delimiters, end. A useful feature, as a brief comment
there carried negligible lexical overhead.

I see only three reasonable possibilities for the terminating word; the
reverse of the opening one, 'end'+opener, and a mixture of those. A
kindly implementation would accept both in each case.

On the same basis HTML/DOM/CSS/ECMA are uncourteously written; more
thoughtful designers would have treated "centre" and "center" as
equivalent, and such few other cases as "colour", ... .

But the fact that a compound statement is a statement has to be
explained anyway, at least in languages that have blocks. Unfortunately,
the weaker students don't understand this, including, I regret to say,
two lecturers who wrote Pascal and C++ textbooks.

A block does not need to be defined as containing a single statement; it
can in the same way be given an opener and a closer, such as "begin" and
"end". In the case of procedures, the block-ness can be implicit.

Yes, they are elegant and easier to follow, but you can't post them to
this news group. (ASCII art is not acceptable when there's a choice of
fonts).

Usenet News is a fixed-width medium, and so by tradition is computer
programming. Anyone who reads News in a system which cannot display
fixed-pitch deserves to suffer the consequences. This newsreader has a
menu item to toggle the choice. Even Google can do it; more options,
show original.

 

[Evertjan.]

Dr J R Stockton wrote on 23 feb 2011 in comp.lang.javascript:

In comp.lang.javascript message
<[email protected]> , Tue, 22 Feb 2011 10:35:42,


Yes. The item can be removed at the end of the statement which the
"if" starts. That must, AFAICS, be true in any structured language.

So then Javascript is not structured in your definition,
because it is not clear when the if-statement ends,
but by the start of a next statement.
I think that is not structured in my book,
because the statement itself should show it's own end.

Look at:

if (boolean) if (boolean) statement else statement;

The latter does not define in itself which if is served by the else.
You could define it is the inner one, but how would you write the code if
it is the outer one?

if (boolean) if (boolean) statement ; else statement;

That does not look very logical and asks for programming errors.

As an optimisation, it can be removed earlier; after the last "then"
of "else". But little will be gained, and for debugging ISTM that the
Boolean should be inspectable during the entire statement "if" ...
"fi".

I think the omission of the fi word in Javascript is a serious error,
"fi" meaning among other things "remove possible else-expectancy from the
stack", but there could have been a better solution,seen that Javascript
never has closing reserved-words, by introdusing "ifelse" next to "if":

So for ifs with elses:

ifelse (boolean)
executeifTRUEstatement
executeifFALSEstatement;

and without elses:

if (boolean)
executeifTRUEstatement;

This is more in line with Javascript structure and allows for very
complex if-levels if desired.

Alas, this is not to be in Javascript, methinks,
as backwards compatibility could not easily be achieved,
and the devided powers-that-be would never implement such in unison.

 

[Tim Streater]

Usenet News is a fixed-width medium, and so by tradition is computer
programming.

I've long since dispensed with that tradition in programming.

 

[Thomas 'PointedEars' Lahn]

I've long since dispensed with that tradition in programming.

But using a fixed-width font is not mere tradition, not only done because
it was done so before. There are important practical reasons.


PointedEars

 

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Tue, 22 Feb 2011 16:47:26, John G Harris
<[email protected]> posted:


A block does not need to be defined as containing a single statement; it
can in the same way be given an opener and a closer, such as "begin" and
"end". In the case of procedures, the block-ness can be implicit.

<snip>

So, you have this construct that starts with a beginning symbol, ends
with an ending symbol, and has a mixture of statements and declarations
in between. How shall we classify this construct? It's obviously not a
declaration, nor is it a comment. Should we treat it as a special and
separate kind of construct, called a topological obfuscator perhaps? Or
should we notice that it can be used anywhere a statement can be used
and be sensible and say that it's one kind of statement?

Exactly one statement.

And it can be used anywhere that exactly one statement is required or
permitted.

John

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>

Dr J R Stockton wrote on 23 feb 2011 in comp.lang.javascript:


So then Javascript is not structured in your definition,

False logic. Saying that something is true in a structured language
does not imply that it is untrue in a non-structured language.

because it is not clear when the if-statement ends,
but by the start of a next statement.

If the language is meaningful and has "if" statements, then it must
always be possible to tell when one ends, whether or not there is a
special marker.

 

[Evertjan.]

Dr J R Stockton wrote on 25 feb 2011 in comp.lang.javascript:

False logic. Saying that something is true in a structured language
does not imply that it is untrue in a non-structured language.

I never said it as an non- or unstructured language,
no programming-language is so complete it's structure is perfect.

But indeed, if a seperate statement depends on the nature of the next
statement, that is a strong marker of lack of structure in my book.

If the language is meaningful and has "if" statements, then it must
always be possible to tell when one ends, whether or not there is a
special marker.

However we were talking about Javascript, not having a "fi"?

The above mentioned lack of structure doesn't degrade the meaningfulness,
only the structure, and so is unnecessarily error-prone.

The if-structure, including or not including the else substructure,
should "know" by itself when it's statement is ended.

Depending on the start of the next statement [or the end of file],
is to weak to be called firm structure. Even when else is defined as
innermost-else, the structure could collapse and give erroneus results
when changed by a unaware programmer, who trusts the structuredness of
such language.

Example:

if (boolean)
if (boolean) statement1
else statement2
else statement3
;

and:

if (boolean)
if (boolean) statement1
// else statement2
else statement3
;

when you take out the line "else statement2"
the final else [of "else statement3"] will suddenly be part of the
inner if-construct.

If the if-statement has a structurally properly designed end,
this would not happen.

Typically an effect of unsound structure.

Adding the now necessary {}s is just patchwork, the primary strutuse
should be sound in itself.