From ... Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!isdnet!freenix!deine.net!hamster.europeonline.net!newsfeed.europeonline.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp,comp.lang.scheme Subject: Re: self-hosting gc References: <87elj5i2rf.fsf@becket.becket.net> <87elj5glx5.fsf@becket.becket.net> <87g03kd1m5.fsf@baguette.webspeed.dk> Mail-Copies-To: never From: Erik Naggum Message-ID: <3223993027817075@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Mar 2002 17:37:03 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader1.kpnqwest.net 1015004223 193.71.199.50 (Fri, 01 Mar 2002 18:37:03 MET) NNTP-Posting-Date: Fri, 01 Mar 2002 18:37:03 MET Xref: archiver1.google.com comp.lang.lisp:27658 comp.lang.scheme:9092 * 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.