Subject: Re: self-hosting gc From: Erik Naggum <email@example.com> Date: Fri, 01 Mar 2002 17:37:03 GMT Newsgroups: comp.lang.lisp,comp.lang.scheme Message-ID: <firstname.lastname@example.org> * Matthias Blume | The point is that both file descriptors and buffers are *unforgeable* | abstract types. So whenever a user program invokes mlos_read, it can | only do so if it has obtained a valid file descriptor and a valid buffer | beforehand. Thus, mlos_read does not need to do *any* checking of its | arguments at runtime because there is a compile-time proof that | everything will be ok. And the important contribution of the programming | language is that it lets you define such abstractions (they do not have | to be built-in). What happens when you close a file? Suppose I get an opened-for-reading file descriptor back from open, store it somewhere, and its type is known to be such that I can mlos_read from it. Do we have a different way to keep track of this open file than storing (a reference to) the file descriptor in a variable? If not, how does close communicate the type back to the compiler so that there is only compile-time type checking that prevents you from calling mlos_read on a closed file descriptor? It is probably something very trivial in SML, but I keep getting confused by such things as the run-time behavior of streams, and wonder how a file descriptor that has hit end of file is prevented at compile-time from being used to read more data, and other such simple things. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.