> So there is a misunderstanding. I've read in the D language specifications:

There we're also other discussions that also contraindict this mission statment.

> If people are concerned with how the code looks, you could even say that braces are hard to read and that D could have block termination statements like "end if" instead.

End if follow this path of content of this newsgroup to the end you'll have re-evolution of PASCAL.

* Very very very fast compiler (~10 times faster than c)
* forces strict coding scheme to the user,
* object pascal provides getters, setter, etc.
* sets
* typesafe writeln() statement
etc. etc.

- Axel

In article <9o9r71$ljt$2@digitaldaemon.com>, "Roberto Mariottini" <mario@jonathan.torino.artis.it> wrote:

> I think a new keyword is not needed, simply accept this common exception:
> 
> IfStatement:
>   if ( Expression ) BlockStatement
>   if ( Expression ) BlockStatement else BlockStatement
>   if ( Expression ) BlockStatement else IfStatement
> 
> This way it is like having an else-if instruction, while not actually having it.

Yes, that's the sort of thing I mean (well, one of them).

> IfStatement:
>   if ( Expression ) BlockStatement
>   if ( Expression ) BlockStatement else BlockStatement
>   if ( Expression ) BlockStatement else IfStatement
> 

Um, where is the syntactical difference compared to the normal/standard way?

BlockStament:
  .... while ...
 |
  .... do ...
 |
  .... Expr ...
 |
  etc.
 |
   IfStatment
;

IfStatement:
   if ( Expression ) BlockStatement
  |
   if ( Expression ) BlockStatement else BlockStatement
;


As I guess it the only think difference is that you'll get a reduce/reduce confilce since the after the 'else' seeing a new 'if', will not be able to say if it's an IfStatement from the BlockStament rule, or an IfStatement from your third rule.
>   if ( Expression ) BlockStatement else IfStatement

- Axel

Now I get it!  I see what you mean...no 'else if' if you have to use braces. Personally, I don't think that this is worth adding a new keyword for, and we certainly shouldn't add special case rules (ick!).

In article <9oa34f$qot$1@digitaldaemon.com>,
 Axel Kittenberger <axel@dtone.org> writes:
|>
|> > IfStatement:
|> >   if ( Expression ) BlockStatement
|> >   if ( Expression ) BlockStatement else BlockStatement
|> >   if ( Expression ) BlockStatement else IfStatement
|> >
|>
|> Um, where is the syntactical difference compared to the normal/standard way?
|>
|> BlockStament:
|>   .... while ...
|>  |
|>   .... do ...
|>  |
|>   .... Expr ...
|>  |
|>   etc.
|>  |
|>    IfStatment
|> ;
|>
|> IfStatement:
|>    if ( Expression ) BlockStatement
|>   |
|>    if ( Expression ) BlockStatement else BlockStatement
|> ;

It actually is (from the web site):

        BlockStatement:
		{ }
		{ StatementList }

	StatementList:
		Statement
		Statement StatementList
        ;

	IfStatement:
		if ( Expression ) Statement
		if ( Expression ) Statement else Statement
        ;

|>
|> As I guess it the only think difference is that you'll get a reduce/reduce
|> confilce since the after the 'else' seeing a new 'if', will not be able to
|> say if it's an IfStatement from the BlockStament rule, or an IfStatement
|> from your third rule.
|> >   if ( Expression ) BlockStatement else IfStatement

There is no such conflict because BlockStatement starts with the terminal '{' and IfStatement starts with the terminal 'if'.

Ciao

In article <9o9v14$op5$1@digitaldaemon.com>,
 Axel Kittenberger <axel@dtone.org> writes:
|> > So there is a misunderstanding.
|> > I've read in the D language specifications:
|>
|> There we're also other discussions that also contraindict this mission
|> statment.

So this "mission statement" is not mandatory? Just to know.

