www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: "with" still sucks + removing features + adding features

reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).



 Kind of an odd syntax.  Why not "case a .. b:"?  Parsing issues?



 It's consistency. Everywhere in the language a .. b implies b is 
 excluded. In a switch you want to include b. So I reflected that in the 
 syntax. In fact, I confess I'm more proud than I should be about that 
 little detail.



Consistency???

While I can see where you're coming from, I still see plenty of
inconsistencies. It's still a range (defined with .. too). Having slices and
foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2
kind of sucks. 
 
 

 Static foreach might be making it too.



 That'd be a nice addition.  Especially with __traits returning
 arrays/tuples, it'd be an alternative to CTFE (shudder) or template
 recursion.



 Yah, can't wait.



I'm still hoping for static switch too!
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).






 excluded. In a switch you want to include b. So I reflected that in the 
 syntax. In fact, I confess I'm more proud than I should be about that 
 little detail.



 Consistency???
 
 While I can see where you're coming from, I still see plenty of
inconsistencies. It's still a range (defined with .. too). Having slices and
foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2
kind of sucks. 



You'd have to squint real hard to see a range. A range is

expr1 .. expr2

That code is

case expr1: .. case expr2:

I mean you can't tell me that as soon as ".." is within a mile it's a range.


Andrei
May 18 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).






 excluded. In a switch you want to include b. So I reflected that in the 
 syntax. In fact, I confess I'm more proud than I should be about that 
 little detail.



 Consistency???
 
 While I can see where you're coming from, I still see plenty of
inconsistencies. It's still a range (defined with .. too). Having slices and
foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2
kind of sucks. 



 You'd have to squint real hard to see a range. A range is
 
 expr1 .. expr2
 
 That code is
 
 case expr1: .. case expr2:
 
 I mean you can't tell me that as soon as ".." is within a mile it's a range.
 
 
 Andrei



It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



Thank you for nicely expressing one of the critics I was trying to express.
(My other problem is that I'd like a more general syntax).

------------------------

A different simple solution can be:
case a .. b+1:
That requires no new syntax.

Bye,
bearophile
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Bill Baxter:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



 Thank you for nicely expressing one of the critics I was trying to express.
 (My other problem is that I'd like a more general syntax).
 
 ------------------------
 
 A different simple solution can be:
 case a .. b+1:
 That requires no new syntax.
 
 Bye,
 bearophile



void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case '0' .. case '9':
          writeln("a digit.");
          break;
       case 'A' .. case 'Z': case 'a' .. case 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}

Cool!

void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case '0' .. '9'+1:
          writeln("a digit.");
          break;
       case 'A' .. 'Z'+1: case 'a' .. 'z'+1:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}

Awful!


Andrei
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Thank you for bringing a "real" example that gives something to work on.


Awful!<



Well, one of your cases was wrong. Using the +1 at the end one of those cases
become:
case 'A' .. 'Z'+1, 'a' .. 'z'+1:
Instead of what you have written:
case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

I agree that that syntax with +1 isn't very nice looking. But the advantage of
+1 is that it introduces (almost) no new syntax, it's not easy to miss, its
meaning is easy to understand. AND you don't have to remember that in a case
the .. is inclusive while in foreach is exclusive on the right, keeping the
standard way in D to denote ranges.

-------------------------

