NaNs and infix relationals

[Thomas M. Breuel]

James W. Thomas writes:
 > [claiming lots of advantages for infix notation]

 > A Boolean macro such as 
 > 
 > isrelation(x, FPUNORD | FPLESS | FPEQUAL, y)
 > 
 > instead of x !> y would provide equivalent functionality 
 > without change to the language, but would be arguably more 
 > awkward, would still require compiler changes if it were to 
 > be efficient, would weaken programmer expectations of 
 > efficiency, and would intrude on name space.  Other 
 > function/macro approaches are less conducive to efficient 
 > code.

I don't think this is a fair evaluation:

1) There is no intrusion on name space. IEEE exentsions, like any
other machine specific extension, would only be present if the
programmer explicitly includes some header file (customarily,
such a header file contains macros that map user visible names onto
the name spaces explicitly reserved for extensions to the C language,
i.e., "#define isnan(x) __isnan(x)", etc.).

2) The intent behind not using infix notation is precisely
that the handling of implementation specific floating point features
(even if the are standardized) is explicit and clearly visible.

3) You have not responded to the criticism that the infix notation
does not let the user define his own IEEE equivalents on non-IEEE
compilers.  Only with a functional/macro notation can I get IEEE
programs to work in some reasonable fashion on a non-IEEE machine
without having to modify the source files significantly.

 > The primary goals of the proposal are (1) to meet the need to 
 > modify programs and to write new programs that deal with NaNs 
 > and (2) to cause minimal perturbation to the C language and 
 > libraries.

I maintain that these goals are best served by leaving the built-in
set of operators alone. Functional notation is straightforward to
understand, and it gives you flexibility without sacrificing
efficiency.

					Thomas.