|> > If people are concerned with how the code looks, you could even say that
|> > braces are hard to read and that D could have block termination statements
|> > like "end if" instead.
|>
|> End if follow this path of content of this newsgroup to the end you'll have
|> re-evolution of PASCAL.
|>
|> * Very very very fast compiler (~10 times faster than c)

The only one fast Pascal compiler I know is the one from Borland.
This is achieved at some costs (typically, the compiler stops at the first
error it founds). Any other Pascal compiler I know is only a little faster
than C compilers, I think because it doesn't need a pre-processor.

|> * forces strict coding scheme to the user,

In Pascal you can easily do what I don't want to do:

 if a and b then
    i := i + 1; j := j + 1;

It's worse even than C:

 if (a && b)
    ++i; ++j;

Here parenthesis give more readability.

|> * object pascal provides getters, setter, etc.

But Pascal doesn't. I think they are good, but this is definitely not Pascal.

|> * sets

Good. Subranges also, they can improve the design-by-contract strategy.

I recognize in C++ something that I find normally in Pascal.
To me is natural: Pascal is the perfect theory, C is the weird trick.
Any language should be between those limits, IMHO. I think
theory is good only if supported by some practice, and practice is
good only if based on some theory. But this is an opinion.

Ciao

In article <9oc6aq$20n7$1@digitaldaemon.com>, "Roberto Mariottini" <mario@jonathan.torino.artis.it> wrote:

> In article <9o9v14$op5$1@digitaldaemon.com>,
>  Axel Kittenberger <axel@dtone.org> writes:
> |> > So there is a misunderstanding.
> |> > I've read in the D language specifications: |> |> There we're also
> other discussions that also contraindict this mission |> statment.
> 
> So this "mission statement" is not mandatory? Just to know.

Hmm...   I seem to remember that the reason why C uses = for assignment and == for comparison is that K&R decided that (since there are on average about 4 times as many assignments as comparisons) the keystrokes saved outweighed the problems.

But then I don't think they had such a mission statement. ;)


> |> End if follow this path of content of this newsgroup to the end you'll have |> re-evolution of PASCAL.
>
> |> * forces strict coding scheme to the user,
> 
> In Pascal you can easily do what I don't want to do:
> 
>  if a and b then
>     i := i + 1; j := j + 1;

Yes.  In ADA you have to put "end if" where the if statement ends.  This means that it is very hard to make such mistakes.  Making braces compulsory would be almost as good.

The ADA way is better because you can see which block is being closed (an
if or a loop, etc.) and it also lets you name the ends, as in
"end function function_name".

However, this is a departure from the C syntax and you'd have to change an awful lot (e.g. structs) to keep things consistent.


The book "Code Complete" mentions that some sizeable project written in ADA was completed basically bug free, partly because ADA has protections such as this.

Hi!

Uhmm..

Time for a "funny comment"..

If you think adding two braces and using shift are "waste of time" you

probably need a typing course..

I thought you guys where joking, but I saw the point in there somewhere when

I read about the old sweet C -bug....

*big warm smile*

Have a nice day

Johan Bryssling, Software developer/Consult, Micronet

ps. IM still watching the "D" - development and still finds it interesting

so when it's ready to ship out?. =)

