[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Clause 10, Expression Evaluation
Nick Maclaren wrote:
To be fair, it also applies to Algol 68, Genstat and quite a few...
I'm less familiar with Algol 68 than with Algol 60, but I wonder how
the latter's call-by-name would fit with the proposed attributes that
are based on static blocks.
The entire discussion is completely off-the-mark in 754R in my opinion;
this is not the place to mandate how current or future langauges *shall*
behave. It *is* appropriate to state high-level *goals*, so that the
designers of new languages (or the improvers of current ones) know to
pay attention to them, but ultimately each language has its own goals.
The proposed requirements are phrased in the context of languages like C.
I agree that they reach further -- but they CANNOT be made to apply in any
universal manner. There are just too many ways to organise computations,
and not all of them can easily be described as occurring in the context
of a programming language. Even with languages, there are many different
organisational principles: deep vs shallow binding, dynamic vs static,
dynamic types, types carried along with items through computations,
declarative vs functional vs goal-oriented (e.g. Prolog), etc. For some
of them, IEEE 754 is simply not applicable (e.g. when there are no
explicit floating-point types), but for many the individual operations
are identifiable as IEEE 754 operations.
The issue that bothers me is that many languages will be in a position to
honour 754R in all its *individual* operations, but would be prevented
from claiming conformance because of a mismatch in global properties.
To take just one example: required WidenTo control. The rationale for
this is that the C language flip-flopped on the issue. Other languages
may however have well-defined type-coercion rules that are perfectly
sensible and predictable, and I see no justification for accomodating
an imposed choice of different coercion rules.
There is an interesting exposure here however: suppose a language
supports a storage type (binary16 or decimal32) as a full-fledged
type on which all operations are supported: this would require an
effective WidenTo behind the scenes for conformance, right? The
way out of course is not to claim IEEE support for those types,
if the language does not wish to abide by that WidenTo rule.
Michel.
Sent: 2007-07-12 16:59:36 UTC