Re: Go ahead. Stop programming. This ensures you from any mistakes.

valentin tihomirov wrote:
It is a fact that statements are executed seqientially, one after another.

Actually, it's not. Statements can be, and some definitely are, executed in parallell or out of sequence, as long as the result in every relevant aspect is the same as if they were executed in the sequence specified in the code.

It is truth that a block of instructions is executed as one statement. It is truth that the variables in the imerative languages, which allow deferred declarations, are visible only past declaration.

Not really. By design the variable is visible in the entire block in the sense that you can not declare another variable with the same name.

Acquiring these basic matters, everybody understands that the parent block variables declared past the block are not visible inside the block and that the block internal variables are not visible past the block. The other considerations are irrationale.

No, they are most definitely rational.

Rearranging code always can yeild errors. Does this argument give me power to infer arbitrary rules?

Now you are not being irrational. The rules are not arbitrary at all. They are definitely relevant to the situation.


I suppose that the first thing the programmers should know is the sequence of instruction execution.

It's not a matter of knowing how it works, but rather having a language that lets you easily produce stable code.

Normally, the statements are eveluated sequentially. Should we put an explicit branch after each and every statement to avoid the natural "fall through"? The fallthrough ban does not save you from the infinite kinds of errors you still can make, including wrong branching. It just infers a fair amount of code where it is unnecessariy.

In a switch statement you are jumping into one of many code blocks, it's not at all unreasonable that each block should end with a statement that specifies where the execution should continue. After all, in the majority of cases the block will end with a break anyway.

This requirement adds a bit of unnecessary code in a few cases, but a bit of unnecessary code is very often used to keep the language consistent and clear. The keyword if, for example, is always followed by a parenthesis, so the parenthesis is really totally unnecessary, but you wouldn't argue that it should be removed or even optional, would you?

--
Göran Andersson
_____
http://www.guffa.com
.

Relevant Pages

  • Re: pseudo-namespacing in JavaScript
    ... SCRIPT element the outcome becomes very different. ... assignment, and if the DIV element had been shown to proceed the SCRIPT ... execution context where the spec says it should not. ... that function declarations will replace the ...
    (comp.lang.javascript)
  • Scott & Andrei article on DCLP and threading... Flawed ?
    ... am unable to make a solid case for strict ordering of 1,2 and 3. ... "As we tried to point out in the article, sequence points don't offer ... state of the execution environment. ... There is a sequence point at the completion of evaluation of each ...
    (comp.lang.cpp)
  • Re: Definition of language constructs
    ... In general, execution involves evaluation, and evaluation ... In /some/ other imperative languages. ... Sequence points are a /particular/ way of expressing execution ...
    (comp.lang.c)
  • Go ahead. Stop programming. This ensures you from any mistakes.
    ... declarations, ... All normal languages obey it ... right away from simplicity. ... of instruction execution. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: IE javascript bug: global variable
    ... Global variable declarations result in properties of the ... actual execution of code in that context. ... That's another aspect of this bug that puzzles me; ... both variable instantiation and actual code ...
    (comp.lang.javascript)
Loading