Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:
>>> I think Walter's message really rendered the whole discussion moot. Post of
>>> the year:
>>>
>>> =========================
>>> I like:
>>>
>>>   a .. b+1
>>>
>>> to mean inclusive range.
>>> =========================
>>
>> Not everything is an integer.
> 
> Works with pointers too.

It works for the cases where an inclusive range makes sense.

Andrei Alexandrescu wrote:
> Jérôme M. Berger wrote:
>> Andrei Alexandrescu wrote:
>>> Jérôme M. Berger wrote:
>>>> Andrei Alexandrescu wrote:
>>>>> Jérôme M. Berger wrote:
>>>>>> Andrei Alexandrescu wrote:
>>>>>>> Derek Parnell wrote:
>>>>>>>> It seems that D would benefit from having a standard syntax
>>>>>>>> format for
>>>>>>>> expressing various range sets;
>>>>>>>>  a. Include begin Include end, i.e. []
>>>>>>>>  b. Include begin Exclude end, i.e. [)
>>>>>>>>  c. Exclude begin Include end, i.e. (]
>>>>>>>>  d. Exclude begin Exclude end, i.e. ()
>>>>>>>
>>>>>>> I'm afraid this would majorly mess with pairing of parens.
>>>>>>>
>>>>>>     I think Derek's point was to have *some* syntax to mean this,
>>>>>> not necessarily the one he showed (which he showed because I
>>>>>> believe that's the "standard" mathematical way to express it for
>>>>>> English speakers). For example, we could say that [] is always
>>>>>> inclusive and have another character which makes it exclusive like:
>>>>>>  a. Include begin Include end, i.e. [  a .. b  ]
>>>>>>  b. Include begin Exclude end, i.e. [  a .. b ^]
>>>>>>  c. Exclude begin Include end, i.e. [^ a .. b  ]
>>>>>>  d. Exclude begin Exclude end, i.e. [^ a .. b ^]
>>>>>
>>>>> I think Walter's message really rendered the whole discussion moot. Post of the year:
>>>>>
>>>>> =========================
>>>>> I like:
>>>>>
>>>>>    a .. b+1
>>>>>
>>>>> to mean inclusive range.
>>>>> =========================
>>>>>
>>>>> Consider "+1]" a special symbol that means the range is to be closed to the right :o).
>>>>>
>>>>     Ah, but:
>>>>  - This is inconsistent between the left and right limit;
>>>>  - This only works for integers, not for floating point numbers.
>>>
>>> How does it not work for floating point numbers?
>>>
>>     Is that a trick question? Depending on the actual value of b, you
>> might have b+1 == b (if b is large enough). Conversely, range a .. b+1
>> may contain a lot of extra numbers I may not want to include (like
>> b+0.5)...
> 
> It wasn't a trick question, or it was of sorts. If you iterate with e.g. foreach through a floating-point range that has b == b + 1, you're bound to get in a lot of trouble because the running variable will be incremented.
> 
	Well:
  - A floating point range should allow you to specify the iteration
step, or else it should allow you to iterate through all numbers
that can be represented with the corresponding precision;
  - The second issue remains: what if I want to include b but not
b+ε for any ε>0?

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:h2vprn$1t77$1@digitalmars.com...
>
> This is a different beast. We simply couldn't devise a satisfactory scheme within the constraints we have. No simple solution we could think of has worked, nor have a number of sophisticated solutions. Ideas would be welcome, though I need to warn you that the devil is in the details so the ideas must be fully baked; too many good sounding high-level ideas fail when analyzed in detail.
>

I assume then that you've looked at something lke C#'s checked/unchecked scheme and someone's (I forget who) idea of expanding that to something like unchecked(overflow, sign)? What was wrong with those sorts of things?

Jérôme M. Berger wrote:
>  - A floating point range should allow you to specify the iteration step, or else it should allow you to iterate through all numbers that can be represented with the corresponding precision;

We don't have that, so you'd need to use a straigh for statement.

>  - The second issue remains: what if I want to include b but not b+ε for any ε>0?

real a, b;
...
for (real f = a; f <= b; update(f))
{
}

I'd find it questionable to use ranged for with floats anyway.


