[Larceny-users] current-{in, out}put-port assignable but not current-error-port

[Derick Eddington]

On Fri, Mar 20, 2009 at 7:40 AM, William D Clinger <will at ccs.neu.edu> wrote:
> Derick Eddington wrote:
>> Is current-error-port intentionally not assignable?
>
> Yes.  As src/Lib/Common/stdio.sch puts it:
>
> ; Rebinding the current-error-port can cause an infinite loop
> ; when errors occur, so current-error-port isn't a parameter.

I wonder if we should still be given the ability to do it somehow,
like via a current-error-port/risk.  Or maybe have two default
exception handlers and the outermost's error port is unchangeable and
its sole purpose is to handle exceptions caused by the inner handler
which is the usual default handler which uses the changeable
current-error-port (?).

>> I have code which
>> parameterizes all three current-*-port

The reason I want to parameterize current-error-port as well is
because I have a REPL library which provides REPLs over given ports,
and during the eval of read expressions I want any output to
current-error-port to go to the given error port.  It's just a toy and
I don't use it for anything currently.  But being able to redirect all
the standard ports seems like something that should be doable.

>> (and imports them via a
>> compatibility library because R6RS's are technically not directly
>> assignable (I think) (but they should be)).
>
> Variables exported from an R6RS library area are never
> assignable, and the R6RS has no notion of parameters.
>
> By making current-input-port and current-output-port into
> parameters that accept an optional argument, Larceny
> violates absolute ("must") requirements of R6RS 5.4 and
> this very explicit requirement of R6RS 6.2:

That's what I meant by "technically not directly assignable", as
opposed to indirectly assignable via with-input-from-file and
with-output-to-file.

--
: Derick
----------------------------------------------------------------