Re: [Q] HOWTO redirect a i/o-port in Unix??

[Matthew Flatt <mflatt@cs.utah.edu>]

Quoting Leo Razoumov:
> GREAT!!!! When is 102 released??

The current plan is late spring or early summer. Of course, 102/8 (the
8th checkpoint before the 102 release) is available via CVS.

> But I still beleive it is worthwhile to have a Unix (POSIX) extension
> library which provides most handy pieces of Unix API.

Agreed. The Right Thing is probably a port of Scsh, and many lesser
solutions would be valuable. I never ported Scsh myself because I never
wanted to program Unix; I wanted something better...

\begin{rants}

> I am trying to promote Scheme (in particular MzScheme) here as a
> universal scripting/extension language and to drop Perl (Tk/Tcl) all
> together. My colleagues are keeping asking me "nasty" practical
> questions like: how do I do this-and-that in Scheme what I can do in
> Perl in the middle of a night with my eyes closed? What should I
> answer?

So why *do* you use Scheme when Perl does everything already?

To me, it's an aesthetic and engineering argument. I use Scheme because
I belive the code will be more reliable, maintainable, and reusable.
Those benefits have a lot to do with the careful design of the
language.

The same aesthetic and engineering sense leads me to design decisions
in MzScheme that don't match the Unix way of doing things. Unix's
stream model is great in abstract, but the details are complex. It's
taken me *years* to really understand how things are supposed to work,
and I still find it difficult to write (and understand!) truly general
Unix I/O code. The key problem, I think, is that basic stream model has
been augmented in many ad hoc ways (for non-blocking I/O, movable
stream positions, etc.).

We're looking for a more compact, consistent set of concepts, for all
the obvious (to a Schemer) reasons. For example, you don't need
select() and non-blocking I/O if your language has threads and a
sensible block-interruption mechanism.

MzScheme does need at least one more primitive: something like
`read-string', but that returns immediately after reading as many bytes
as are ready, blocking only if none are ready. Maybe other primitives
are needed. Or maybe there's an even better set of primitives MzScheme
could provide - we'll keep looking.

> Also there is another problem with "copy-stream" implementation of
> redirect-port: with a read/write approach it is all but impossible to
> synchronize FROM and TO stream positions. What happens if my
> subprocess "myprog" uses 'lseek' and repositions its output file
> position.

Using lseek on stdout? That sounds pretty strange. Actually, it seems
like a good example of where the Unix I/O model breaks down: many
strange things are possible since *some* streams have movable positions
tacked onto them.

\end{rants}

To repeat the non-rant part of my message: I agree that it would be
great to have an extension that lets you do everything that is possible
in Unix. I'm very much in favor of a Scsh port, or other efforts in
that direction. I think that's what you're talking about, and we're
with you!

Matthew