Isn't 'end' the statement delimiter in the examples below?

Pavel Minayev wrote:

>     if a = 1 then a += 1 end
>
>     -- or --
>
>     if a = 1 then
>         a += 1
>     end
>
>     -- or even --
>
>     if a
>     = 1 then a
>     += 1 end
>
> Still, I prefer to have semicolons. They make life easier when reading code, and help compiler to parse some complicated cases.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C5ECA86.97EDD361@deming-os.org...

> Isn't 'end' the statement delimiter in the examples below?

No, it's end of block, not end of statement. You
could see something like this in Lua:

    function foo(a, b) a += 1
    bar() if a > 10 then a = 0
    end baz(a) end

Just a legal piece of code =)

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C5EBDCD.5040504@estarcion.com...

> Logical shift = unsigned shift = not arithmetic shift = don't shift in sign bits. Doesn't make a difference to the left shift, obviously.

Ahh... sorry, didn't know how it's called "logical".

k, I see now :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Pavel Minayev <evilone@omen.ru> wrote in message news:a3ll7u$svm$1@digitaldaemon.com...

> Why not then simply "and" & "or" & "eq", and where is "not"?. And why don't you like && || ?

&& does not in itself imply a "logical" operation rather than a numerical one.  l& has an advantage over && in the regard.  Having said that, "land" has both benefits and problems.  As long as there is a consistant distinction made for logial vs numerical operations.

In C, we have = numeric == logical
                     & numeric && logical
                     | numeric || logical

and now the inconsistancy

                    < logical  << numeric
                    > logical  >> numeric

Very unfortunate.


> > >>  = logical shift right
> > << = logical shift left
>
> LOGICAL SHIFT???

Sorry Assembler vocab.



>
> > do
> >    ch = fgetc(fp)
> >    if (ch != EOF land ch !=  EOL) then exit
> >   ...
> > loop
>
> No Pascal, please =)
>
>     while (true)
>     {
>         ...
>     }

Inferior.

Simple brackets are inferior for a variety of reasons.
In the above instance the opening brace is redundant and wastes a line of
space.  The block can start at the end of the conditional with no loss of
clarity.

Second, there is no type to the closing brace.  Lack of block typing makes a language prone to block grouping errors.  Indention is a poor replacement for proper language typing.  Youi might as well omit variable typing and stipulate that variables the end with one brace are integers, two braces are floats, etc.

Block typing is good.  Use it.

> "D" <s_nudds@hotmail.com> wrote in message
> > C syntax is a fine model to follow if you wish to continually repeat the
> > same perpetually exposed errors.
> > Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
> > token.

Pavel Minayev <evilone@omen.ru> wrote in message news:a3lla6$svt$1@digitaldaemon.com...
> BASIC fan, eh? =)

I am, but I don't propose the method because it's the one chosen by
MSBasics.  It is simply a fact that
line continuation is less common that <EOL>.  It is also a fact that
semicolons are commonly omited and their omission causes trouble. Not
requiring them is therefore superior.


Pavel Minayev <evilone@omen.ru> wrote in message news:a3lla6$svt$1@digitaldaemon.com...
> Just indent code properly, and everything is very readable. In fact, C/C++/D code is sometimes more readable than BASIC or Pascal one, because you read much less junk.

The fact that C/C++ does not have block typing means that it is error prone and less readable than those langauges that have it.

I don't recommend perpetually repeating the foolish mistakes of the past.