We can introduce in D a syntax that maps on the semantics of iota(start, stop)
or even iota(start, stop, step) (I don't remember if iota() supports opIn_r,
and has length, if not then it's better to add them).

So you can do:

foreach (i; somerangesyntax) {...}
(So this replaces the current ranged foreach syntax).

case somerangesyntax: ...

if (x in somerangesyntax) {...}

map(fun, somerangesyntax);

And more, using only one (or two) general syntaxes.

-------------------------

The simple exclusive range syntax, with +1:

void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case '0' .. '9'+1:
          writeln("a digit.");
          break;
       case 'A' .. 'Z'+1, 'a' .. 'z'+1:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


Using Chapel closed range syntax:

void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case '0' ..# '9':
          writeln("a digit.");
          break;
       case 'A' ..# 'Z', 'a' ..# 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


An alternative to that Chapel syntax:

void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case '0' ..> '9':
          writeln("a digit.");
          break;
       case 'A' ..> 'Z', 'a' ..> 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


It may be easy to miss the third point (but it's not a noisy syntax)

void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case '0' ... '9':
          writeln("a digit.");
          break;
       case 'A' ... 'Z', 'a' ... 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


Using something more explicit (interval() is lazy and inclusive on the right.
The D compiler optimizes away at compile time the following calls):

void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case interval('0', '9'):
          writeln("a digit.");
          break;
       case interval('A', 'Z'), interval('a', 'z'):
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


void classify(char c) {
    write("You passed ");
    switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case ['0' .. '9']:
          writeln("a digit.");
          break;
       case ['A' .. 'Z'], ['a' .. 'z']:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}



Such syntaxes are meant to be used in every other situation too (and I'd like
to have another syntax that is non-inclusive, possibly like the current one):

foreach (i; 'A' .. 'Z'+1) {...}
case 'A' .. 'Z'+1: ...
if (x in 'A' .. 'Z'+1) {...}
map(fun, 'A' .. 'Z'+1);

foreach (i; 'A' ..# 'Z') {...}
case 'A' ..# 'Z': ...
if (x in 'A' ..# 'Z') {...}
map(fun, 'A' ..# 'Z');

foreach (i; 'A' ..> 'Z') {...}
case 'A' ..> 'Z': ...
if (x in 'A' ..> 'Z') {...}
map(fun, 'A' ..> 'Z');

foreach (i; 'A' ... 'Z') {...}
case 'A' ... 'Z': ...
if (x in 'A' ... 'Z') {...}
map(fun, 'A' ... 'Z');

foreach (i; interval('A', 'Z')) {...}
case interval('A', 'Z'): ...
if (x in interval('A', 'Z')) {...}
map(fun, interval('A', 'Z'));

foreach (i; ['A' .. 'Z']) {...}
case ['A' .. 'Z']: ...
if (x in ['A' .. 'Z']) {...}
map(fun, ['A' .. 'Z']);


The a..b+1 syntax can't be used inside map() in a simple way.

The [a .. b] syntax is acceptable, but then it doesn't offer a good way to
define those if() and map() for the noninclusive situation:

// inclusive cases?
foreach (i; ['A' .. 'Z']) {...}
case ['A' .. 'Z']: ...
if (x in ['A' .. 'Z']) {...}
map(fun, ['A' .. 'Z']);

// noninclusive cases?
foreach (i; 'A' .. 'Z') {...}
case 'A' .. 'Z': ...
if (x in 'A' .. 'Z') {...}
map(fun, 'A' .. 'Z');

Well... That's not perfect, but it looks better than the syntax suggested by
Andrei. Do you have better ideas?

Bye,
bearophile
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:
 
 Thank you for bringing a "real" example that gives something to work on.
 

 Awful!<



 Well, one of your cases was wrong. Using the +1 at the end one of those cases
become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:
 
 I agree that that syntax with +1 isn't very nice looking. But the advantage of
+1 is that it introduces (almost) no new syntax, it's not easy to miss, its
meaning is easy to understand. AND you don't have to remember that in a case
the .. is inclusive while in foreach is exclusive on the right, keeping the
standard way in D to denote ranges.



You don't understand. My point is not that people will dislike 'Z'+1. 
They will FORGET TO WRITE THE BLESSED +1. They'll write:

case 'A' .. 'Z':

and they'll wonder why the hell Z is not handled. Now do you see why 
it's sometimes ungainly to discuss language design here? It can only go 
forever, and in the end anyone can say "but I just don't like it". In 
fact I'll use that prerogative right now:

[snip]


 Well... That's not perfect, but it looks better than the syntax suggested by
Andrei. Do you have better ideas?



I like my syntax better than all you mentioned, by a mile.


Andrei
May 18 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:


 I like my syntax better than all you mentioned, by a mile.



Problem: Define a syntax that indicates a specific range of values for a
single case statement.

Constraints:
(1) No new keywords permitted.
(2) No new operators permitted.
(3) Must indicate an *inclusive* range
(4) A range has an explicit starting value and ending value
(5) A range has an implicit step value of 1.
(6) Must not be keystroke-heavy
(7) Must be easy to read
(8) Must be easy to remember while writing
(9) Must not be ambiguous with existing syntax
(10) Must be consistent with existing syntax
(11) Must take the general form ...

    'case' RANGE ':'


Andrei ...
  case FIRST .. case LAST :
   [[ -(8)- The second 'case' is easy to forget to write ]]
   [[ -(10)- The ".." means exclusive range elsewhere but not here ]]

bearophile ...
  case FIRST .. LAST+1 :
   [[ -(8)- The +1 is easy to forget to write ]]

JB (first pass)
  case FIRST .. LAST :
   [[ -(10)- inconsistent with exclusive range syntax]]


So just as a thought without a lot of adademic introspection 

derek ...
  case [FIRST ; LAST] :

  sample code ...
    void classify(char c) {
      write("You passed ");
      switch (c) {
       case '#':
          writeln("a hash sign.");
          break;
       case ['0' ; '9']:
          writeln("a digit.");
          break;
       case ['A' ; 'Z'], ['a' ; 'z']:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
      }
  }

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
 

 I like my syntax better than all you mentioned, by a mile.



 Problem: Define a syntax that indicates a specific range of values for a
 single case statement.
 
 Constraints:



(0) Must be recognizable and understood at first sight without the user 
running to the manual and looking it up.


 (1) No new keywords permitted.
 (2) No new operators permitted.
 (3) Must indicate an *inclusive* range
 (4) A range has an explicit starting value and ending value
 (5) A range has an implicit step value of 1.
 (6) Must not be keystroke-heavy
 (7) Must be easy to read
 (8) Must be easy to remember while writing
 (9) Must not be ambiguous with existing syntax
 (10) Must be consistent with existing syntax
 (11) Must take the general form ...
 
     'case' RANGE ':'
 
 
 Andrei ...
   case FIRST .. case LAST :
    [[ -(8)- The second 'case' is easy to forget to write ]]



Compile-time error.


    [[ -(10)- The ".." means exclusive range elsewhere but not here ]]



NO. NO. NO. BY GOLLY NO. Please understand the very basics of a grammar. 
I swear this is the last time I explain that.

".." is a TOKEN. TOKEN. TOKEN. Punctuation. It is NOT any grammatical 
construct in particular.

expression1 .. expression2

is a notation for ranges. All elements must be present. ".." by itself 
does not have a meaning.

case expression1: .. case expression2:

is an entirely different construct. It does not have expression1 .. 
expression2 anywhere in sight. It is ridiculous to attribute meaning to 
".." alone as much as saying that "(" must only used to initiate a 
function call or "[" must be only used to initiate an array indexing 
operation.


 bearophile ...
   case FIRST .. LAST+1 :
    [[ -(8)- The +1 is easy to forget to write ]]
 
 JB (first pass)
   case FIRST .. LAST :
    [[ -(10)- inconsistent with exclusive range syntax]]
 So just as a thought without a lot of adademic introspection 
 
 derek ...
   case [FIRST ; LAST] :



Fails (0) with flying colors.


Andrei
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gut7lb$ue8$1 digitalmars.com...

 (0) Must be recognizable and understood at first sight without the user 
 running to the manual and looking it up.



I've never considered that a particularly good criterea in most cases. Most 
language features/syntax are non-obvious at a glance for anyone who isn't 
already familiar with it. And typically, you only need to look it up once 
and then next time you see it you'll remember. People had the same complaint 
when '$' was proposed for blah.length, but seriously, one it was included 
who here has ever had a non-trivial time learning and internalizing that? 
Does '!()' scream "template" to someone who hasn't used D or looked at the D 
docs? Of course not. But it works fine. And I sure someone could have easily 
said the same about the '#' at the beginning of preprocessor directives back 
whenever those were first created. But who ever has any real trouble with 
that? I didn't even the very first time I was introduced to it. This '(0)' 
is barely an issue at all.
May 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gut7lb$ue8$1 digitalmars.com...

 (0) Must be recognizable and understood at first sight without the user 
 running to the manual and looking it up.



 I've never considered that a particularly good criterea in most cases. Most 
 language features/syntax are non-obvious at a glance for anyone who isn't 
 already familiar with it.



Not slight departures from existing syntax.

Andrei
May 19 2009
prev sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:


 On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
 

 I like my syntax better than all you mentioned, by a mile.



 Problem: Define a syntax that indicates a specific range of values for a
 single case statement.
 
 Constraints:
 (1) No new keywords permitted.
 (2) No new operators permitted.
 (3) Must indicate an *inclusive* range
 (4) A range has an explicit starting value and ending value
 (5) A range has an implicit step value of 1.
 (6) Must not be keystroke-heavy
 (7) Must be easy to read
 (8) Must be easy to remember while writing
 (9) Must not be ambiguous with existing syntax
 (10) Must be consistent with existing syntax
 (11) Must take the general form ...
 
     'case' RANGE ':'
 
 
 Andrei ...
   case FIRST .. case LAST :
    [[ -(8)- The second 'case' is easy to forget to write ]]
    [[ -(10)- The ".." means exclusive range elsewhere but not here ]]
 
 bearophile ...
   case FIRST .. LAST+1 :
    [[ -(8)- The +1 is easy to forget to write ]]
 
 JB (first pass)
   case FIRST .. LAST :
    [[ -(10)- inconsistent with exclusive range syntax]]
 
 
 So just as a thought without a lot of adademic introspection 
 
 derek ...
   case [FIRST ; LAST] :



Personally I feel that your syntax breaks the condition
(6) Must not be keystroke-heavy

I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.

Maybe the solution is a second range operator that is inclusive, such as:
    case FIRST ... LAST:

I don't feel it breaks the no new operator rule as ... is already handled by
the lexer, and it is obvious to the parser what the intended usage is. Also the
operator can be generalized to all range statements.

Jeremie
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote:


 Derek Parnell Wrote:

   case [FIRST ; LAST] :



 Personally I feel that your syntax breaks the condition
 (6) Must not be keystroke-heavy



Huh?? By keystroke-heavy I meant the number of keyboard presses the finger
would have to do to write it.


Ignoring FIRST/LAST, I have 3 (three) keystrokes  and Andrei has 8
keystrokes? 

Me =  [ ; ]

Andrei = SHIFT : .. case


 I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.
 
 Maybe the solution is a second range operator that is inclusive, such as:
     case FIRST ... LAST:



Which is 3 keystrokes too. 

Sorry, I don't understand what you mean by saying my suggestion breaks (6).

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:


 On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote:
 

 Derek Parnell Wrote:

   case [FIRST ; LAST] :



 Personally I feel that your syntax breaks the condition
 (6) Must not be keystroke-heavy



 Huh?? By keystroke-heavy I meant the number of keyboard presses the finger
 would have to do to write it.
 
 
 Ignoring FIRST/LAST, I have 3 (three) keystrokes  and Andrei has 8
 keystrokes? 
 
 Me =  [ ; ]
 
 Andrei = SHIFT : .. case
 

 I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.
 
 Maybe the solution is a second range operator that is inclusive, such as:
     case FIRST ... LAST:



 Which is 3 keystrokes too. 
 
 Sorry, I don't understand what you mean by saying my suggestion breaks (6).
 
 -- 
 Derek Parnell
 Melbourne, Australia
 skype: derek.j.parnell



Ah yes if you go by the count of characters, then yes you are right. I assumed
it meant the ease of typing it, as ... is way faster to get on the screen than
[;]. Also your characters are only easily accessible on a keyboard using the US
layout (I began programming on a french canadian layout, and you need to use
the right alt key for both [ and ], real annoying).
May 18 2009
prev sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.


 Awful!<



 Well, one of your cases was wrong. Using the +1 at the end one of 
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the 
 advantage of +1 is that it introduces (almost) no new syntax, it's not 
 easy to miss, its meaning is easy to understand. AND you don't have to 
 remember that in a case the .. is inclusive while in foreach is 
 exclusive on the right, keeping the standard way in D to denote ranges.



 You don't understand. My point is not that people will dislike 'Z'+1. 
 They will FORGET TO WRITE THE BLESSED +1. They'll write:
 
 case 'A' .. 'Z':



You know, Ruby solves this by introducing a “seperate” range syntax for 
exclusive ranges: “...”. An inclusive range is written the same as an 
exclusive range in D: “..”.

a[1 .. 2].length #=> 1 ([a[1]])
a[1 ... 2].length #=> 2 ([a[1], a[2]])

I see no reason not to include such a seperate syntax in D. “..” being 
exclusive and “...” being inclusive, not the other way round as in Ruby 
— see “Programmer’s Paradox”   
http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

Kind regards, Alex
May 19 2009
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.


 Awful!<



 Well, one of your cases was wrong. Using the +1 at the end one of
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.



 You don't understand. My point is not that people will dislike 'Z'+1.
 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':



 You know, Ruby solves this by introducing a “seperate” range syntax for
 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.
 
 a[1 .. 2].length #=> 1 ([a[1]])
 a[1 ... 2].length #=> 2 ([a[1], a[2]])
 
 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .
 
 Kind regards, Alex



Yes, this is useful for all use cases of ranges.
I like '...'.
May 19 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Frank Benoit wrote:

 Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.


 Awful!<



 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.



 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':



 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.

 a[1 .. 2].length #=> 1 ([a[1]])
 a[1 ... 2].length #=> 2 ([a[1], a[2]])

 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex



 Yes, this is useful for all use cases of ranges.
 I like '...'.



Indeed it's not a bad idea... But it might be easily mistyped, lead to 
strange off-by-one errors and be very difficult to find while debugging 
them. Hmmm...
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Frank Benoit wrote:

 Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to 
 work on.


 Awful!<



 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.



 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':



 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.

 a[1 .. 2].length #=> 1 ([a[1]])
 a[1 ... 2].length #=> 2 ([a[1], a[2]])

 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex



 Yes, this is useful for all use cases of ranges.
 I like '...'.



 Indeed it's not a bad idea... But it might be easily mistyped, lead to 
 strange off-by-one errors and be very difficult to find while debugging 
 them. Hmmm...



It's an awful idea. It's a non-idea. If "idea" had an antonym, that 
would be it.

I can't fathom what's on the mind of a person (not you, at least you
foresee some potential problems) who, even after patiently explained the
issues with this mental misfire, several times, still can bring
themselves to think it's not that bad.

Let me add one more, although more than sure someone will find a remedy
for it, too.

a...b

vs.

a.. .b

and of course the beauty

a....b

I don't plan to discuss minor features on this group anymore.


Andrei
May 19 2009
next sibling parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:

 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.



 wouldn't get your blood boiling so easily.  This is the internet, and
 we're talking about programming languages.  It's not like we're
 defusing a tense international arms conflict or something.



 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?



You're probably breaching some volume of posts limit. ;)
Thunderbird works nice.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92
fUcS3bLFqSaQ/Pk8KKVNzJM=
=k/lq
-----END PGP SIGNATURE-----
May 19 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



In about two years I've never heard Walter say something like that (even if may
think similar things every day), he doesn't need a pedestal. 

Thank you,
bearophile
May 19 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



This has nothing to do with a pedestal. It's simple pragmatics. We are 
fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) 
around here, and that's counterproductive.

Some of language design and most of syntax design are subjective. We all 
have a tendency to subjectively prefer features that we created and to 
be more critical of features that others have created. It's natural. 
They call it the better-than-average bias 
(http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency 
as much as the next guy, but I also like to believe I do not let that 
mask my reasoning too bad. That is, I wouldn't go at any length to 
defend a no-win case and argue against others while at the same time 
consistently ignoring any explanation given several times and in several 
forms.

Case in point: omitting the trailing parens in function calls... I got 
destroyed on that one :o).


Andrei
May 19 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



 This has nothing to do with a pedestal. It's simple pragmatics. We are 
 fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) 
 around here, and that's counterproductive.
 
 Some of language design and most of syntax design are subjective. We all 
 have a tendency to subjectively prefer features that we created and to 
 be more critical of features that others have created. It's natural. 
 They call it the better-than-average bias 
 (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency 
 as much as the next guy, but I also like to believe I do not let that 
 mask my reasoning too bad. That is, I wouldn't go at any length to 
 defend a no-win case and argue against others while at the same time 
 consistently ignoring any explanation given several times and in several 
 forms.
 
 Case in point: omitting the trailing parens in function calls... I got 
 destroyed on that one :o).
 
 
 Andrei



I think the other effect is we don't often have time to think about our 
suggestions for very long... Design is a process and something often 
"sounds good at the time". Consider the A{} syntax for templates... a 
whole newsgroup, a month of discussion, and it took until Walter started 
implementing it to realize the syntactic ambiguity.

Having more heads to think about a syntactic change can't be a bad thing.
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



 This has nothing to do with a pedestal. It's simple pragmatics. We are 
 fulfilling Wadler's law 
 (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and 
 that's counterproductive.

 Some of language design and most of syntax design are subjective. We 
 all have a tendency to subjectively prefer features that we created 
 and to be more critical of features that others have created. It's 
 natural. They call it the better-than-average bias 
 (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that 
 tendency as much as the next guy, but I also like to believe I do not 
 let that mask my reasoning too bad. That is, I wouldn't go at any 
 length to defend a no-win case and argue against others while at the 
 same time consistently ignoring any explanation given several times 
 and in several forms.

 Case in point: omitting the trailing parens in function calls... I got 
 destroyed on that one :o).


 Andrei



 I think the other effect is we don't often have time to think about our 
 suggestions for very long... Design is a process and something often 
 "sounds good at the time". Consider the A{} syntax for templates... a 
 whole newsgroup, a month of discussion, and it took until Walter started 
 implementing it to realize the syntactic ambiguity.
 
 Having more heads to think about a syntactic change can't be a bad thing.



Good point. "Think" is key :o). I'm sure it's often happened to many of 
us to share with a friend something we spent nights poring over, for 
them to come with what they're convinced is a much better idea after 
dignifying the matter with five seconds worth of thinking.


Andrei
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Robert Fraser wrote:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



 This has nothing to do with a pedestal. It's simple pragmatics. We 
 are fulfilling Wadler's law 
 (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and 
 that's counterproductive.

 Some of language design and most of syntax design are subjective. We 
 all have a tendency to subjectively prefer features that we created 
 and to be more critical of features that others have created. It's 
 natural. They call it the better-than-average bias 
 (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that 
 tendency as much as the next guy, but I also like to believe I do not 
 let that mask my reasoning too bad. That is, I wouldn't go at any 
 length to defend a no-win case and argue against others while at the 
 same time consistently ignoring any explanation given several times 
 and in several forms.

 Case in point: omitting the trailing parens in function calls... I 
 got destroyed on that one :o).


 Andrei



 I think the other effect is we don't often have time to think about 
 our suggestions for very long... Design is a process and something 
 often "sounds good at the time". Consider the A{} syntax for 
 templates... a whole newsgroup, a month of discussion, and it took 
 until Walter started implementing it to realize the syntactic ambiguity.

 Having more heads to think about a syntactic change can't be a bad thing.



 Good point. "Think" is key :o).



And another thing is, of course, that even a simple language can become 
too hard for a normal programmer, if it becomes too elegant or assumes 
too much generalizing, memorizing, and abstract thinking from the 
programmer when he is coding.

Some of the vociferous things (well, like the trailing parens thing) may 
be related to that.

So, this NG serves a purpose in helping the language stay near most 
regular programmers' reach. Wich is a must, if we intend to take over 
the world.
May 19 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



 This has nothing to do with a pedestal. It's simple pragmatics. We are 
 fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) 
 around here, and that's counterproductive.



Yeah. But more important is, of course, that you are important to the 
development of D, even on your own. That means, that unless you are 
careful with the time spent on this newsgroup, it will unduely eat away 
from your time with actual development. (And even thinking, in some cases.)

For example, spending copious amounts of ink on trying to explain some 
of the most esoteric features to some who have no chance of getting it 
with any amount of explanation, is a waste of time. Let the ideas 
trickle down. At the end of the day (er, actually, the month), the guys 
sitting next to him will explain it in more suitable terms anyway.

Also, sometimes being too terse, only causes a flurry of (either 
misunderstandings, or) a barrage of questions, that you then have to 
answer, instead of answering properly the first time around.

BUT, THIS IS not important, and please, don't take the above personally. 
It was just thoughts in response to "not planning to discuss minor 
features". They're important too.

AND I'm not perfect either. Definitely not.
May 19 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



Walter hasn't done it in 10 years in this NG.
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



 Walter hasn't done it in 10 years in this NG.



There's only one Walter!

Andrei
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.



 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.



 Walter hasn't done it in 10 years in this NG.



 There's only one Walter!



:-)
May 19 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Let me add one more, although more than sure someone will find a remedy
 for it, too.
 
 a...b
 
 vs.
 
 a.. .b
 
 and of course the beauty
 
 a....b



