TYIPEEK / SFA interaction changed??

[Kent M. Pitman <KMP at MIT-MC>]

It used to be that the following definition
 (DEFUN SFA-HANDLER (SELF OP DATA)
    (CASEQ OP ((WHICH-OPERATIONS) '(TYIPEEK))
	      ((TYIPEEK) DATA)
	      (T (ERROR "I am too dumb to do that" OP))))
 (SETQ STREAM (SFA-CREATE #'SFA-HANDLER 0. "Dumb Stream"))
would allow you to do 
 (TYIPEEK NIL STREAM)	 => -1
 (TYIPEEK NIL STREAM -1) => -1
 (TYIPEEK NIL STREAM -3) => -3
even tho
 (TYIPEEK NIL (OPEN 'NUL: 'IN) -1) => -1
 (TYIPEEK NIL (OPEN 'NUL: 'IN) -3) => -1 ; this was a bug then and still is now

Anyway, now you get the following behavior instead:
 (TYIPEEK NIL STREAM)	 => ;NIL NON-FIXNUM VALUE
 (TYIPEEK NIL STREAM -1) => ;NIL NON-FIXNUM VALUE

In an EOF case, the TYIPEEK message to an SFA must be able to return its DATA
argument. DATA used to get bound to #nnnnnn and somehow if you returned this,
it magically figured out you wanted the eof value returned to the user. Now I
would prefer that DATA be bound to the value supplied (default -1 if 
none supplied), but that's just preference. The important thing tho' is that
I have code that is broken until someone fixes the TYIPEEK message to pass
some piece of data which if returned will give the right value back from 
TYIPEEK without erring...

Naturally, while you're at it you could fix that other bug wherein only -1
can be returned from an EOF on a real file object when TYIPEEK'ing, even if
some other arg is supplied (see the -3 case above).

-kmp