On Tue, 07 Jul 2009 21:20:42 +0200, "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)...
> 
> 		Jerome

If Andrei is not joking (the smiley notwithstanding) the "+1" doesn't mean add one to the previous expression, instead it means that the previous expression's value is the last value in the range set.

Subtle, no?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Andrei Alexandrescu wrote:
> Nick Sabalausky wrote:
>> 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.

We also should be careful not to turn D into a "bondage and discipline" language that nobody will use unless contractually forced to.

Robert Jacques wrote:
> The new rules are definitely an improvement over C, but they make byte/ubyte/short/ushort second class citizens, because practically every assignment requires a cast:
> byte a,b,c;
> c = cast(byte) a + b;

They've always been second class citizens, as their types keep getting promoted to int. They've been second class on the x86 CPUs, too, as short operations tend to be markedly slower than the corresponding int operations.

> And if it weren't for compatibility issues, it would almost be worth it to remove them completely.

Shorts and bytes are very useful in arrays and data structures, but aren't worth much as local variables. If I see a:

    short s;

as a local, it always raises an eyebrow with me that there's a lurking bug.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:h3093m$2mu6$1@digitalmars.com...
> Before adding a feature X let's discuss them, ... If not enough people like a solution then let's not add it.

Something like that was attempted once before. Andrei didn't like what we had to say, got huffy, and withdrew from the discussion. Stay tuned for the exciting sequel where the feature goes ahead as planned anyway, and our protagonists get annoyed that people still have objections to it.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:h30907$2lk0$3@digitalmars.com...
> 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.
>

C#'s scheme supports the opposite as well. Not checking for the stuff where you mostly don't care, and then "checked" to enable the checks in the spots where you do care. And then there's been the suggestions for finer-graned control for whevever that's needed.

On Tue, 07 Jul 2009 18:10:24 -0400, Robert Jacques wrote:

> On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell <derek@psych.ward> wrote:
> 
>> On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:
>>
>>
>>> Well, how often does everyone else use bytes?
>>
>> Cryptography, in my case.
>>
> 
> Cool. If you don't mind, what's you're take new rules? (As different use cases and points of view are very valuable)

By new rules you mean the ones implemented in D 2.031?

I'm not sure yet. I need to use them more in practice to see how they sort themselves out. It seems that what they are trying to do is predict runtime behaviour at compile time and make the appropriate (as defined by Walter) steps to avoid runtime errors.

Anyhow, and be warned that I'm just thinking out loud here, we could have a scheme where the coder explicitly tells the compiler that, in certain specific sections of code, the coder would like to have runtime checking of overflow situations added by the compiler. Something like ...

   byte a,b,c;

   try {
     a = b + c;
   }
   catch (OverflowException e) { ... }

and in this situation the compiler would not give a message, because I've instructed the compiler to generate runtime checking.

The problem we would now have though is balancing the issuing-of-messages with the ease-of-coding. It seems that the most common kind of assignment is where the LHS type is the same as the RHS type(s), so we don't want to make that any harder to code. But clearly, this is also the most common source of potential overflows. Ok, let's assume that we don't want the D compiler to be our nanny; that we are adults and understand stuff. This now leads me to think that unless the coder says differently, the compiler should be silent about potential overflows.

The "try .. catch" example above is verbose, however it does scream "run-time checking" to me so it is probably worth the effort. The only remaining issue for me is how to catch accidental overflows in the special cases where I, as a responsible coder, knowingly wish to avoid.

Here is where I propose having a signal to the compiler about which specific variables I'm worried about, and if I code an assignment to one of these that can potentially overflow, then the compiler must issue a message.

NOTE BENE: For the purposes of these examples, I use the word "guard" as the signal for the compiler to guard against overflows. I don't care so much about which specific signalling method could be adopted. This is still conceptual stuff, okay?

   guard byte a; // I want this byte guarded.
   byte b,c;     // I don't care about these bytes.

   a = 3 + 29; // No message 'cos 32 fits into a byte.
   a = b + c;  // Message 'cos it could overflow.
   a = cast(byte)(b + c);  // No message 'cos cast overrides messages.
   a++; // Message - overflow is possible.
   a += 1; // Message - overflow is possible.
   a = a + 1 // Message - overflow is possible.
   a = cast(byte)a + 1;  // No message 'cos cast overrides messages.

And for a really smart compiler ...

   a = 0;
   a++; // No message as it can determine that the run time value
        // at this point in time is okay.

   for (a = 'a'; a <= 'z'; a++) // Still no message.

Additionally, I'm pretty certain that I think ...

  auto x = y + z;

should ensure that 'x' is a type that will always be able to hold any value
from (y.min + z.min) to (y.max + z.max) inclusive.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:h30907$2lk0$3@digitalmars.com...
>> 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.
>>
> 
> C#'s scheme supports the opposite as well. Not checking for the stuff where you mostly don't care, and then "checked" to enable the checks in the spots where you do care. And then there's been the suggestions for finer-graned control for whevever that's needed. 

Well unfortunately that all wasn't considered. If properly championed, it would. I personally consider the current approach superior because it's safe and unobtrusive.

Andrei

Nick Sabalausky wrote:
> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:h3093m$2mu6$1@digitalmars.com...
>> Before adding a feature X let's discuss them, ... If not enough people like a solution then let's not add it.
> 
> Something like that was attempted once before. Andrei didn't like what we had to say, got huffy, and withdrew from the discussion. Stay tuned for the exciting sequel where the feature goes ahead as planned anyway, and our protagonists get annoyed that people still have objections to it. 

Put yourself in my place. What would you do? Honest. Sometimes I find it difficult to find the right mix of being honest, being technically accurate, being polite, and not wasting too much time explaining myself.

Andrei

On Tue, 07 Jul 2009 19:39:55 -0500, Andrei Alexandrescu wrote:

> Nick Sabalausky wrote:
>> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:h3093m$2mu6$1@digitalmars.com...
>>> Before adding a feature X let's discuss them, ... If not enough people like a solution then let's not add it.
>> 
>> Something like that was attempted once before. Andrei didn't like what we had to say, got huffy, and withdrew from the discussion. Stay tuned for the exciting sequel where the feature goes ahead as planned anyway, and our protagonists get annoyed that people still have objections to it.
> 
> Put yourself in my place. What would you do? Honest. Sometimes I find it difficult to find the right mix of being honest, being technically accurate, being polite, and not wasting too much time explaining myself.
> 
> Andrei

Ditto.

We know that the development of the D language is not a democratic process, and that's fine. Really, it is. However, clear rationale for decisions made would go a long way to helping reduce dissent, as would some pre-announcements to avoid surprises.

By the way, I appreciate that you guys are now closing off bugzilla issues before the release of their fix implementation. It a good heads-up and demonstrates activity in between releases. Well done.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Robert Jacques wrote:
>>> long g;
>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>
>> Works today.
> 
> Wrong. I just tested this and what happens today is:
> g = cast(long)(e+f);
> And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".


Andrei