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

[Bill Gunshannon]

On 4/8/22 13:01, Arne Vajhøj wrote:
> 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.

As I stated elsewhere, the change to ANSI C from K&R broke
everything.  You can not compile K&R with an ANSI C Compiler
and vice versa.  What better time to fix it all?

bill