Valery wrote:
> I think that inclusive ranges more intuitive for beginner programmers because statements:
> 
>   case 1..10,
>   array [1..10],
>   foreach (int item; 1..10),
>   foreach_reverse (int item; 1..10) (now foreach_reverse range is too dificult to understand it: item begins with 10 or 9, ends 1 or 2?)
> 
> will not require an explanation of their actions. Thanks.

I can say from personal experience that this is true.

1-based indexing is also easier for beginners.

So are BASIC and LOGO.

You may notice a trend here... :P

Inclusive ranges are easier for naive programmers to grok, but are fundamentally mismatched to programming.  It's harder to split an inclusive range, and it complicates the math.  Just try writing anything which involves manipulating ranges in Lua; it's considerably harder than with exclusive ranges.

The question is which you would rather: help naive programmers work inefficiently or prevent competent programmers from working efficiently?

I say screw the beginners; learning will do them good.

Daniel Keep wrote:

> 
> Valery wrote:
>> I think that inclusive ranges more intuitive for beginner programmers because statements:
>> 
>>   case 1..10,
>>   array [1..10],
>>   foreach (int item; 1..10),
>>   foreach_reverse (int item; 1..10) (now foreach_reverse range is too
>>   dificult to understand it: item begins with 10 or 9, ends 1 or 2?)
>> 
>> will not require an explanation of their actions. Thanks.
> 
> I can say from personal experience that this is true.
> 
> 1-based indexing is also easier for beginners.
> 
> So are BASIC and LOGO.
> 
> You may notice a trend here... :P
> 
> Inclusive ranges are easier for naive programmers to grok, but are fundamentally mismatched to programming.  It's harder to split an inclusive range, and it complicates the math.  Just try writing anything which involves manipulating ranges in Lua; it's considerably harder than with exclusive ranges.
> 
> The question is which you would rather: help naive programmers work inefficiently or prevent competent programmers from working efficiently?
> 
> I say screw the beginners; learning will do them good.

Besides, when learning programming the concept of zero-based indexing and exclusive ranges is amongst the most trivial of concerns you need worry about these days.

Lutger wrote:
> Daniel Keep wrote:
> 
>> Valery wrote:
>>> I think that inclusive ranges more intuitive for beginner programmers
>>> because statements:
>>>
>>>   case 1..10,
>>>   array [1..10],
>>>   foreach (int item; 1..10),
>>>   foreach_reverse (int item; 1..10) (now foreach_reverse range is too
>>>   dificult to understand it: item begins with 10 or 9, ends 1 or 2?)
>>>
>>> will not require an explanation of their actions. Thanks.
>> I can say from personal experience that this is true.
>>
>> 1-based indexing is also easier for beginners.
>>
>> So are BASIC and LOGO.
>>
>> You may notice a trend here... :P
>>
>> Inclusive ranges are easier for naive programmers to grok, but are
>> fundamentally mismatched to programming.  It's harder to split an
>> inclusive range, and it complicates the math.  Just try writing anything
>> which involves manipulating ranges in Lua; it's considerably harder than
>> with exclusive ranges.
>>
>> The question is which you would rather: help naive programmers work
>> inefficiently or prevent competent programmers from working efficiently?
>>
>> I say screw the beginners; learning will do them good.
> 
> Besides, when learning programming the concept of zero-based indexing and exclusive ranges is amongst the most trivial of concerns you need worry about these days.
> 

On the other hand indeed foreach_reverse is tricky and I bet it does the wrong thing with floats. Actually let's see:

import std.stdio;

void main()
{
    foreach_reverse (i; 0.7 .. 100.7)
    {
        write(i, " ");
    }
}

The last number printed is -0.3. I think this has been discussed, but I can't find a bugzilla about it.


Andrei

Andrei Alexandrescu wrote:

> void main()
> {
>      foreach_reverse (i; 0.7 .. 100.7)
>      {
>          write(i, " ");
>      }
> }
> 
> The last number printed is -0.3.

A question if I may.