Oh, and this speaks more about the .b syntax than anything else. Does 
anyone actually use this...? If it was removed, b could still be 
accessed by its fully-qualified name, so its' removal not a huge loss.
May 19 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Andrei Alexandrescu wrote:

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b



 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.



"But that will make porting C code harder"

Guess who'll say that. ;-)
May 19 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:

 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.



 "But that will make porting C code harder"
 
 Guess who'll say that. ;-)



??? C allows .x to access a global member? You learn something useless 
every day...
May 19 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Ary Borenszweig wrote:

 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.



 "But that will make porting C code harder"

 Guess who'll say that. ;-)



 ??? C allows .x to access a global member? You learn something useless 
 every day...



Aaaaaaaaaaah... I thought they were talking about .1, .2, etc.

I forgot about .foo
May 19 2009
prev sibling next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:

 Robert Fraser wrote:

 Frank Benoit wrote:

 Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to 
 work on.


 Awful!<



 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.



 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':



 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.

 a[1 .. 2].length #=> 1 ([a[1]])
 a[1 ... 2].length #=> 2 ([a[1], a[2]])

 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex



 Yes, this is useful for all use cases of ranges.
 I like '...'.



 Indeed it's not a bad idea... But it might be easily mistyped, lead to 
 strange off-by-one errors and be very difficult to find while 
 debugging them. Hmmm...



 It's an awful idea. It's a non-idea. If "idea" had an antonym, that 
 would be it.
 
 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



I don’t see a reason not to restrict other features to introduce a new 
one. I never used .foo to access the global scope or .1 for floating 
point literals. But what I do use very often is array[n..m + 1], which 
would ease things for quite a lot of things going on when working with 
arrays. Of course it’s just syntactic sugar, but so is the whole slicing 
feature. It could easily be done in the standard library.

