Hi, and thanks for commenting on this SRFI :)

> IDEs like to connect to a repl with a non-tty.

Absolutely, and this is a very important use case for the future.

However, the IDEs should not be using the normal command line REPL which
is optimized for humans typing at text terminals. They should be using a
pipe or socket which speaks a reliable protocol designed for machine
parsing.

> I think, geiser does that, and maybe scheme-mode too (not sure about DrRacket).

Not sure about what they do. We should explore that at some point and
draft a Language Server Protocol (LSP) style SRFI :)

Common Lisp's SLIME (and, in particular, its SWANK backend) are also
worth studying. I recall SWANK is even implemented for some Schemes.

> In a perfect world, an interpreter should have something like
> "channels", and it should be possible to explicitly indicate which
> "channel" to read the code from, and which the data.

That's why `current-input-port` is a parameter object :) You can rebind
it (either lexically or globally) to `(read)` from a different port.

> Relying on a istty() is not a good option, because (read) may even
> need to launch a separate GUI frame (window) for input, if the
> current-input-port is configured to do so on being read.

We would only be relying on isatty() to check whether we should buffer
all the source code from stdin before doing a `read` of that code. This
would not interfere with any calls to `read` made by user code.