Re: Undefined behaviour, was: for or against equality

On Tue, 11 Jan 2022 16:55:54 -0000 (UTC), Kaz Kylheku
<480-992-1380@kylheku.com> wrote:


>On 2022-01-08, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>>Undefined behaviour, as far as language standards are concerned, are
>>>omnipresent in programming - for all languages.
>>
>> Please prove this astounding assertion. My impression is that managed
>> languages define everything, at least to some extent, and leave
>> nothing undefined. If they allowed nasal demons, the appeal of
>> managed languages would evaporate instantly.
>
>The Lisp-like programming language Scheme has unspecified order of
>argument evaluation. And you can stuff side effects into argument
>expressions, like in C.


In Scheme the order of evaluation for let expressions similarly is
unspecified.


There is at least one Scheme which deliberately randomizes the order
of function argument and let evaluation. And there are parallel
Schemes which evaluate function arguments and lets in parallel.




>Its built-in imperative have undefined return values.
>
>ANSI Common Lisp leaves the effects undefined of modifying literals,
>just like C. ANSI Lisp code that perpetrates some kind of error is
>safe only if compiled in safe mode; if you compile with reduced safety,
>e.g. (declare (optimize (safety 0))), then error become undefined
>behavior, including type errors. If you declare that some quantity is
>a fixnum integer, and request safety 0 speed 3, and then it turns
>out that it's other than an integer, woe to that code.
>However, in these cases you're invoking the safety escape hatch;
>it's not like C where you are shackled by chains of undefined behavior
>which make themselves felt every time you squirm.


And Lisp's optimization settings can be changed per function or per
compilation unit as well as globally. ["declaim" vs "declare"]

Return to the comp.compilers page.
Search the comp.compilers archives again.