So I’m not demanding anything, I’m just providing my very own thoughts 
on this topic. If there are too many obstacles then it’s probably not 
worth it. The thing is, I don’t know half as much as most of the guys 
here do, so I don’t see those obstacles at first glance. Please bear 
with me. :)


 Let me add one more, although more than sure someone will find a remedy
 for it, too.
 
 a...b



inclusive range from a to b


 vs.
 
 a.. .b



exclusive range from a to .b

Personally, I see “...” as an atomic operator, like “!=” or “==”. I 
wouldn’t ever recognize “.. .” as “...” or “! =” as “!=”.
Additionally, 
I add a space before and after every operator, so there’s no ambiguity 
in any way, plus it’s nicely recognizable what the hell is going on. If 
it was for me, I’d even go as far as to make this a requirement in the 
specification. But that would upset downs.

Actually, what about “…” as inclusive range operator? :P I’d love that.



 and of course the beauty
 
 a....b



Inclusive range from “a” to “.b”? Pretty clear in this *particular*
case. ;)



 I don't plan to discuss minor features on this group anymore.



But.. bike shed discussions are fun! Seriously, though — I learn a lot 
thanks to people “nitpicking” other people’s ideas, showing corner 
cases, obstacles and so on. So please, don’t stop discussing minor 
features. :)
May 20 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



 Your post is emotional rather than rational.



Agreed. In my defense, let me mention that I've been rational in my 
previous 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b



 a..b vs a.b - no one complains



You see, you didn't understand my point. My point was that the 
introduction of a space changes semantics. We should avoid that.


 It also gracefully solves an issue with uniform distribution
 
 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)



Yeah, and this does something else:

uniform(0....int.max)

and if you use an alias we also have:

uniform(0.....A.max)

It's interesting how there is a continuum of number of "." that still 
lead to compilable code that does different things every time. Perfect 
material for "Why D is a horrible language" articles.


Andrei
May 20 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



 Your post is emotional rather than rational.



 Agreed. In my defense, let me mention that I've been rational in my 
 previous 50 posts on the topic :o).
 

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b



 a..b vs a.b - no one complains



 You see, you didn't understand my point. My point was that the 
 introduction of a space changes semantics. We should avoid that.
 

 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)



 Yeah, and this does something else:
 
 uniform(0....int.max)
 
 and if you use an alias we also have:
 
 uniform(0.....A.max)
 
 It's interesting how there is a continuum of number of "." that still 
 lead to compilable code that does different things every time. Perfect 
 material for "Why D is a horrible language" articles.



This is easily solved by making the lexer not allow the "...." token, or 
   "....." token, etc. (maximum 3 dots.) This way you are forced to 
insert a space there to make your intention clear, and you can never 
have bugs like that.

Perfect material for "Why D is a beautiful language" articles.
May 20 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 This is easily solved by making the lexer not allow the "...." token, or 
   "....." token, etc. (maximum 3 dots.) This way you are forced to 
 insert a space there to make your intention clear, and you can never 
 have bugs like that.



I agree that things could be fixed. This is, however, a hack because a 
lexer is not supposed to operate that way. Lexers are "maximum munch".

So we're looking at a number of problems here. One is that we'd need to 
change the language in several places to accommodate an ill-conceived 
feature. Another is that I can't seem to get some very simple points 
across such as the difference between a token and a non-terminal, in 
spite of having tried repeatedly and in various forms. Another is that I 
am becoming suffocated with self-righteousness and therefore am losing 
goodwill in this thread at an exponentially-increasing rate. Finally, it 
looks like such discussions necessitate more than a full-time job.


Andrei
May 20 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

...

 
 So we're looking at a number of problems here. One is that we'd need to 
 change the language in several places to accommodate an ill-conceived 
 feature. Another is that I can't seem to get some very simple points 
 across such as the difference between a token and a non-terminal, in 
 spite of having tried repeatedly and in various forms. Another is that I 
 am becoming suffocated with self-righteousness and therefore am losing 
 goodwill in this thread at an exponentially-increasing rate. Finally, it 
 looks like such discussions necessitate more than a full-time job.
 
 
 Andrei



You could ask Walter for advice on most of these matters ;)
May 20 2009
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



 Your post is emotional rather than rational.



 Agreed. In my defense, let me mention that I've been rational in my 
 previous 50 posts on the topic :o).
 

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b



 a..b vs a.b - no one complains



 You see, you didn't understand my point. My point was that the 
 introduction of a space changes semantics. We should avoid that.
 



Like,

a- --b

vs.

a-- -b

?


 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)



 Yeah, and this does something else:
 
 uniform(0....int.max)
 
 and if you use an alias we also have:
 
 uniform(0.....A.max)
 
 It's interesting how there is a continuum of number of "." that still 
 lead to compilable code that does different things every time. Perfect 
 material for "Why D is a horrible language" articles.
 
 
 Andrei
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained 
 the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



 Your post is emotional rather than rational.



 Agreed. In my defense, let me mention that I've been rational in my 
 previous 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b



 a..b vs a.b - no one complains



 You see, you didn't understand my point. My point was that the 
 introduction of a space changes semantics. We should avoid that.



 Like,
 
 a- --b
 
 vs.
 
 a-- -b
 
 ?



Yes, like that. I didn't say there aren't any right now. I said we 
should avoid that.


Andrei
May 20 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that
  would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.






 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b






 of a space changes semantics. We should avoid that.


 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)




 uniform(0....int.max)

 and if you use an alias we also have:

 uniform(0.....A.max)

 It's interesting how there is a continuum of number of "." that still lead
 to compilable code that does different things every time. Perfect material
 for "Why D is a horrible language" articles.



 Isn't 0...a already a horrendously awful non-idea and mental misfire
 by these arguments?
 
 --bb



The problems increase exponentially with the number of dots.

Andrei
May 20 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:

 It also gracefully solves an issue with uniform distribution
 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)



To avoid the possible confusion caused by ... Chapel uses ..#

