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 have code which
> parameterizes all three current-*-port (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-error-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:
A procedure that detects an argument that it is not
specified to handle must raise an exception with
condition type &assertion. Also, the argument
specifications are exhaustive: if the number of
arguments provided in a procedure call does not
match any number of arguments accepted by the
procedure, an exception with condition type
&assertion must be raised.
That is just one of many similar extensions that prevent
Larceny from being R6RS-conforming, even though Larceny is
certainly one of the more R6RS-compatible implementation
now available.
Will
_______________________________________________
Larceny-users mailing list
Larceny-users@lists.ccs.neu.edu
https://lists.ccs.neu.edu/bin/listinfo/larceny-users
