Andrei Alexandrescu:

> How is this a response to what I wrote?

I have said that sometimes you want to use the safer types even in a place where you have said could use the primitive types.


> And to take that to its logical conclusion, we don't want the defaults in the D language to cater to such applications.

Integral safety (and few other kinds of safeties) are useful even in software that's not high integrity :-)

Bye,
bearophile

On 11/2/13 10:29 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>> How is this a response to what I wrote?
>
> I have said that sometimes you want to use the safer types even in a
> place where you have said could use the primitive types.

Then just use the safer types! I mentioned the possibility as, well, a possibility. But then how will you use the safer types to implement the safer types?

>> And to take that to its logical conclusion, we don't want the defaults
>> in the D language to cater to such applications.
>
> Integral safety (and few other kinds of safeties) are useful even in
> software that's not high integrity :-)

So is speed, and you're among the first to get miffed when we have a performance regression. And for a good reason. You're also one to clamor for backward compatibility, and it would be hard to imagine a more massive one. So just drop this.


Andrei

Andrei Alexandrescu:

> We need to ensure left-to-right evaluation semantics through and through.

Good. And Walter agrees with you. I am not asking for a road map with dates, but what are the steps and the work to arrive there? What needs to be done?

Bye,
bearophile

On 11/2/13 12:42 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> We need to ensure left-to-right evaluation semantics through and through.
>
> Good. And Walter agrees with you.

Actually he only agrees partially. In the expression:

a[i++] = i++;

Walter argues "evaluate right-hand side first, then left-hand side, then assign". I argue "evaluate left-to-right regardless". I suspect this extends to other cases, such as:

functions[i++](i++);

(assuming functions is an array of functions). I argue that LTR is the one way to go. Not sure he'd agree. Similarly:

objects[i++].method(i++);

(assuming objects is an array of objects). Here again I think LTR is the simplest and most intuitive rule.

> I am not asking for a road map with
> dates, but what are the steps and the work to arrive there? What needs
> to be done?

I think someone should sit down and define behavior for all such cases, then proceed and implement it in the front-end. I haven't done significant front end work so I don't know what that entails.


Andrei

Andrei Alexandrescu:

> Actually he only agrees partially.

I didn't know this.


> In the expression:
>
> a[i++] = i++;
>
> Walter argues "evaluate right-hand side first, then left-hand side, then assign". I argue "evaluate left-to-right regardless". I suspect this extends to other cases, such as:
>
> functions[i++](i++);
>
> (assuming functions is an array of functions). I argue that LTR is the one way to go. Not sure he'd agree. Similarly:
>
> objects[i++].method(i++);
>
> (assuming objects is an array of objects). Here again I think LTR is the simplest and most intuitive rule.

Where it's too much hard for us to tell what's the most intuitive behavour, it means the code is very anti-intuitive. Such code is going to make me scratch my head regardless what rule the D compiler will follow. So it's code that I refactor mercilessly to make it clear enough, splitting it in as many lines as needed. All this means that too much complex cases can be disallowed statically by the D compiler. This could break a little of code, but it's D code that today relies on undefined behavour, so turning it into a syntax error it's actually an improvement. So what I am saying is to define semantics for the normal cases, and just statically disallow the hardest cases.


> I think someone should sit down and define behavior for all such cases, then proceed and implement it in the front-end. I haven't done significant front end work so I don't know what that entails.

Timon Gehr has a sharp mind that seems fit to spot most of those cases, with some help from others, like Kenji. So that can be a first step. Perhaps a little DIP could be handy to keep such ideas.

Bye,
bearophile

On 11/2/13 1:25 PM, bearophile wrote:
> Where it's too much hard for us to tell what's the most intuitive
> behavour, it means the code is very anti-intuitive. Such code is going
> to make me scratch my head regardless what rule the D compiler will
> follow. So it's code that I refactor mercilessly to make it clear
> enough, splitting it in as many lines as needed. All this means that too
> much complex cases can be disallowed statically by the D compiler. This
> could break a little of code, but it's D code that today relies on
> undefined behavour, so turning it into a syntax error it's actually an
> improvement. So what I am saying is to define semantics for the normal
> cases, and just statically disallow the hardest cases.

I think you underestimate the fraction of the cases that would be disabled. Pretty much any use where aliasing is a possibility would not pass muster.

Andrei

On 11/2/13 1:25 PM, bearophile wrote:
> Timon Gehr has a sharp mind that seems fit to spot most of those cases,
> with some help from others, like Kenji. So that can be a first step.
> Perhaps a little DIP could be handy to keep such ideas.

They call it "open source" for a reason. Have at it!!!

Andrei

On 11/2/2013 9:49 AM, bearophile wrote:
> not as bug free as software of the Space Shuttle guiding system

Nobody pretends that the Space Shuttle flight control computers are safe. There are 4 of them, plus a 5th with completely different design & software in it. This is coupled with a voting system.

On 11/2/2013 6:59 AM, Timon Gehr wrote:
> Well, I think it is funny to consider a methodology adequate in hindsight if it
> has resulted in a crash. Have the techniques advocated by Walter been thoroughly
> applied in this project?

One downside of system redundancy is it adds weight, and spacecraft are catastrophically sensitive to weight.

When space probes fail, they don't kill people. So while the failures cost money and are embarrassing, the weight penalty of redundancy may have meant the mission wasn't practical in the first place.

Tradeoffs, tradeoffs.

I don't know much about failsafe redundancy in, for example, Mars probes. I have seen discussions about the lack of failsafes in many aspects of the Shuttle design. They are well known tradeoffs, though, and they know the risks.

Nobody has even figured out how to make failsafe helicopter rotor blades. Instead, they opt for expensive maintenance and inspections. If a rotor blade fails, the helicopter crashes and kills everyone aboard.

On Saturday, 2 November 2013 at 04:06:46 UTC, Walter Bright wrote:
> On 11/1/2013 6:52 AM, Wyatt wrote:
>> "We could, for instance, begin with cleaning up our language by no longer
>> calling a bug a bug but by calling it an error. It is much more honest because
>> it squarely puts the blame where it belongs, viz. with the programmer who made
>> the error.
>
> Although it is tempting to do so, creating a culture of "blame the programmer" for the mistakes he's made also creates a culture of denial of problems.
>
> If you want to create quality of software, a far better culture is one that recognizes that people are imperfect, and looks for collaborative ways to engineer the possibility of errors out of the system. That doesn't work if you're trying to pin the blame on somebody.

My reading was less that an error should be hauled out as an indictment of the individual who made it and more that we should collectively be more cognizant of our own fallible nature and accept that that affects the work we do.  In that vein the _who_ is less important than the explicit understanding that some human (probably me) mucked up.  Of course, I tend to read EWD with a fair bit of fabric softener- he was a grumpy old man on a mission.

Though even with the more literal interpretation, I'm not sure I agree that necessarily has to be negative.  If I'm in error, I honestly _want_ to know.  How it's conveyed is a function of the culture that can make it a positive (learning) experience or a negative one.

-Wyatt