uniform(0 .. int.max)  - exclusive
uniform(0 ..# int.max) - inclusive

Bye,
bearophile
May 20 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
bearophile wrote:

 
 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }





  void classify(char c) {
      write("You passed ");
      switch (c) {
         case '#':
            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }

This is usable, easy to read -- and the programmer has no problem to 
remember that .. works differently in case statements than in ranges.

There are other places in D that place an undue burden on the 
programmer, but this is not IMHO one of them.

--------------------

My pet peeve with case is that, since we don't seem to be getting rid of 
break (and use some word for fall-through instead, "which would save a 
good deal of ink"), we should at least try to make break more 
conspicuous. I can name a hundred times I've forgotten a break from 
somewhere. So the canonical indentation should be like this:


  void classify(char c) {
      write("You passed ");
      switch (c) {
         case '#':
            writeln("a hash sign.");
         break;
         case '0' .. case '9':
            writeln("a digit.");
         break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
         break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
         break;
         default:
            writeln("quite a character!");
         break;
      }
  }

(It'd look better when the cases have more lines, but still.) Currently 
in D, break is at least as important as case, therefore it deserves a 
conspicuous place, hence my suggestion.
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 bearophile wrote:

 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }



 
 
  void classify(char c) {
      write("You passed ");
      switch (c) {
         case '#':
            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }
 
 This is usable, easy to read -- and the programmer has no problem to 
 remember that .. works differently in case statements than in ranges.



I'd like to keep the (non-required) colon after the first expression in 
a ".." pair of case labels, that is:

case '0': .. case '9':

as opposed to

case '0' .. case '9':

That way it is abundantly clear that the notation has nothing in common 
with expression1 .. expression2. The error message if someone forgot the 
':' can easily be made clear.


Andrei
May 18 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-05-18 22:39:23 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 I'd like to keep the (non-required) colon after the first expression in 
 a ".." pair of case labels, that is:
 
 case '0': .. case '9':
 
 as opposed to
 
 case '0' .. case '9':
 
 That way it is abundantly clear that the notation has nothing in common 
 with expression1 .. expression2. The error message if someone forgot 
 the ':' can easily be made clear.



You could have '::' denote an inclusive range. :-)

	case '0'..'9': // '9' excluded
	case '0'::'9': // '9' included

Seriously, I don't care much what the syntax is as long as it's 
different from the one used for exclusive range. Both:

	case '0': .. case '9':

looks acceptable to me. Although I agree with others about the 
inconsistency of using ".." for an inclusive range, having it finish 
with "case '9':" seems to indicate clearly the intent to include the 
last element.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 bearophile wrote:

 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }





  void classify(char c) {
      write("You passed ");
      switch (c) {
         case '#':
            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }

 This is usable, easy to read -- and the programmer has no problem to 
 remember that .. works differently in case statements than in ranges.



 I'd like to keep the (non-required) colon after the first expression in 
 a ".." pair of case labels, that is:
 
 case '0': .. case '9':
 
 as opposed to
 
 case '0' .. case '9':
 
 That way it is abundantly clear that the notation has nothing in common 
 with expression1 .. expression2. The error message if someone forgot the 
 ':' can easily be made clear.



So concatenating ranges would be

     case '0': .. case '9': case 'a': .. case 'z':
         do something

which then could be written, depending on programmer preferences

     case '0':
     .. case '9':
     case 'a':
     .. case 'z':
         do something

or

     case '0': .. case '9':
     case 'a': .. case 'z':
         do something

While I'd prefer to omit the colon, I can live with it.
May 18 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Georg Wrede wrote:

 This is usable, easy to read -- and the programmer has no problem to
 remember that .. works differently in case statements than in ranges.



You're making two assumptions here:
1. That inclusive ranges are preferable inside 'case' statements.
2. That non-inclusive ranges are preferable outside 'case' statements.

I don't buy it.  The issue of inclusive versus non-inclusive ranges is
*exactly the same* in and outside 'case' statements.

// Non-inclusive:
foreach (c; start .. middle) doA(c);
foreach (c; middle .. end) doB(c);
foreach (c; start .. end) {
  switch (c) {
    case start .. middle:
      doA(c);
      break;
    case middle .. end:
      doA(c);
      break;
  }
}

// Inclusive:
foreach (c; 'a' ... 'z') doSomething(c);
switch (c) {
  case 'a' ... 'z':
    doSomething(c);
    break;
}
foreach (c; 0 ... int.max) doSomething(c);
switch (c) {
  case 0 ... int.max:
    doSomething(c);
    break;
}


Since I don't accept your assumptions, I see no point in arguing whether
or not those assumptions would justify overloading the '..' operator to
have one meaning in 'case' statements and another meaning elsewhere.


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:

 Georg Wrede wrote:

 This is usable, easy to read -- and the programmer has no problem to
 remember that .. works differently in case statements than in ranges.



 You're making two assumptions here:
 1. That inclusive ranges are preferable inside 'case' statements.



Yes. The point of case a: .. case b: is to save you from writing case a: 
case a+1: and so on up to case b:. There is no exclusion. You write now 
the cases you want to handle.


 2. That non-inclusive ranges are preferable outside 'case' statements.



Of course. One word: STL.


 I don't buy it.  The issue of inclusive versus non-inclusive ranges is
 *exactly the same* in and outside 'case' statements.



No.


Andrei
May 18 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:

 Rainer Deyke wrote:

 You're making two assumptions here:
 1. That inclusive ranges are preferable inside 'case' statements.



 Yes. The point of case a: .. case b: is to save you from writing case a:
 case a+1: and so on up to case b:. There is no exclusion. You write now
 the cases you want to handle.
 

 2. That non-inclusive ranges are preferable outside 'case' statements.



 Of course. One word: STL.



I can think of two concrete advantages of half-open/non-inclusive ranges:
  1. When using zero-based indexing, '0 .. length' expresses all
elements in a sequence.
  2. A range can be 'split' on any point 'x' into subranges '0 .. x' and
'x .. length'.
Both of these advantages also apply to 'case' statements:

const int
  first_nullary_instruction = 5,
  first_unary_instruction = 5,
  first_binary_instruction = 10,
  num_instructions = 15;

switch (c) {
  case first_nullary_instruction .. first_unary_instruction:
    executeNullaryInstruction();
    break;
  case first_unary_instruction .. first_binary_instruction:
    executeUnaryInstruction();
    break;
  case first_binary_instruction .. num_instructions:
    executeUnaryInstruction();
    break;
  default:
    illegalInstruction();
    break;
}

I can think of two concrete advantages of inclusive ranges:
  1. The past-the-end element may not be known.
  2. The past-the-end element may not be representable.
Both of these advantages also outside 'case' statements:

foreach (i; 0 ... int.max) doSomethingWith(i);


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 5:38 PM, div0 <div0 users.sourceforge.net> wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:

 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that wo=













 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained t=













 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remed=













 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.



 wouldn't get your blood boiling so easily. =A0This is the internet, and
 we're talking about programming languages. =A0It's not like we're
 defusing a tense international arms conflict or something.



 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?



 You're probably breaching some volume of posts limit. ;)
 Thunderbird works nice.

 - --
 My enormous talent is exceeded only by my outrageous laziness.
 http://www.ssTk.co.uk
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92
 fUcS3bLFqSaQ/Pk8KKVNzJM=3D
 =3Dk/lq
 -----END PGP SIGNATURE-----



I'd vastly prefer a newsreader.  Sadly I've yet to encounter a
newsreader that can store its state in a shared location, which is
important for me as I need to be able to access the newsgroups from
multiple computers.  Cough, googlegroups, cough, but whatever.

It might be the way I snip out parts of quoted posts.  Maybe it
doesn't like that.
May 19 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that
 =A0would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained th=










 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



 Your post is emotional rather than rational.



 Agreed. In my defense, let me mention that I've been rational in my previ=




 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b



 a..b vs a.b - no one complains



 You see, you didn't understand my point. My point was that the introducti=




 of a space changes semantics. We should avoid that.


 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max) =A0- exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)



 Yeah, and this does something else:

 uniform(0....int.max)

 and if you use an alias we also have:

 uniform(0.....A.max)

 It's interesting how there is a continuum of number of "." that still lea=




 to compilable code that does different things every time. Perfect materia=




 for "Why D is a horrible language" articles.



Isn't 0...a already a horrendously awful non-idea and mental misfire
by these arguments?

--bb
May 20 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that woul=







 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.



 Maybe if you weren't prone to such humorous bouts of hyperbole, you
 wouldn't get your blood boiling so easily. =A0This is the internet, and
 we're talking about programming languages. =A0It's not like we're
 defusing a tense international arms conflict or something.



Also, why does the puremagic mailing list software hate me so much
when it comes to threading my replies?
May 19 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 May 2009 16:48:41 -0400, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:


 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?



FWIW, your replies also sometimes thread your replies in a new thread in  
opera (and I recall this happening with Outlook Express before I  
switched).  There must be something your client isn't transmitting  
properly to signal it's the continuation of a thread.

Probably you should examine your headers closely on replies that do get  
threaded properly vs. replies that for some reason start a new thread.

-Steve
May 19 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:
 

 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.



 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



But it's not "blarf". It's "case". I am floored that nobody sees the 
elegance of that syntax.

Andrei
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",



Such attitude/purposes have created the monkey mess named Perl :-]

Bye,
bearophile
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:


 Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",



 Such attitude/purposes have created the monkey mess named Perl :-]



I submit the D words 'static', 'auto' and 'scope' as examples of this too.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
 

 Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",






 I submit the D words 'static', 'auto' and 'scope' as examples of this too.



When was the last time you had trouble with "static"? Can you show a 
snippet of code that's confusing because of it?

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:58:19 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
 

 Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",






 I submit the D words 'static', 'auto' and 'scope' as examples of this too.



 When was the last time you had trouble with "static"? Can you show a 
 snippet of code that's confusing because of it?



"not having a trouble" and "not being consistant" are two different things.

For example, I have no trouble with ".." meaning exclusive range inside a
'[' ']' pair, and an inclusive range in a 'case' statement. That does not
trouble me at all and yet it is an inconsistancy.

But back to your question ... here is 'static' used with three different
meanings within three lines of code.

-------
module xyzzy;
import std.stdio;

version(X) const int y = 1;
else       const int y = -1;
           
static this() {
   static if (y == 1) 
      static int x = 0;
   else
      static int x = 42;
 
   writefln("X=%d Y=%d", x,y);
}

void main()
{
   
}

----------

But maybe that's just me?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 But back to your question ... here is 'static' used with three different
 meanings within three lines of code.
 
 -------
 module xyzzy;
 import std.stdio;
 
 version(X) const int y = 1;
 else       const int y = -1;
            
 static this() {
    static if (y == 1) 
       static int x = 0;
    else
       static int x = 42;
  
    writefln("X=%d Y=%d", x,y);
 }
 
 void main()
 {
    
 }
 
 ----------
 
 But maybe that's just me?



Doesn't confuse me one bit.

Andrei
May 18 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:05:03 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 But back to your question ... here is 'static' used with three different
 meanings within three lines of code.
 
 -------
 module xyzzy;
 import std.stdio;
 
 version(X) const int y = 1;
 else       const int y = -1;
            
 static this() {
    static if (y == 1) 
       static int x = 0;
    else
       static int x = 42;
  
    writefln("X=%d Y=%d", x,y);
 }
 
 void main()
 {
    
 }
 
 ----------
 
 But maybe that's just me?



 Doesn't confuse me one bit.



That's nice.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:


 It's all a matter of perspective. I see both as begin .. end. That may be
 the same reason why I think addition when I see foo(bar()) + baz(37). The
 extra cruft is more or less ignored when figuring out the basics of what is
 going on.



 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



 elegance of that syntax.



 So your argument is that "case" inherently deserves a special case?



It has been a keyword with a specific meaning for many years. That's 
bound to mean something.


 I don't think it's a terrible syntax, but I wouldn't go as far as to
 call it elegant.  I'm with bear that it would be better if we could
 come up with some syntax that means "inclusive range" everywhere.
 Rather than introducing special cases.  Special cases are generally a
 sign that something has gone wrong in a language design.



I completely disagree that that's a special case. ".." is punctuation. 
You can't pretend punctuation has the same meaning everywhere in a 
programming language.

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



