Why don't people like lisp?

Jon S. Anthony j-anthony at rcn.com
Fri Oct 24 15:54:28 EDT 2003


"Rainer Deyke" <rainerd at eldwood.com> writes:

> Jon S. Anthony wrote:
> > "Rainer Deyke" <rainerd at eldwood.com> writes:
> >
> >> I'm all for more elaborate gc schemes.  In particular, I want one
> >> that gives me guaranteed immediate destructors even in the presence
> >> of reference cycles.  And I want to language specification to
> >> guarantee it.
> >
> > It's difficult to even put a requirement for "gc" in a language
> > _specification_ let alone one that _guarantees_ this sort of thing.
> >
> >
> >> Having to explicitly close files is something I'd expect in C or
> >> assembly, but it has no place in high-level languages.  And
> >> "with-open-file" is too limiting.  Let the computer do the work, not
> >> the programmer.
> >
> > What's limiting about it?
> 
> Unless I've completely misunderstood the concept, "with-open-file" requires
> me to structure my program such that the file is opened at the beginning and
> closed at the end of a block of code.

No it does not require this - it is what you use when this is the
natural expression for what you would want.

> In the absence of coroutines or threads (both of which would
> significantly complicate the structure of my code), this implies
> that the lifetime of open files is strictly hierarchical: if file
> 'a' is opened while file 'b' is open, then file 'b' must be closed
> before file 'a' is closed.

No, even within the with-open-file of b you could close a whenever or
wherever you wanted.  The with-open-file for a just guarantees certain
things when you leave the scope.

> More generally, it implies that the file is opened at the beginning
> of a natural code block

Well, the block that it itself opens.


> and is closed at the end of the same block .

Is guaranteed to be closed.  You could close it before this if that
made sense.


> (instead of, for example, on first use) ...  (instead of, for
> example, when it is no longer needed)

OK.  If your code needs to be more flexible in this, you would use
OPEN and/or CLOSE.  If you had a particular open/close paradigm in
mind you could then write an abstraction (macro) akin to
with-open-file which provides behavior like what you say here and it
would generate the calls to open and close.  I'm sure there are
scenarios where this might not be "reasonably doable".

/Jon




More information about the Python-list mailing list