CLISP - an ANSI Common Lisp

Hello,

The current behavior of EXT:STREAM-HANDLES is to return two file
descriptors (input and output) when possible, and error otherwise.

The problem I have with this behavior is that (apparently) there's no
way to predict whether it is possible to perform this operation or not
on a random stream (notably when it's just of class STREAM): IIUC,
stream_handles does the validity check based on information which is
only available at the C level.

I can currently work around this by catching STREAM-SIMPLE-ERROR but
this is not satisfactory (too coarse a grain). So my question is:

- would it hurt if EXT:STREAM-HANDLES were changed to return nil instead
  of error'ing? CCL does this with his STREAM-DEVICE function for
  instance.

- otherwise, could we have a predicate such as STREAM-HAS-HANDLES-P
  please?


Or, we could enrich the STREAM class hierarchy with a mixin for streams
with handles, or, expose the current implementation details (the
strmtype field) to the Lisp level. But maybe we don't want to go that
far :-)


Thanks!

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: [clisp-list] stream-handles behavior From: Pascal J. Bourguignon <pjb@in...> - 2012-05-21 10:09 Didier Verna <didier@...> writes: > Hello, > > The current behavior of EXT:STREAM-HANDLES is to return two file > descriptors (input and output) when possible, and error otherwise. > > The problem I have with this behavior is that (apparently) there's no > way to predict whether it is possible to perform this operation or not > on a random stream (notably when it's just of class STREAM): IIUC, > stream_handles does the validity check based on information which is > only available at the C level. > > I can currently work around this by catching STREAM-SIMPLE-ERROR but > this is not satisfactory (too coarse a grain). So my question is: > > - would it hurt if EXT:STREAM-HANDLES were changed to return nil instead > of error'ing? CCL does this with his STREAM-DEVICE function for > instance. (defun stream-device (stream) (handler-case (ext:stream-handle stream) (error () nil))) > - otherwise, could we have a predicate such as STREAM-HAS-HANDLES-P > please? (defun stream-ahs-handle-p (stream) (stream-device stream)) IMO, Lisp is not C. It's not bad to signal an error if a function cannot access the wanted attribute. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

Re: [clisp-list] stream-handles behavior From: Didier Verna <didier@lr...> - 2012-05-21 11:05 "Pascal J. Bourguignon" <pjb@...> wrote: > (defun stream-device (stream) > (handler-case (ext:stream-handle stream) (error () nil))) Could you please read the mails you're replying to ? ;-) I said: >> I can currently work around this by catching STREAM-SIMPLE-ERROR but >> this is not satisfactory (too coarse a grain). Catching just ERROR is even coarser and unsatisfactory for the same reason. You catch more than you actually want, and this is dangerous in principle. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

Re: [clisp-list] stream-handles behavior From: Pascal J. Bourguignon <pjb@in...> - 2012-05-21 13:10 Didier Verna <didier@...> writes: > "Pascal J. Bourguignon" <pjb@...> wrote: > >> (defun stream-device (stream) >> (handler-case (ext:stream-handle stream) (error () nil))) > > Could you please read the mails you're replying to ? ;-) Sorry. > I said: > >>> I can currently work around this by catching STREAM-SIMPLE-ERROR but >>> this is not satisfactory (too coarse a grain). > > Catching just ERROR is even coarser and unsatisfactory for the same > reason. You catch more than you actually want, and this is dangerous in > principle. Right, but this is another topic. Indeed, it would be nice if all the CL operators, and all the libraries defined always specific conditions, so we could write: (defun stream-device (stream) (handler-case (ext:stream-handle stream) (ext:stream-has-no-handle-error () nil))) But often it's not expected to have any other errors either, so just error is acceptable. The downside, is that the condition ontology is often as complex if not more complex than the main object ontology of a library or program. (But nothing that couldn't be handled with a few nice macros). -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.

Re: [clisp-list] stream-handles behavior From: Didier Verna <didier@lr...> - 2012-05-21 13:41 "Pascal J. Bourguignon" <pjb@...> wrote: > Indeed, it would be nice if all the CL operators, and all the > libraries defined always specific conditions > > The downside, is that the condition ontology is often as complex if > not more complex than the main object ontology of a library or > program. (But nothing that couldn't be handled with a few nice > macros). Yup. Now, let's work a couple of years on a CDR which describes all the precise errors we need in the standard :-) -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

Re: [clisp-list] stream-handles behavior From: Sam Steingold <sds@gn...> - 2012-05-21 14:37 Hi, > * Didier Verna <qvqvre@...> [2012-05-21 11:58:07 +0200]: > > The current behavior of EXT:STREAM-HANDLES is to return two file > descriptors (input and output) when possible, and error otherwise. > > The problem I have with this behavior is that (apparently) there's no > way to predict whether it is possible to perform this operation or not > on a random stream (notably when it's just of class STREAM): IIUC, > stream_handles does the validity check based on information which is > only available at the C level. > > I can currently work around this by catching STREAM-SIMPLE-ERROR but > this is not satisfactory (too coarse a grain). So my question is: why "too coarse a grain"? could you please be more specific? > - would it hurt if EXT:STREAM-HANDLES were changed to return nil instead > of error'ing? CCL does this with his STREAM-DEVICE function for > instance. > > - otherwise, could we have a predicate such as STREAM-HAS-HANDLES-P > please? 1. STREAM-HANDLES is just a thin interface to stream_handles() which is used in many places (including modules) and which I am very reluctant to change. 2. looking through clisp/src/stream.d it appears that this is the function you want: (defun stream-device (object) (and (or (sys::built-in-stream-p object) (eq 'socket:socket-server (type-of object))) (handler-case (ext:stream-handles object) (stream-error (e) nil)))) the only errors signaled by stream-handles are errors on invalid argument. (stream-device 1) ==> NIL (stream-device *terminal-io*) ==> 0 ; 1 -- Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000 http://www.childpsy.net/ http://mideasttruth.com http://thereligionofpeace.com http://iris.org.il Shady characters are often very bright.

Re: [clisp-list] stream-handles behavior From: Didier Verna <didier@lr...> - 2012-05-21 15:27 Sam Steingold <sds@...> wrote: > why "too coarse a grain"? could you please be more specific? What I mean is that in general (maybe not in this particular case though), I don't like to rely on catching errors for testing whether I have the right to do something or not. The general problem is that many times, a single error is used for different reasons (this is what I call "coarse grain", and the standard doesn't help in this matter) but you are only interested in one of them. When you catch such an error, you're actually catching a whole bunch of situations, including the one you're looking for, but not only, and there's no way to know. The consequence is that in principle, catching too many situations may in fact hide bugs. > 2. looking through clisp/src/stream.d it appears that this is the > function you want: > > (defun stream-device (object) > (and (or (sys::built-in-stream-p object) > (eq 'socket:socket-server (type-of object))) > (handler-case (ext:stream-handles object) > (stream-error (e) nil)))) > > the only errors signaled by stream-handles are errors on invalid > argument. > > (stream-device 1) > ==> NIL > (stream-device *terminal-io*) > ==> 0 ; 1 It looks perfect, thanks! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

59 messages have been excluded from this view by a project administrator.