I'm a bit confused. Are you saying that one must expect that the meaning of
punctuation in a programming language depends on the context the
punctuation is found in?

If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
.. b:" can mean inclusive range, no?


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?



How many meanings does '[' have in your favorite programming language?


Andrei
May 18 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?



 How many meanings does '[' have in your favorite programming language?



One.

But how is your question an answer to my question?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:
 

 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



 punctuation in a programming language depends on the context the
 punctuation is found in?






 One.



No.

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:
 

 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



 punctuation in a programming language depends on the context the
 punctuation is found in?






 One.



 No.



But you never asked for the name of my favourite language?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:
 

 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



 punctuation in a programming language depends on the context the
 punctuation is found in?












 But you never asked for the name of my favourite language?
 



Yah, I realized my flawed supposition after sending :o). So, what is it?

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:20:11 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 But you never asked for the name of my favourite language?







 Yah, I realized my flawed supposition after sending :o). So, what is it?



Actually I have two - Forth and Euphoria, but D comes a close second.

Anyways ... back to the actually question that I asked and you haven't got
around to answering yet -- (you're not doing politian training are you :-))

On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.



I'm a bit confused. Are you saying that one must expect that the meaning of
punctuation in a programming language depends on the context the
punctuation is found in?

If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
.. b:" can mean inclusive range, no?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?
 
 If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
 .. b:" can mean inclusive range, no?



No, you don't understand. But I sworn that I'll explain it for the last 
time in another post, so I'm out of times I can explain it.

Let me make a separate point. With "...", people just defined the space 
operator. What's the space operator? Changes the meaning of 0...10 in 
two distinct ways:

0...10 is an all-inclusive integer range from 0 to 10
0. ..10 is a right-open floating-point range from 0 to 10
0.. .10 is a right-open floating-point range from 0 to 0.1

Not to mention:

0.....10 is an all-inclusive floating-point range from 0 to .1 (if I 
counted my dots right).

I have no doubt somebody will find this all intuitive and pleasing on 
the eye, and will suggest a couple of additional constructs and keywords 
to improve things.


Andrei
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gutd12$16h9$1 digitalmars.com...

 Let me make a separate point. With "...", people just defined the space 
 operator. What's the space operator? Changes the meaning of 0...10 in two 
 distinct ways:

 0...10 is an all-inclusive integer range from 0 to 10
 0. ..10 is a right-open floating-point range from 0 to 10
 0.. .10 is a right-open floating-point range from 0 to 0.1



So '1.' and '.1'  are legal numbers in D? I would have assumed that any 
numerical literal with a decimal point would require at least one digit on 
both sides of the decimal point. Not sure I see a good reason for this not 
to be required.
May 19 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gutd12$16h9$1 digitalmars.com...

 Let me make a separate point. With "...", people just defined the space 
 operator. What's the space operator? Changes the meaning of 0...10 in two 
 distinct ways:

 0...10 is an all-inclusive integer range from 0 to 10
 0. ..10 is a right-open floating-point range from 0 to 10
 0.. .10 is a right-open floating-point range from 0 to 0.1



 So '1.' and '.1'  are legal numbers in D? I would have assumed that any 
 numerical literal with a decimal point would require at least one digit on 
 both sides of the decimal point. Not sure I see a good reason for this not 
 to be required. 



Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even 
if we don't consider "the new space operator" implications!!!!!! It 
really makes it hard to spot the odd decimal value when you're not 
expecting it there.

That's mainly an American invention. In Europe, in most countries, you 
couldn't ever write .1 without everybody shouting typo!

Had D been invented in Europe, .1 would never have crossed anybodys 
mind. After several decades, I'm still uncomfortable when anybody writes 
.1, be it in programming or on street billboards.


Then we could go on (not that Andrei ever meant it, so I'm not serious 
here), and write

1.0..2.0   an all-inclusive floating range from 1.0 to 2.0
1.0 ..2.0   a right-inclusive floating range from 1.0 to 2.0
1.0.. 2.0   a left-inclusive floating range from 1.0 to 2.0
1.0 .. 2.0   a non-inclusive floating range from 1.0 to 2.0

1..2   an all-inclusive integer range from 1 to 2
1 ..2   a right-inclusive integer range from 1 to 2
1.. 2   a left-inclusive integer range from 1 to 2
1 .. 2   a non-iclusive integer range from 1 to 2

(And we didn't even need the triple-dot operator!)

But this would break existing code, make white-space significant, choke 
Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted 
languages (read: embarrassing).

(Not that whitespace isn't already significant in a way, otherwise we 
could write 1 . 2 and it would be the same thing as 1.2.)


Actually, I'm not sure there would be ambuguity with the American 
decimals, either:

1....2   an all-inclusive range from 1. to .2
1. ...2   a right-inclusive range from 1. to .2
1... .2   a left-inclusive range from 1. to .2
1. .. .2   a non-inclusive range from 1. to .2
1...2   Error: improperly mixing integers and floating point.

Note, I'm personally against having decimals in ranges in the first place.
May 19 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:
 

 So '1.' and '.1'  are legal numbers in D? I would have assumed that any
 numerical literal with a decimal point would require at least one digit on
 both sides of the decimal point. Not sure I see a good reason for this not
 to be required.



 we don't consider "the new space operator" implications!!!!!! It really
 makes it hard to spot the odd decimal value when you're not expecting it
 there.

 That's mainly an American invention. In Europe, in most countries, you
 couldn't ever write .1 without everybody shouting typo!

 Had D been invented in Europe, .1 would never have crossed anybodys mind.
 After several decades, I'm still uncomfortable when anybody writes .1, be it
 in programming or on street billboards.



 For what it's worth, I'm American and have neither seen the 'one-sided
 floating-point number' used in public nor am I comfortable with it
 being in a programming language.  It just doesn't look right.



Yeah. If it was up to me, it'd be forbidden.
May 19 2009
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Georg Wrede wrote:

 Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:

 After several decades, I'm still uncomfortable when anybody writes 
 .1, be it
 in programming or on street billboards.



 For what it's worth, I'm American and have neither seen the 'one-sided
 floating-point number' used in public nor am I comfortable with it
 being in a programming language.  It just doesn't look right.



 Yeah. If it was up to me, it'd be forbidden.
 



Same here.
May 19 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Alexander Pánek:

 Same here.



I too don't like .56, I add a zero when I see a literal like that in the code.
But what about Walter? :-)

Bye,
bearophile
May 19 2009
parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bearophile wrote:

 Alexander Pánek:

 Same here.



 I too don't like .56, I add a zero when I see a literal like that in the code.
But what about Walter? :-)
 
 Bye,
 bearophile



I always use it, but I won't be bothered if it was outlawed.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKEvG/T9LetA9XoXwRAkIaAKCdqOLBL9X+KwRm/vAmtoxVR4KXCQCeOaQt
Tsgo4JIuNIfP9UgiTaMLLtM=
=eo39
-----END PGP SIGNATURE-----
May 19 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:guu95i$2p6c$1 digitalmars.com...

 That's mainly an American invention. In Europe, in most countries, you 
 couldn't ever write .1 without everybody shouting typo!



*shrug*, I've lived in the US all my life and it's never occurred to me to 
consider .1 anything but a typo (or at least laziness).



 Then we could go on (not that Andrei ever meant it, so I'm not serious 
 here), and write

 1.0..2.0   an all-inclusive floating range from 1.0 to 2.0
 1.0 ..2.0   a right-inclusive floating range from 1.0 to 2.0
 1.0.. 2.0   a left-inclusive floating range from 1.0 to 2.0
 1.0 .. 2.0   a non-inclusive floating range from 1.0 to 2.0

 1..2   an all-inclusive integer range from 1 to 2
 1 ..2   a right-inclusive integer range from 1 to 2
 1.. 2   a left-inclusive integer range from 1 to 2
 1 .. 2   a non-iclusive integer range from 1 to 2

 (And we didn't even need the triple-dot operator!)

 But this would break existing code, make white-space significant, choke 
 Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted 
 languages (read: embarrassing).



Hee hee hee :)


 (Not that whitespace isn't already significant in a way, otherwise we 
 could write 1 . 2 and it would be the same thing as 1.2.)



Or "int foo" vs "intfoo".
May 19 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote:


 On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.



 punctuation in a programming language depends on the context the
 punctuation is found in?






 One.



 No.



 But you never asked for the name of my favourite language?



 Does it have string or character literals?  Then there's probably at
 least two meanings.  ;-P



Huh? "two meanings" of '['   ... is that what you are saying?

Ok, the language has both string literals and character literals, so how
does that imply that '[' has two meanings?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 19 2009
parent reply Max Samukha <outer space.com> writes:
On Tue, 19 May 2009 18:23:25 +1000, Derek Parnell <derek psych.ward>
wrote:


On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote:


 On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.



 punctuation in a programming language depends on the context the
 punctuation is found in?






 One.



 No.



 But you never asked for the name of my favourite language?



 Does it have string or character literals?  Then there's probably at
 least two meanings.  ;-P



