Koen Claessen <[EMAIL PROTECTED]> writes:
>
.....
>
> This is also the case for making stdin a constant or not. I think stdin IS
> a constant, and should stay that way. If some bad programmer wrote a
> function that only worked on the stdin and stdout, than he limited the
> users of his/her function to only use it for that purpose. He/she also
> could have made two extra parameters for this function instead.
>
I don't agree, for the following reasons:
1. your OS may give you a triple of file descriptors when exec'ing your
process, but I don't see how it automatically follows that the fixed
nature of these is what you want to lift up to the programmer interface.
Just because that's what stdio gives you?
2. The majority of today's computers run on Win* platforms, for which
there's
no notion of conventional stdin, stdout when developing a non-console
app.
(goes for any GUI-only app, really). What do you want to do here, tell
the
programmer to forget about the I/O library completely *or* provide ways
for the programmer to change the interpretation of what stdin, stdout
means in the context of his/her GUI app. I know which one I'd prefer.
3. Multiple threads, the seventies idea of stdin and friends
being constant does not apply anymore, witness the Java API for
dynamically configuring the input and output stream of a process.
I don't honestly see what having these handles as constant *gain* you,
so why then have them as such, if not having them constant gives you
extra expressiveness?
> If you need awkward plumbing for this you can still hide it away by
> abstracting it into another (reader) monad. I think we should see stdin
> and stdout as static connections with the outside world, and make our own
> abstractions in Haskell if we wish to, instead of using stdin and stdout
> for that.
>
At a systems level they should be accessible, but, as I mentioned above,
I don't see the value of mimicking stdio's lack of features here.
> Regards,
> Koen.
>
--Sigbjorn