Why does D allow iteration over an interval of floats? A floating point number has no direct successor or predecessor. Any such interval would contain zero, one or infinite elements.

Given the -0.3, I'm assuming you increase/decrease by 1.0 each iteration. Is this useful enough to be the standard behavior?

-- 
Michiel Helvensteijn

I have not read this entire topic, but what about the following:

case 5, .., 9:

Or even:

case 5.., 9:

This actually can be very logical, IMHO, because it's saying that 9 is included very specifically.

Other possibilities that could be explored:

case for 5, 9:
case somekindofrange!(5, 9):

In any case, I am unsure how to indent the current syntax within my coding standards.  This is unacceptable to me:

case 5: .. case 9:

(which honestly has the same problem you name.)  I guess I have to use this:

case 5: ...
case 9:

But, certainly that .. will get lost.  Alas, I suppose I will pretend this feature of D does not exist, then.  I have serious concerns with loading multiple statements on one line, and otherwise it's invisible.

-[Unknown]


Walter Bright wrote:
> Tim Matthews wrote:
>> But it only explains the inclusive/exclusiveness and not any of the other points.
> 
> Let's start with agreeing on why:
> 
>     case X..Y:
> 
> is not appropriate.
> 
>> Do you not agree that the syntax looks a little ugly?
> 
> I haven't seen any thing less ugly that is workable.

On Sat, Jul 11, 2009 at 4:37 PM, Unknown W. Brackets<unknown@simplemachines.org> wrote:
> I have not read this entire topic, but what about the following:
>
> case 5, .., 9:

I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this.  This would be FANTASTIC.

On Sat, Jul 11, 2009 at 4:42 PM, Jarrett Billingsley<jarrett.billingsley@gmail.com> wrote:
> On Sat, Jul 11, 2009 at 4:37 PM, Unknown W. Brackets<unknown@simplemachines.org> wrote:
>> I have not read this entire topic, but what about the following:
>>
>> case 5, .., 9:
>
> I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this.  This would be FANTASTIC.

Oh man, and it's even extensible and would mesh perfectly with the existing syntax:

case 1, 3: // 1 or 3
case 5, .., 9: // 5, 6, 7, 8, 9
case 10, 12, .., 17, 19: 10, 12, 13, 14, 15, 16, 17, 19

Jarrett Billingsley wrote:
> On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
> Brackets<unknown@simplemachines.org> wrote:
>> I have not read this entire topic, but what about the following:
>>
>> case 5, .., 9:
> 
> I don't have a problem with the current syntax, but the mathematical
> side of my brain squealed with fanboyish glee when it saw this.  This
> would be FANTASTIC.

At some point, we need to just move on with this. As to ,.., I suggest is it not visually very distinct in many fonts (the comma and the .) and may lead to frustrating syntax errors.

While there are many "programmers' fonts" that do a good job making the characters all distinguishable, the language shouldn't rely too heavily on that. There's already enough trouble with 0 and O.

On Sat, Jul 11, 2009 at 4:59 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> On Sat, Jul 11, 2009 at 4:37 PM, Unknown W. Brackets<unknown@simplemachines.org> wrote:
>>>
>>> I have not read this entire topic, but what about the following:
>>>
>>> case 5, .., 9:
>>
>> I don't have a problem with the current syntax, but the mathematical side of my brain squealed with fanboyish glee when it saw this.  This would be FANTASTIC.
>
> At some point, we need to just move on with this. As to ,.., I suggest is it not visually very distinct in many fonts (the comma and the .) and may lead to frustrating syntax errors.
>
> While there are many "programmers' fonts" that do a good job making the characters all distinguishable, the language shouldn't rely too heavily on that. There's already enough trouble with 0 and O.

int O_O = 0_0;

On Sat, Jul 11, 2009 at 1:37 PM, Unknown W. Brackets<unknown@simplemachines.org> wrote:
> I have not read this entire topic, but what about the following:
>
> case 5, .., 9:

Agreed.  That would be a nicer syntax.

--bb