Huh? "two meanings" of '['   ... is that what you are saying?

Ok, the language has both string literals and character literals, so how
does that imply that '[' has two meanings?



In D, [ has at least four meanings:

auto a = [1, 2, 3]; - array initializer
a[1] - indexing operator
a[c..d] - slicing operator 
int[10] - static array declarator

C++ has [] for lambdas (no! C++ should be banned by the international
law, if there is any)
May 19 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Max Samukha wrote:

 ...
 
 In D, [ has at least four meanings:
 
 auto a = [1, 2, 3]; - array initializer
 a[1] - indexing operator
 a[c..d] - slicing operator 
 int[10] - static array declarator
 
 C++ has [] for lambdas (no! C++ should be banned by the international
 law, if there is any)



Actually, it's more like two.

a[1]
int[]
int[10]
a[c..d]

These are all subscript notation.

[1, 2, 3]
[a:b, c:d]

These are array literal notation.

From a strict, semantics nazi point of view, that's really six meanings.
But that's like arguing there's a meaningful difference between a.b and
A.b where a is a value and A is a type.

It's worth noting that I still sometimes forget that [...] is for array
literals, but I never ever forget its use for subscripting.

  -- Daniel
May 19 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:


 So '1.' and '.1' =A0are legal numbers in D? I would have assumed that an=







 numerical literal with a decimal point would require at least one digit =







 both sides of the decimal point. Not sure I see a good reason for this n=







 to be required.



 Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even i=




 we don't consider "the new space operator" implications!!!!!! It really
 makes it hard to spot the odd decimal value when you're not expecting it
 there.

 That's mainly an American invention. In Europe, in most countries, you
 couldn't ever write .1 without everybody shouting typo!

 Had D been invented in Europe, .1 would never have crossed anybodys mind.
 After several decades, I'm still uncomfortable when anybody writes .1, be=




 in programming or on street billboards.



For what it's worth, I'm American and have neither seen the 'one-sided
floating-point number' used in public nor am I comfortable with it
being in a programming language.  It just doesn't look right.
May 19 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.






 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing", and the most
 useful thing for switches is inclusive.



No! If I thought that, I would have said this is fine:

case 'a' .. 'z':

It is NOT fine because 'a' .. 'z' means one thing here and a different 
thing in another place. So I went for:

case 'a': .. case 'z':

specifically because case 'a': .. case 'z': does NOT have any meaning 
anywhere else.


Andrei
May 18 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gusuoi$ftk$2 digitalmars.com...

 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.



After reading that over and over many times, I think I finally see what you 
were trying to get at with that. People are supposed to see that as:

case 'a': case 'b': case 'c': /*snipped, but you get the idea*/ case 'x': 
case 'y': case 'z':

And everything except the first and last is just "shrunk down". I think I 
understand how that can be seen as elegance.

But others have brought up some very valid objections that I really have to 
agree with, and I'll add one more: A lot of people don't like the whole 
"fall-through" thing anyway and want to see D move farther from it rather 
than embracing it as this syntax seems to do.
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gusuoi$ftk$2 digitalmars.com...

 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.



 After reading that over and over many times, I think I finally see what you 
 were trying to get at with that. People are supposed to see that as:
 
 case 'a': case 'b': case 'c': /*snipped, but you get the idea*/ case 'x': 
 case 'y': case 'z':
 
 And everything except the first and last is just "shrunk down". I think I 
 understand how that can be seen as elegance.



Yes. I got a rush of endorphine out of that one.


 But others have brought up some very valid objections that I really have to 
 agree with, and I'll add one more: A lot of people don't like the whole 
 "fall-through" thing anyway and want to see D move farther from it rather 
 than embracing it as this syntax seems to do.



I dislike the fall through as much as you do.


Andrei
May 18 2009
parent grauzone <none example.net> writes:
 I dislike the fall through as much as you do.



What about fixing it?

My proposal was always to introduce a new, second syntax, which switches 
to sane semantics:

switch (x) {
    case(value) {
       //no fall through
    }
    case value2:
       //C compatibility, fall through
}

At least the colon should make the two syntaxes [proper plural?] 
unambiguous.
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.






 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing", and the most
 useful thing for switches is inclusive.



 No! If I thought that, I would have said this is fine:
 
 case 'a' .. 'z':
 
 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:
 
 case 'a': .. case 'z':
 
 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.



The colon is not needed there for understanding, and definitely not 
needed for remembering that .. in a case is inclusive. It's the overall 
context (being in a switch statement) that puts the programmer in the 
inclusive mindset.

     case 'a' .. case 'z':

is adequate. Besides, then we can have discontinuous ranges without 
changing the current behavior, since

     case 'a' .. case 'z':
     case 'A' .. case 'Z':
         do something

is the same as

     case 'a' .. case 'z': case 'A' .. case 'Z':
         do something

already now.
May 18 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:
 

 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.



 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



 But it's not "blarf". It's "case". I am floored that nobody sees the 
 elegance of that syntax.
 
 Andrei



I don't know if it's a consolation or throwing salt in your eyes, but I still
don't see the elegance of using the keyword for an enumerated set to represent
manifest constants.
May 18 2009
parent "Nick Sabalausky" <a a.a> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:gusvsq$i81$1 digitalmars.com...

 I don't know if it's a consolation or throwing salt in your eyes, but I 
 still don't see the elegance of using the keyword for an enumerated set to 
 represent manifest constants.



As a testament to the sucky-ness of "enum manifst constants", even though 
I've been seeing discussions about it for years, there hasn't been a single 
time where it's actually occurred to me to use it. Anytime I write in D, I 
still just keep using "const" instead of "enum" to creat my 
...*constants*... without even thinking about it.
May 18 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Bill Baxter wrote:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



Agreed.

Although non-inclusive ranges are common enough that they deserve their
own syntax, I think inclusive ranges are *also* important enough to
deserve their own syntax.  Writing '+1' is often error-prone or even
just plain wrong (such as when it leads to integer overflow).

I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
and similar to 'a .. b' without being too similar.  It does require the
programmer to pay attention, but that's unavoidable.  From there, it
naturally follows that 'case's in a 'switch' statement should follow the
same convention.

I don't believe it makes any sense to have inclusive ranges in 'switch'
statements and non-inclusive ranges everywhere else.  Inclusive ranges
are fairly common outside 'switch' statements, and non-inclusive ranges
are fairly common in 'switch' statements.


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:

 Bill Baxter wrote:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".



 Agreed.
 
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).
 
 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.



I swear I didn't see the difference til the third read. I thought you 
were kidding.

Even Perl would turn its nose at a significant semantic difference 
brought by the third period.


Andrei
May 18 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.



Not true: Perl has a '..' operator and a '...' operator with distinct
but similar meanings.  And as much as I loathe Perl in general, I don't
see anything wrong with that.  I am open to a reasonable alternate syntax.


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.



 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings.  And as much as I loathe Perl in general, I don't
 see anything wrong with that.  I am open to a reasonable alternate syntax.



Having both .. and ... wouldn't be too bad. They're insistinguishable 
only as long as one is not expecting a distinction. But with a 
programming language, they look dissimilar enough.

A side benefit would be to be able to specify inclusive and exclusive 
ranges both within switch statements and range contexts.

'0' ... '9'
'a' ... 'z'
a .. b
a ... b
0 .. middle
middle .. $

Of course, this idea will be drowned in a 2-month bicycle shed color 
discussion about which should be the inclusive range and which the 
exclusive one. And after that somebody suggests tokens for the remaining 
two inclusion permutations, and then we really can forget all this for good.
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.



 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings.  And as much as I loathe Perl in general, I don't
 see anything wrong with that.  I am open to a reasonable alternate 
 syntax.



 Having both .. and ... wouldn't be too bad. They're insistinguishable 
 only as long as one is not expecting a distinction. But with a 
 programming language, they look dissimilar enough.
 
 A side benefit would be to be able to specify inclusive and exclusive 
 ranges both within switch statements and range contexts.
 
 '0' ... '9'
 'a' ... 'z'
 a .. b
 a ... b
 0 .. middle
 middle .. $
 
 Of course, this idea will be drowned in a 2-month bicycle shed color 
 discussion about which should be the inclusive range and which the 
 exclusive one. And after that somebody suggests tokens for the remaining 
 two inclusion permutations, and then we really can forget all this for 
 good.



I'm now sorry I even mentioned the blessed thing. This must have been 
the worst discussion on language design, ever.

Andrei
May 18 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:09:21 -0500, Andrei Alexandrescu wrote:


 I'm now sorry I even mentioned the blessed thing. This must have been 
 the worst discussion on language design, ever.



LOL ... especially when these discussions have no influence on whatever the
outcome will eventually be.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.



 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings.  And as much as I loathe Perl in general, I don't
 see anything wrong with that.  I am open to a reasonable alternate 
 syntax.



 Having both .. and ... wouldn't be too bad. They're insistinguishable 
 only as long as one is not expecting a distinction. But with a 
 programming language, they look dissimilar enough.

 A side benefit would be to be able to specify inclusive and exclusive 
 ranges both within switch statements and range contexts.

 '0' ... '9'
 'a' ... 'z'
 a .. b
 a ... b
 0 .. middle
 middle .. $

 Of course, this idea will be drowned in a 2-month bicycle shed color 
 discussion about which should be the inclusive range and which the 
 exclusive one. And after that somebody suggests tokens for the 
 remaining two inclusion permutations, and then we really can forget 
 all this for good.



 I'm now sorry I even mentioned the blessed thing. This must have been 
 the worst discussion on language design, ever.



I was only half serious. :-)
May 18 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:


 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).



