Subject: [clisp-list] CHARSET questions & early vs late error signaling

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Aug 12 07:48:01 2002

Hi,

>there are situations when closing a terminal stream is appropriate,
>e.g., when your script is a filter.
Remember I talked about (CLOSE #<the terminal io object -- strmtype_terminal>).
Closing files, fifos or sockets has different behaviour.

If I remember correctly (IIRC), only the Lisp object is (marked as) closed,
not C's underlying handle, therefore not the OS' idea of standard-in or
standard-out. Therefore other programs wouldn't see the close.

IIRC, when CLISP starts with input or output redirected to files or pipes,
*terminal-io* is not bound to a #<terminal-io> object, but to a file or pipe
stream object. Closing that invokes the C library close routine, resulting
in the behaviour you describe.

>we can add a variable, say, CUSTOM:*FORBID-CLOSING-TERMINAL-STREAMS*,
>and set it initially to NIL for backward compatibility.
>Do people really want that?
I just showed varying solutions to (IMHO) somewhat similar areas, in CLISP (other examples in other applications are certainly abundant). I didn't request
a change. The last thing I want is yet another of those variables. :-)

I'll have to some day write up a diatribe on the (wrongly) supposed freedom that
those variables give. For a start, just image integrating seven independent 
libraries or components which require incompatible settings of such variables.
Who's going to investigate the run-time access of these libraries to the variables?

As a related topic, who would swear that one's own application won't break
if I put unusual (but legal) values into *print-length*, *read-base*,
*print-base*, *print-radix*, *package* etc.?

Enjoy,
	Jorg Hohle.