Issue: FLOAT-UNDERFLOW (version 2)

[Jon L White <jonl@lucid.com>]

re: [Lucid's WITH-FLOATING-POINT-TRAPS]
    The inability to converge on a design for such an elaborate feature is
    precisely the reason for proposing the very simple feature.  

The design may not be as elaborate or complex as you think.  When you see 
the synopsis of it below, I think you'll have to agree that a simple setting
of an implementation-dependent parameter yields the functionality of 
WITHOUT-FLOATING-UNDERFLOW-TRAPS with only two differences:
   (1) the syntax is superficially different
   (2) the equivalent of WITH-FLOATING-UNDERFLOW-TRAPS comes
       along with it.
So an implementation wanting to obey the WITH-FLOATING-POINT-TRAPS interface,
but having already implemented WITHOUT-FLOATING-UNDERFLOW-TRAPS, could in 
fact support the former by a simple use of the latter.


re: Also note that underflow is the _only_ exception that some applications 
    have a very strong need to enable while at the same time other applications
    have a very strong need to disable.  Thus just the simple feature gets
    us most of the way towards perfection. 

So why are these "some" applications so much more worthy than the others
that "have a very strong need" to selectively enable and disable the
overflow trap?  [Using ieee floating-point, it is very useful at times to
admit positive and negative infinity representations, which is what the
untrapped overflow gives you].


What makes me a bit leary of this proposal, at this stage of the game,
is that I thought we had agreed to close down Cleanup for new proposals,
in order to concentrate our efforts of finishing the large amount of
work already started but not completed.  For things previously discussed,
and which are clearly non-controversial, I see no problem.  Now, the issue 
of floating-point extremals was discussed briefly after I brought up the 
issue of denormalization (over a year ago?), and got replies from Cassels 
at Symbolics.com, Steele at Think.com and Hilfinger at Berkeley.edu 
[that discussion might have been on Common-Lisp@SAIL rather than on 
CL-Cleanup@SAIL]; at least it seemed there was consensus on that matter.  
But the larger picture of treatment of floating-point traps just didn't 
get discussed.


Anyway, before formalizing a CLeanup proposal [which I fear would be
moot at this late a date], let me get your reactions to a description 
of the relevant features from Lucid Common Lisp:


(1)  SUPPORTED-FLOATING-POINT-CONDITIONS -- An implementation-dependent 
     defconstant which typically varies from port to port; holds the list 
     of conditions which __can be__ supported as floating-point traps. 
     These are all condition names in the (extended) error system.   For 
     example, ports using the MC68881 chip typically have:
  
		floating-point-inexact 
		floating-point-overflow 
		floating-point-underflow 
		floating-point-OutOfDomain
		floating-point-NaN
		floating-point-UnorderedComparison
		division-by-zero

     Other ports might have only division-by-zero, floating-point-underflow,
     and floating-point-overflow.  Frequently these are continuable 
     conditions, but that varies with the degree of difficulty in restarting
     a floating-point co-processor.


(2) ENABLED-FLOATING-POINT-TRAPS  -- A function of no arguments which
    Returns a list of all the floating-point condition names currently
    enabled for error trapping.  These names will be a subset of those
    on SUPPORTED-FLOATING-POINT-CONDITIONS.  A SETF method is provided
    for this function as the means of explicitly setting the traps.  [Of 
    course, certain software functions need to inspect the established
    state too -- it isn't merely a blind poking of the control register
    of a floating point chip.]

(3) WITH-FLOATING-POINT-TRAPS  -- a macro for temporary setting of floating
    point trapping conditions [typically, the temporary setting of traps
    can be done in an implementation-dependent way that is much more
    efficient than just saving and restoring (ENABLED-FLOATING-POINT-TRAPS)]

   (defmacro with-floating-point-traps ((enable-list disable-list) &body body)
      ....)

    where the 'enable-list' and 'disable-list' are evaluated.  The traps
    enabled during the execution of the body are:

       (UNION <enable-list> 
              (SET-DIFFERENCE (ENABLED-FLOATING-POINT-TRAPS) <disable-list>))

    Sample uses might be:

        (with-floating-point-traps 
	      ('(floating-point-underflow)
               supported-floating-point-conditions)
         ... 
         ...	;all floating-point traps turned off except underflow
         ...)

        (with-floating-point-traps 
	      ('()
               '(floating-point-underflow))
         ... 
         ...	;underflow turned off; all others left alone.
         ...)


I would expect controversy about the syntax of WITH-FLOATING-POINT-TRAPS;
and I would expect that someone would want to waste our time arguing how
much detail we would need in the specification of the defconstant 
SUPPORTED-FLOATING-POINT-CONDITIONS.



-- JonL --