(Oops, I only replied this to Alex. For the record, resending to scheme-reports.)
I'm in favor of this feature but I don't push this to be included in r7rs errata. I agree it's too big change, and it's best to leave it undefined for now (or, an error in r7rs-sense). On Sun, Feb 1, 2015 at 3:59 PM, Alex Shinn <[email protected]> wrote: > On Sat, Jan 31, 2015 at 3:17 PM, Shiro Kawai <[email protected]> > wrote: > >> On Fri, Jan 30, 2015 at 5:32 PM, Alex Shinn <[email protected]> wrote: >> >>> From the user perspective there is no separation between >>> the port and any backing store, and they otherwise have no >>> way to free the resources. You should be able to reliably >>> accumulate a very large port and free it, or alternately >>> maintain many medium ports and not worry about them >>> hogging memory after closing. >>> >> >> If you lose the reference to the port, won't the memory be GC'ed? >> >> It is generally a bad practice to rely on freeing external resources, such >> as file descriptors, by GC. But for memory, usually we rely on GC. >> > > Indeed, but for ports people expect resources are freed > immediately on closing (at least I do). Users may assume > that closed ports only take a constant amount of memory, > and not bother to free references to them. > > Are you arguing in favor of allowing this behavior? The > only other 3 implementors to comment were all opposed. > Regardless, making a change in favor of this would be > adding new implementation requirements post-facto, and > would be beyond the scope of an errata. As-is, the result > is unspecified, and if all of the WG members agree we > could explicitly say it "is an error," but anything more than > that should be left for R8RS. > > -- > Alex > >
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