Andrei

Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:h2vprn$1t77$1@digitalmars.com...
>> This is a different beast. We simply couldn't devise a satisfactory scheme within the constraints we have. No simple solution we could think of has worked, nor have a number of sophisticated solutions. Ideas would be welcome, though I need to warn you that the devil is in the details so the ideas must be fully baked; too many good sounding high-level ideas fail when analyzed in detail.
>>
> 
> I assume then that you've looked at something lke C#'s checked/unchecked scheme and someone's (I forget who) idea of expanding that to something like unchecked(overflow, sign)? What was wrong with those sorts of things? 

An unchecked-based approach was not on the table. Our focus was more on checking things properly, instead of over-checking and then relying on "unchecked" to disable that.

Andrei

Andrei Alexandrescu:
> How often did you encounter that issue?

Please, let's be serious, and let's stop adding special cases to D, or they will kill the language.
Lately I have seen too many special cases.
For example the current design of the rules of integral seems bad. It has bugs and special cases from the start.
The .. used in case is another special case, even if Andrei is blind regarding that, and doesn't see its problem.
Why for a change people here stop implementing things, and start implementing a feature only after 55-60+% of the people think it's a good idea?
Languages like C# and Scala show several features good to be copied, let's copy them, and let's not add any more half-backed things. Before adding a feature X let's discuss them, let's create a forum or place to keep a thred for each feature plus a wiki-based text of the best solution found, etc. If not enough people like a solution then let's not add it. Better not having a feature than having a bad one, see Python that even today misses basic things like a switch/case.

Bye,
bearophile

Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
> Leandro Lucarella wrote:
> >This seems nice. I think it would be nice if this kind of things are commented in the NG before a compiler release, to allow community input and discussion.
> 
> Yup, that's what happened to case :o).
> 
> >I think this kind of things are the ones that deserves some kind of RFC (like Python PEPs) like someone suggested a couple of days ago.
> 
> I think that's a good idea. Who has the time and resources to set that up?

What's wrong with the Wiki?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
He andáu muchos caminos, muchos caminos he andáu, Chile tiene el buen vino y Suecia, el bacalao. Esta'o Unido tiene el hot do', Cuba tiene el mojito, Guatemala, el cornalito y Brasil la feishoada.

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
>> Leandro Lucarella wrote:
>>> This seems nice. I think it would be nice if this kind of things are
>>> commented in the NG before a compiler release, to allow community input
>>> and discussion.
>> Yup, that's what happened to case :o).
>>
>>> I think this kind of things are the ones that deserves some kind of RFC
>>> (like Python PEPs) like someone suggested a couple of days ago.
>> I think that's a good idea. Who has the time and resources to set that up?
> 
> What's wrong with the Wiki?

Where's the link?

Andrei

bearophile wrote:
> Andrei Alexandrescu:
>> How often did you encounter that issue?
> 
> Please, let's be serious, and let's stop adding special cases to D,
> or they will kill the language.

Don't get me going about what could kill the language.

> Lately I have seen too many special
> cases. For example the current design of the rules of integral seems
> bad. It has bugs and special cases from the start.

Bugs don't imply that the feature is bad. The special cases are well
understood and are present in all of C, C++, C#, and Java.

Value range propagation as defined in D is principled and puts D on the right side of both safety and speed. It's better than all other languages mentioned above: safer than C and C++, and requiring much fewer casts than C# and Java.


Andrei

Andrei Alexandrescu wrote:
> Jérôme M. Berger wrote:
>>  - A floating point range should allow you to specify the iteration
>> step, or else it should allow you to iterate through all numbers that
>> can be represented with the corresponding precision;
> 
> We don't have that, so you'd need to use a straigh for statement.
> 

struct FloatRange {
    float begin, end, step;
    bool includeBegin, includeEnd;

    int opApply (int delegate (ref float) dg) {
       whatever;
    }

    whatever;
}

>>  - The second issue remains: what if I want to include b but not b+ε
>> for any ε>0?
> 
> real a, b;
> ...
> for (real f = a; f <= b; update(f))
> {
> }
> 
> I'd find it questionable to use ranged for with floats anyway.
> 
	So would I. But a range of floats is useful for more than iterating
over it. Think interval arithmetic for example.

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr