Haskell 98: Behaviour of hClose

[Glynn Clements]

Simon Peyton-Jones wrote:

> | Re: your request to have a final look through the report
> | for any wibbles that might remain -- Section 11.3.2 of the
> | lib report isn't clear on what the expected behaviour of
> | (hClose h >> hClose h) ought to be, i.e., will the second
> | hClose fail or not?
> | 
> | Both GHC and Hugs will now not raise an error when
> | an already closed file is closed again.
> 
> 
> I'm inclined to agree.  Making hClose on a closed handle into a no-op is
> sometimes convenient for the programmer, and not hard for the
> implementation to support.  So I propose to specify that in H98.
> 
> 
> Meanwhile I only had one reply to this proposed clarification to input
> on "stdin":
> 
> 	If the standard input (stdin) is a terminal device, 
> 	any input on stdin is normally echoed on that device
> 
> The "normally" clause is a weasel way to say that if you fiddle with the
> device then odd things may happen.  The point is that programs like
> 	do { s <- getLine ; putLine (reverse s) }
> should work portably.  If we leave this sentence out, then such programs
> are not portable. But they are some of the first programs people write,
> so it's important.
> 
> In short, I propose to adopt this change unless there's a lot of yelling
> soon.

No yelling, but some random points for consideration:

1. It might be worth being more explicit, i.e. stating whether this is
because the runtime explicitly enables echoing, or because it's
assumed that echoing will already be enabled.

At present, it appears to be the latter. This is good, as it leaves
the decision up to the user. E.g. my preferred terminal (XEmacs'
shell-mode) does local echo, so echoing is disabled in the terminal
driver. Having the runtime/libraries enable it would not be good.

2. Is there actually anything special about the treatment of stdin, or
does this apply to any input stream which is associated with a
terminal?

3. In general, "magic" behaviour (e.g. clearing the ICANON flag when
disabling buffering) should at least be documented, otherwise it's
likely to confuse experienced programmers. Particularly when functions
appear to mirror common C functions. Some of Haskell's IO module,
along with the Prelude IO functions, does look suspiciously like
<stdio.h>; this can lead people to assume that the semantics are
similar.

-- 
Glynn Clements <glynn.clements@virgin.net>