Agreed.


 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.  It does require the
 programmer to pay attention, but that's unavoidable.  From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.



Sorry, but I don't share your sense of "easy to read" here. The eye can
glaze over the third dot very easily and just not notice it.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:


 On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:
 

 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).



 Agreed.
 

 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.  It does require the
 programmer to pay attention, but that's unavoidable.  From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.



 Sorry, but I don't share your sense of "easy to read" here. The eye can
 glaze over the third dot very easily and just not notice it.
 
 -- 
 Derek Parnell
 Melbourne, Australia
 skype: derek.j.parnell



I disagree, the ... syntax was also my suggestion for the reason that it is a
very obvious syntax that isn't limited to only the switch ranges.

I don't think its that easy to miss a third dot, especially if there are spaces
around the operator, and the editor uses a fixed-width font (like any good
editor should).

If you want to be paranoid about confusion, comment it, just like closing }'s
are often seen with a comment of the opening statement, just like you would do:
} // version(Windows)
you can do:
case 1 ... 10: // inclusive

You could also configure your editor to color code them differently, I already
do that with a lot of other things, it gives the brain one more cue  to detect
what is going on.

And since the operator also leaves .. available for inclusive ranges you can do:
case FIRST .. LAST + 1:

or even better:
enum CASE_LAST = LAST + 1:
case FIRST .. CASE_LAST:

This goes along with the best feature of D: let the programmers do things the
way they want to.
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 3:29 PM, Jason House
<jason.james.house gmail.com> wrote:


 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.



Agreed.  If you tell someone   a .. b  means a non-inclusive range
from a to b, then ask them to guess what    blarf a .. blarf b  means,
I would be very surprised if many guessed "inclusive range from blarf
a  to blarf b".

... Unless they guess that the fact you were asking something which
should be so obvious meant that it was probably a trick question, in
which case they'd answer inclusive, that being the non-obvious answer.

--bb
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:


 It's all a matter of perspective. I see both as begin .. end. That may =










 the same reason why I think addition when I see foo(bar()) + baz(37). T=










 extra cruft is more or less ignored when figuring out the basics of wha=










 going on.



 Agreed. =A0If you tell someone =A0 a .. b =A0means a non-inclusive range
 from a to b, then ask them to guess what =A0 =A0blarf a .. blarf b =A0me=







 I would be very surprised if many guessed "inclusive range from blarf
 a =A0to blarf b".



 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.



So your argument is that "case" inherently deserves a special case?

I don't think it's a terrible syntax, but I wouldn't go as far as to
call it elegant.  I'm with bear that it would be better if we could
come up with some syntax that means "inclusive range" everywhere.
Rather than introducing special cases.  Special cases are generally a
sign that something has gone wrong in a language design.

--bb
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.



 So your argument is that "case" inherently deserves a special case?



Thinking about it more, I guess you must actually be seeing it as a
rule of   " '..' always does the most useful thing", and the most
useful thing for switches is inclusive.  I see that as a local minimum
in the design space that would be exceeded by having a good syntax to
express inclusive ranges when you want them.

--bb
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 5:33 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.



 So your argument is that "case" inherently deserves a special case?



 Thinking about it more, I guess you must actually be seeing it as a
 rule of =A0 " '..' always does the most useful thing", and the most
 useful thing for switches is inclusive.



 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different th=




 in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning
 anywhere else.



Well, I'm floored that you find that at all elegant.  It's "elegant"
in much the same way using static to mean 12 different things,
depending upon context, is "elegant".   Although here it's worse I'd
say because the meaning is so much closer to the other meaning, so the
expectation of matching behavior is greater.  But maybe you dig on
that kind of thing.  I see it as a necessary evil.  Not something to
go strutting around proudly about.

Dat's all I'm gonna say about it though.  I've had my fill on this one.

--bb
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 8:48 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:


 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax. =A0Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).



 Agreed.


 I favor the syntax 'a ... b' for inclusive ranges. =A0It's easy to read
 and similar to 'a .. b' without being too similar. =A0It does require th=







 programmer to pay attention, but that's unavoidable. =A0From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.



 Sorry, but I don't share your sense of "easy to read" here. The eye can
 glaze over the third dot very easily and just not notice it.



That's often said, but if you're looking at it in a fixed-width font,
then I don't agree that it's so easy to glaze over the third dot.

--bb
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 8:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.



 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings. =A0And as much as I loathe Perl in general, I don't
 see anything wrong with that. =A0I am open to a reasonable alternate synt=




Heh, right you are.
http://www.perl.com/doc/manual/html/pod/perlop.html#Range_Operators

If Ruby won't turn it's nose up at a two dot /  three dot distinction,
then it would be hard to believe Perl would.

But leave it to Perl to give it a completely obscure meaning.

--bb
May 18 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 06:39:23 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 Georg Wrede wrote:

 bearophile wrote:

 void classify(char c) {
     write("You passed ");
     switch (c) {
        case '#':
           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }



    void classify(char c) {
      write("You passed ");
      switch (c) {
         case '#':
            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }
  This is usable, easy to read -- and the programmer has no problem to  
 remember that .. works differently in case statements than in ranges.



 I'd like to keep the (non-required) colon after the first expression in  
 a ".." pair of case labels, that is:

 case '0': .. case '9':

 as opposed to

 case '0' .. case '9':

 That way it is abundantly clear that the notation has nothing in common  
 with expression1 .. expression2. The error message if someone forgot the  
 ':' can easily be made clear.


 Andrei



Will it be possible to write like this?

void classify(char c) {
   write("You passed ");
   switch (c) {
      case '0':
      ..
      case '9':
         writeln("a digit.");
         break;
      case 'A':
      ..
      case 'Z':
         writeln("upper case ASCII character.");
         break;
      case 'a':
      ..
      case 'z':
         writeln("lower case ASCII character.");
         break;
      case '.', ',', ':', ';', '!', '?':
         writeln("a punctuation mark.");
         break;
      default:
         writeln("quite a character!");
         break;
   }
}

Looks cool!
May 19 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 16:19:32 +0400, Alexander Pánek
<alexander.panek brainsware.org> wrote:


 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work  
 on.


 Awful!<



 Well, one of your cases was wrong. Using the +1 at the end one of  
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the  
 advantage of +1 is that it introduces (almost) no new syntax, it's not  
 easy to miss, its meaning is easy to understand. AND you don't have to  
 remember that in a case the .. is inclusive while in foreach is  
 exclusive on the right, keeping the standard way in D to denote ranges.



 They will FORGET TO WRITE THE BLESSED +1. They'll write:
  case 'A' .. 'Z':



 You know, Ruby solves this by introducing a “seperate” range syntax for  
 exclusive ranges: “...”. An inclusive range is written the same as an  
 exclusive range in D: “..”.

 a[1 .. 2].length #=> 1 ([a[1]])
 a[1 ... 2].length #=> 2 ([a[1], a[2]])

 I see no reason not to include such a seperate syntax in D. “..” being  
 exclusive and “...” being inclusive, not the other way round as in Ruby  
 — see “Programmer’s Paradox”    
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex



I think this is reasonable.

++vote;
May 19 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.



Your post is emotional rather than rational.


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b



a..b vs a.b - no one complains

It also gracefully solves an issue with uniform distribution

uniform(0..int.max)  - exclusive
uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)

also in switch:

switch(a)
{
case 0..10: // exclusive
case 10...100: // inclusive
}


 I don't plan to discuss minor features on this group anymore.



It is as minor as "case a: .. case b:", i.e. not minor at all.
I'd say that there is no such thing as minor feature, every feature is
important.


 Andrei
May 20 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.



 punctuation in a programming language depends on the context the
 punctuation is found in?






 One.



 No.



 But you never asked for the name of my favourite language?



Does it have string or character literals?  Then there's probably at
least two meanings.  ;-P

--bb
May 18 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 19, 2009 at 10:51 AM, div0 <div0 users.sourceforge.net> wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 bearophile wrote:

 Alexander P=E1nek:

 Same here.



 I too don't like .56, I add a zero when I see a literal like that in the=







 Bye,
 bearophile



 I always use it, but I won't be bothered if it was outlawed.



I use it too.  Looks fine to me.  I also use  the 3.f  form on
occasion to get an integral float.

--bb
May 19 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.



Maybe if you weren't prone to such humorous bouts of hyperbole, you
wouldn't get your blood boiling so easily.  This is the internet, and
we're talking about programming languages.  It's not like we're
defusing a tense international arms conflict or something.
May 19 2009