[Info-vax] Rust as a HS language, was: Re: Quiet?

[Arne Vajhøj]

On 4/7/2022 9:01 AM, Bill Gunshannon wrote:
> On 4/6/22 12:35, Arne Vajhøj wrote:
>> On 4/6/2022 12:08 PM, Bill Gunshannon wrote:
>>> Let me re-word that.  40 years ago the problems were well known
>>> and documented.  A company created a C compiler and support package
>>> to fix it.  The industry rejected it because the cost (and I don't
>>> mean the purchase price!) was too high.
>>>
>>> It is interesting that very little of this made it into the C
>>> Standard which is when they could have fixed all of it.  And
>>> they can't use the backwards compatibility argument because
>>> there was no compatibility maintained between K&R and ANSI C.
>>
>> How much is known about why that product failed?
> 
> Today, little more than memories.  I don't imagine Don French is
> still around to ask but when the subject was discussed more than
> 20 years ago the general understanding was that the overhead was
> much more than users were willing to put up with.  Another example
> of something ahead of its time. (Like the UCSD P-machine and the
> STVOS.)
> 
>> I could have been the overhead. But I doubt it. Many languages
>> from that era did either check or had the option of enabling checks.
> 
> And many did not.  COBOL never did precisely because of the overhead.
> (Not sure if it does it today.)  Fortran may have been weak in this
> respect as I can remember working on a lot of programs where the
> solution seemed to hint at bounds problems.  Pascal seemed to always
> have the option to turn all of it off.  I think the intent was to
> develop with it on and then turn it off for the performance value
> when ready for production. (Again remembering that production was
> never Wirth's purpose for the language!)

VMS Fortran, Pascal, Cobol and Basic all support /CHECK=[NO]BOUNDS.

It is default on in Pascal and Basic. Default off in Fortran and Cobol.

>> And today it would almost certainly not have been an issue. Most
>> languages check.
> 
> And yet, C still doesn't even after ANSI got control of it.

It would probably be more difficult to implement in C/C++
due to their let us call it flexible approach to pointers.

It would break a lot of bad code that did not need to
exceed bounds but actually did.

It would require an unsafe { } construct to allow
to exceed bounds where actually needed.

Too complicated and breaking too much existing
code. I am not surprised that it did not happen.

New languages have the benefit of starting without
luggage of backwards compatibility requirements.

Arne