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.
-- : Derick ---------------------------------------------------------------- On Thu, 2009-03-19 at 19:36 -0400, William D Clinger wrote: > Derick Eddington wrote: > > > The R6RS library 8.2.6 specification of transcoded-port > > > says the closed binary port "cannot be used by the input > > > and output operations described in this chapter." > > > > But that applies only to binary ports closed in the special way > > transcoded-port does, as the context of that quote makes clear. > > No, I think the context of that quote makes it clear that, > even though the binary port has been closed in a special > way that might lead you to think it can still be used, it > is really just like all other closed ports in being unusable > by input and output operations. > > > I don't > > see how it applies to any other closed ports. Even if it could be > > construed to apply, "cannot be used by the input and output operations" > > doesn't mean the types of ports must change. > > Scheme is not a typed language. Certain properties of an > object are immutable, but others may be mutable. Whether > something is a port, for example, is immutable, so it is > reasonable to think of that property as a type property. > > Whether a port is open, on the other hand, is a mutable > property of a port. Closing a port has major side effects. > > The question here is whether the property of being an > input, output, binary, or textual port is mutable or > immutable. The R6RS documents are certainly not as > clear about this as they should be, but I believe that, > considered in context, R6RS library 8.2.6 is saying that > the binary port that is closed by transcoded-port is like > other closed ports in that it can no longer be used for > input or output operations. > > My opinion is not authoritative, but I did indeed write > the specification of transcoded-port (during the second > of two hurried rewrites of the R6RS library section 8.2 > that I was asked to do on very short notice, even though > I wasn't on the io subcommittee). > > Furthermore David Bartley and I designed and specified > the io system of RRRS, which survives in the R5RS and in > (rnrs io simple). I see nothing in the R6RS documents > to indicate that the property of being an input or output > port has become immutable, after all these years of being > mutable in the RRRS through IEEE/ANSI and R5RS standards. > > In particular, the disjoint types listed in R6RS 11.1 are > exactly the same as the ones listed in IEEE Standard 1178 > section 3.4, Disjointness of Types. A search for the word > "type" in R6RS library chapter 8 shows that the word is > almost always used in connection with condition types, and > there is absolutely no suggestion that the property of > being an input port (etc) has become an immutable property > of a port. As the author of the last paragraph of R6RS > library 8.2, I'm pretty sure it was never intended to > suggest that any of those properties were immutable. > > > port-eof? "returns #t if the lookahead-u8 procedure (if input-port is a > > binary port) or the lookahead-char procedure (if input-port is a textual > > port) would return the end-of-file object, and #f otherwise." If a > > closed port, which is still an input port and is still either binary or > > textual, is given, I think it's clear that port-eof? returns #F (which > > Ikarus does, PLT does not, and Ypsilon does not) because lookahead-u8 or > > lookahead-char would not return the end-of-file object. > > There may some way of reading the R6RS documents that would > allow an implementation to regard a closed port as an input > port, but I doubt it. There is certainly no language that > would require a closed port to remain an input or output > port. > > In Larceny, calling port-eof? on a closed input port raises > an exception: > > > (define p (current-input-port)) > > (close-port p) > > (port-eof? (current-input-port)) > #f > > (port-eof? p) > > Error: unhandled condition: > Compound condition has these components: > #<record &assertion> > #<record &message> > message : "assertion failed" > #<record &irritants> > irritants : ((io/input-port? p)) > > As is typical of Larceny, the error message is poor, but the > reason for the exception is that (as R6RS library chapter 8 > says) you aren't allowed to perform input or output opeations > on a closed port. That semantics has been enforced in Larceny > for the past decade, and in Larceny's predecessor, MacScheme, > for another 15 years before that. To my knowledge, none of > the thousands of users of those systems ever suggested that > a closed port should remain an input or output port. > > > I still think it has too much potential to be seriously confusing. > > For what benefit? It's confusing because... > > It's confusing because you are thinking of type as an immutable > property of objects, which is okay so long as you use the word > "type" only when referring to immutable properties of objects. > > Once you begin to use the word "type" to refer to mutable > properties, however, you will become confused. The moral of > the story is that you shouldn't use the word "type" to refer > to properties of mutable objects unless the standards tell you > those properties are immutable---which is certainly not the > case here. > > Just look at how often you're using the word "type" to refer > to properties that the R6RS documents are moderately careful > not to refer to as a "type". You do that seven times in > your next two paragraphs: > > > ... users get control flow based on > > "not a certain port type" but they're convinced the offending object > > must be a certain port type because they traced where it came from and > > they haven't discovered, memorized, and remembered that Larceny changes > > the type on them. I'm glad I randomly noticed this instead of racking > > my brain for hours about how the hell could it not be a certain port > > type when a complex program breaks because of this. I would much rather > > have a program break when it tries to perform I/O on a closed port and > > give me an exception saying "port is closed". > > > > > and is less > > > confusing than having input ports for which port-eof? > > > would raise an exception or having output ports for which > > > flush-output-port would raise an exception. > > > > I don't understand this argument because by changing the types of closed > > ports to be an abstract androgynous type, the procedures with arguments > > which are required to be input or output or textual or binary ports will > > always raise an exception when given a closed port because the argument > > type is invalid. How is this less confusing? > > Once you learn not to refer to potentially mutable properties > as types, it will become much less confusing for you because > the properties will correspond exactly to what the R6RS says > about which arguments are accepted by the input and output > procedures. > > If you persist in thinking of "input port" as an immutable > type, however, then you will have to invent some myth to > reconcile your thinking with the fact that closed ports are > not accepted by input operations that, according to the R6RS > library document, are required to accept input ports as > arguments. > > Myths lead to confusion. It's better to think clearly. > > Will _______________________________________________ Larceny-users mailing list [email protected] https://lists.ccs.neu.edu/bin/listinfo/larceny-users