"Roberto Mariottini" <mario@jonathan.torino.artis.it> wrote in message news:9oahhl$136g$1@digitaldaemon.com...
> In article <9oa34f$qot$1@digitaldaemon.com>,
>  Axel Kittenberger <axel@dtone.org> writes:
> |>
> |> > IfStatement:
> |> >   if ( Expression ) BlockStatement
> |> >   if ( Expression ) BlockStatement else BlockStatement
> |> >   if ( Expression ) BlockStatement else IfStatement
> |> >
> |>
> |> Um, where is the syntactical difference compared to the normal/standard
way?
> |>
> |> BlockStament:
> |>   .... while ...
> |>  |
> |>   .... do ...
> |>  |
> |>   .... Expr ...
> |>  |
> |>   etc.
> |>  |
> |>    IfStatment
> |> ;
> |>
> |> IfStatement:
> |>    if ( Expression ) BlockStatement
> |>   |
> |>    if ( Expression ) BlockStatement else BlockStatement
> |> ;
>
> It actually is (from the web site):
>
>         BlockStatement:
> { }
> { StatementList }
>
> StatementList:
> Statement
> Statement StatementList
>         ;
>
> IfStatement:
> if ( Expression ) Statement
> if ( Expression ) Statement else Statement
>         ;
>
> |>
> |> As I guess it the only think difference is that you'll get a
reduce/reduce
> |> confilce since the after the 'else' seeing a new 'if', will not be able
to
> |> say if it's an IfStatement from the BlockStament rule, or an
IfStatement
> |> from your third rule.
> |> >   if ( Expression ) BlockStatement else IfStatement
>
> There is no such conflict because BlockStatement starts with the terminal '{' and IfStatement starts with the terminal 'if'.
>
> Ciao

When your indentation goes off the right of the screen when doing complex if/else if/else logic, you will see the benefit of adding elseif to the language.

There is no need for a new keyword... the parser (or in fact the lexer) can deal with the combination "else if" as if it were a single token, elseif.

I really wouldn't mind being forced to use curly braces around all blocks controlled by if/for/while/etc.  Keeps things consistent, and simplifies the language spec.  But it would also mean an increased need for elseif.  I imagine that in the future, the editor will automatically generate the braces for you, so that when you type "if" the editor magically makes you some blocks like so:

if [boolexpr]
[statements]

and place your cursor inside of the empty [boolexpr] block.  You type your expression, then either type '{' or right arrow or down arrow or use the mouse to move to the empty [statements] block.  Once you've finished typing your statements, you either type '}' or right arrow or down arrow or use the mouse to go to the line after the if.  The editor could also fold up (hide) blocks for you on request so you can look at the high-level logic of a huge multi-page function, without all the clutter, or expand each block to zoom in on it.  A real smart editor would prevent any kind of syntax error from ever being entered in the first place.  It could also change the language slightly, such as removing the need for displaying or typing the parenthesis around the boolexpr test of an if statement, and removing the need for { } around blocks.  When saving the file it would convert blocks to { } form, when loading a .D file it would convert { } to the IDE editor's block format, probably parse up the whole file and keep it in memory as a graph of some kind.

One of these days.

The thing I like about C-style { } is it's short and easy to type and if the conscientious programmer indents them well, it makes things clear to read. Eiffel-style "end" to delimit blocks makes sense in some ways because it eliminates the need for the opening '{', which really seems to just be syntactical clutter needed only to differentiate a statement from a block of statements, and is mis-indented by many programmers which eliminates much of the benefit of visual lining up of the indented block.  Also, if indented properly, { } wastes two lines of valuable screen real estate which makes some programmers turn to a style such as this to save space:

if (a > b)
{ DoSomething(); }

or

inline void Advance()
{ ++j; }

If blocks are always required, the only thing you need is the '}' or something like 'end'.  '}' by itself sucks because it's not balanced.

I'd rather just have the editor take care of this statement grouping, automatically providing the language's delimiters as necessary.

In fact I think this concept is worthwhile enough that I'd almost want to separate the internal parse tree form of the language entirely from the textual representation which gets saved to files and written in emails or newsgroups.   Conversion between the two forms should be well-defined, of course, but isn't it time programmers started working with code as something besides plain text?  Just look at Visual Basic or Delphi, they already do something like this, they could hide the text form entirely if they wanted.

Sean

"Russ Lewis" <russ@deming-os.org> wrote in message news:3BA8C300.FB9FEE09@deming-os.org...
> Now I get it!  I see what you mean...no 'else if' if you have to use
braces.
> Personally, I don't think that this is worth adding a new keyword for, and
we
> certainly shouldn't add special case rules (ick!).

Your reply caused me to go back and look at my statement you were replying to. I don't know what I was thinking.

I was insane.

I repent.

'else if' is good.

--
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))) ]