On Wed, 19 May 2004 23:19:26 +0200, Roel Mathys wrote:

> Juan C wrote:
> 
>>>yeah, but elif is 4 letters, else if is 6 letters and a space, that's upto 75% more, so adding elif would mean an increase in productivity of almost 43%
>> 
>> 
>> Well, no, a disk storage (and network transfer) savings of 43%. And I've only got 75GB of free space on my disk! I'd better watch out.
>> 
>> One of my Perl books around here states (jokingly I hope) that Perl doesn't have
>> "elif" because it's "file" spelled backward. Who am I to argue with that?  (Oy!)
>> 
>> More seriously: if "elif" is added simply to take the place of "else if", I would hope that "else if" becomes illegal. On the other hand you can write "elif" and have a text replacement utility replace it with "else if".
>> 
>> 
> 
> this could be "the" ultimate reason to add a preprocessor to D, replace all "elif" with "else if" <g>
> 

No this is the job of your IDE.

in leds you can define any identifier to expande to any text
you can have gpl expanded to the gpl common header with the project
name inserted.
you can define "ei" to expande to"

if ( $cursor )
{
}
else if (  )
{
}
else
{
}

any minimal code editor should be able to do that.

Ant

Juan C wrote:

> If there were several competing D compilers (and there will be) features like
> this could be deciding factors in choosing one. (Can you say "non-portable"?)

I don't agree, I've seen enough so-called 4th generation language tools, this would be one more.

code containing the elif is not D, as long as the specification does not allow it. It's best to put in the specs (before 1.0 is released) how vendor-specific extension can be but into the language.
C++ has something like that, don't recall exactly what it is, but MS used it to define some extra's into their Managed C++.

bye,
roel

Juan C wrote:
>> yeah, but elif is 4 letters, else if is 6 letters and a space,
>> that's upto 75% more, so adding elif would mean an increase in
>> productivity of almost 43%
> 
> Well, no, a disk storage (and network transfer) savings of 43%. And
> I've only got 75GB of free space on my disk! I'd better watch out.

As if

	else ifelse ifelse ifelse ifelse ifelse ifelse ifelse ifelse if

were a valid program....

> One of my Perl books around here states (jokingly I hope) that Perl
> doesn't have "elif" because it's "file" spelled backward. Who am I to
> argue with that?  (Oy!)

Maybe you should use lreP then....

> More seriously: if "elif" is added simply to take the place of "else
> if", I would hope that "else if" becomes illegal.

What would that achieve?

> On the other hand you can write "elif" and have a text replacement
> utility replace it with "else if".

You could do all kinds of text replacements to translate an ad-hoc language into D.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

Stewart!

if (a < b) {
....
} else if (sin(k) < cos(b)) {
....
} else {
}

isn't a bad substitute for:

