[Larceny-users] Ports' type changes unexpectedly

William D Clinger will at ccs.neu.edu
Thu Mar 19 23:48:50 EDT 2009


Derick Eddington wrote:
> Thank you for the informative response.  I now understand the rationale
> behind your argument, and I think it does make sense.  But, as you said,
> the R6RS certainly doesn't make this issue clear enough.  In fact, it's
> guilty of referring to potentially mutable properties as types: R6RS 6.2
> "Procedure entries" says "Other type restrictions are expressed through
> parameter-naming conventions that are described in specific chapters."
> which would give me the idea that parameters named "input-port" are
> referring to types.  This must be what you mean by "moderately careful"
> not to refer to them as types.

Exactly!

In the R5RS, the only "type" in section 1.3.3 that isn't
immutable is list, which is accompanied by a parenthetical
reference to section 6.3.2, which explains that "an object
can be a list one moment and not the next".

In R6RS 6.2, *all* of the listed types are immutable.  The
main defect in the sentence you quoted is that it neglects
to mention that the parameter-naming conventions are also
used to restrict arguments on the basis of mutable properties
(such as "list") as well as immutable.

But the R6RS certainly uses the word "type" more often and
more casually that I would have liked.

To give you some more historical context, the R6RS narrowly
avoided a semantics in which binary ports could mutate into
textual ports [1,2,3].  I invented the transcoded-port hack
so implementations wouldn't be required to support that
particular mutation.

Will

[1] http://lists.r6rs.org/pipermail/r6rs-discuss/2006-October/000559.html
[2] http://lists.r6rs.org/pipermail/r6rs-discuss/2006-November/000564.html
[3] http://www.r6rs.org/formal-comments/comment-88.txt



More information about the Larceny-users mailing list