select
{
case a < b:                         ..... break;
case (sin(k) < cos(b):       ..... break;
default:                              ..... break;
}

but try to express:

select
{
default:                              ..... break;
case a < b:                         ..... break;
case (sin(k) < cos(b):       ..... break;
}

Based on the results of the discussion bellow, I can tell that most of the programmers do not need extra expression power. OK! It was just a suggestion :)

I read your proposal. It is good, but static. "select" covers both static and non static and optimization is up to compiler.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c8fmuu$20co$1@digitaldaemon.com...
> Lev Elbert wrote:
>
> > I have a suggestion: let's include in D a select statement with
non-static
> > conditions:
> >
> > seclect ()
> > {
> > case a < b:
> >     ....
> >     break;
> <snip>
> > which is equivalent to if - else if - else block, but in some cases more compact and understandable.
>
> Not quite sure how that would be.
>
> if (a < b) {
> ....
> } else if (sin(k) < cos(b)) {
> ....
> } else if (str == "12345") {
> ....
> } else {
> ....
> }
>
> That's compact.  I'd have no trouble understanding it.  It's even cleanly structured compared to switch.
>
> Indeed, I proposed a cleanly structured switch syntax a while back.... http://www.digitalmars.com/drn-bin/wwwnews?D/22722
>
> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Lev Elbert wrote:

<snip>
> but try to express:
> 
> select
> {
> default:                     ..... break;
> case a < b:                  ..... break;
> case (sin(k) < cos(b):       ..... break;
> }

What would that achieve?  Besides a little syntax error?

> Based on the results of the discussion bellow, I can tell that most of the
> programmers do not need extra expression power. OK! It was just a suggestion
> :)
> 
> I read your proposal. It is good, but static. "select" covers both static
> and non static and optimization is up to compiler.
<snip top of upside-down reply>

It is perectly orthogonal to your idea AFAICS.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

> What would that achieve?  Besides a little syntax error?

1. (Sorry for error).
2. In if-else if-else terms: else first. In some cases - more
understandable.

Sure, all what can be expressed by select can be expressed by if-elseif-else. This is the matter of taste. I just do not like extra "distracting" words.

In the case

if (...) {
} else if (.....) {
} else {
}

the conditions are hidden in "else ifs".

In short: program with select() would be more compact and understandable
then if-else if.

But discussion is immatereal - nobody wants to implement it :)

Lev Elbert wrote:
>>What would that achieve?  Besides a little syntax error?
> 
> 
> 1. (Sorry for error).
> 2. In if-else if-else terms: else first. In some cases - more
> understandable.

What order of checking would the rest of the terms have?  Start at the bottom and work up?

<snip>
> In short: program with select() would be more compact and understandable
> then if-else if.
<snip>

More compact?

select {
	case ...:
		...
		break;
	case ...:
		...
		break;
	default:
		...
}

versus

if (...) {
	...
} else if (...) {
	...
} else {
	...
}

OTOH, if my suggested syntax is extended to this, we'd have

select {
	case ... {
		...
	} else case ... {
		...
	} else {
		...
	}
}

                       if    select/break  block select
Lines (as shown)        7    10             9
Tokens                 14    13            13
Chars (as shown)       39    63            57
Chars (squashed up)    23    31            38

(The token and char counts exclude the dots.)

OK, so it saves a token in this example, but that's about all it saves.  As for more understandable, maybe.  But as you rightly say, it's a matter of style.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

On Mon, 24 May 2004 10:43:11 +0100, Stewart Gordon wrote:

> OTOH, if my suggested syntax is extended to this, we'd have
> 
> select {
> 	case ... {
> 		...
> 	} else case ... {
> 		...
> 	} else {
> 		...
> 	}
> }
> 
>                         if    select/break  block select
> Lines (as shown)        7    10             9
> Tokens                 14    13            13
> Chars (as shown)       39    63            57
> Chars (squashed up)    23    31            38
> 
> (The token and char counts exclude the dots.)
> 
> OK, so it saves a token in this example, but that's about all it saves.
>   As for more understandable, maybe.  But as you rightly say, it's a
> matter of style.
> 
> Stewart.

I dislike your style blocks because:
	- it appears that they would make case fallthrough be confusing or
		impossible.
	- they differ from existing standards, and I don't feel they add enough to
		justify the difference.
	- a change would break existing code.

I don't think the advantages outweight the disadvantages.

Mike Swieton
__
It's so simple to be wise. Just think of something stupid to say and then
don't say it.
	- Sam Levenson

Mike Swieton wrote:

>On Mon, 24 May 2004 10:43:11 +0100, Stewart Gordon wrote:
>
>  
>
>>OTOH, if my suggested syntax is extended to this, we'd have
>>
>>select {
>>	case ... {
>>		...
>>	} else case ... {
>>		...
>>	} else {
>>		...
>>	}
>>}
>>
>>                        if    select/break  block select
>>Lines (as shown)        7    10             9
>>Tokens                 14    13            13
>>Chars (as shown)       39    63            57
>>Chars (squashed up)    23    31            38
>>
>>(The token and char counts exclude the dots.)
>>
>>OK, so it saves a token in this example, but that's about all it saves. 
>>  As for more understandable, maybe.  But as you rightly say, it's a 
>>matter of style.
>>
>>Stewart.
>>    
>>
>
>I dislike your style blocks because:
>	- it appears that they would make case fallthrough be confusing or
>		impossible.
>	- they differ from existing standards, and I don't feel they add enough to
>		justify the difference.
>	- a change would break existing code.
>  
>
How? Remember his version doesn't have a colon.  Also I don't think there's a need for the else part.  Something like:

switch (...)
{
case ...
{

}
case ...
{

}
}

Fall through is a big problem for many programmers.

-- 
-Anderson: http://badmama.com.au/~anderson/

Mike Swieton wrote:

<snip>
> I dislike your style blocks because:
> 	- it appears that they would make case fallthrough be confusing or
> 		impossible.

Confusing - not sure.

Impossible - only if the condition has a side effect.  Otherwise, you can do it by nesting cases.

Of course, you would need to repeat the condition to be fallen through from, but considering that fall-through is a bit of a dirty trick anyway....

> 	- they differ from existing standards, and I don't feel they add enough to
> 		justify the difference.

No more than the very invention of a select statement would in the first place.  If a specification were set in so much stone that it couldn't even be added to, you wouldn't

> 	- a change would break existing code.

How?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.