Why don't people like lisp?

[Matthew Danish]

On Thu, Oct 23, 2003 at 10:53:21AM -0400, Brian Kelley wrote:
> The file is closed when the reference count goes to zero, in this case 
> when it goes out of scope.  This has nothing to do with the garbage 
> collector, just the reference counter.  At least, that's the way I 
> understand, and I have been wrong before(tm).  The upshot is that it has 
> worked in my experience 100% of the time and my code is structured to 
> use (abuse?) this.  How is this more difficult?

I would see this as a dependence on an implementation artifact.  This
may not be regarded as an issue in the Python world, though.  (Are you
sure refcounting is used in all Python implementations?  It is not that
great of a memory management technique except in certain situations).
One of the arguments against using finalizers to deallocate resources is
that it is unpredictable: a stray reference can keep the resource (and
maybe lock) open indefinitely.

This is not to say that Python couldn't achieve a similar solution to
the Lisp one.  In fact, it could get quite nearly there with a
functional solution, though I understand that it is not quite the same
since variable bindings caught in closures are immutable.  And it would
probably be most awkward considering Python's lambda.

> The difference here, as I see it, is that if an exception happens then 
> the system has to wait for the garbage collector to close the file.  In 
> both examples there was no exception handling after the fact (after the 
> file is closed).  The macro, then, allows execution to continue with the 
> closed file while the python version stops execution in which case the 
> file is closed anyway.  (unless it is in a another thread of execution 
> in which the file is closed when it goes out of scope)

I'm not sure I understand this paragraph.  The macro only executes the
body code if the file is successfully opened.  The failure mode can be
specified by a keyword argument.  The usual HANDLER-CASE and
HANDLER-BIND can be used to handle conditions with or without unwinding
the stack (you could fix and continue from a disk full error, for
example).  If the stack is unwound out of the macro, by a condition
(abnormally), then there is an attempt to restore the state of the
filesystem (method probably dependent on the :if-exists parameter).  If
control exits normally, the file is closed normally.

> In either case one still needs to write handling code to support the 
> failure as this is most likely application specific.  Using macros as a 
> default handler seems very appropriate in lisp.  

Not sure what `using macros as a default handler' means.

> This is a good thing, naturally.  But the examples you have given are 
> completely do-able (in one form or another) in python as it currently 
> stands, either by creating a wrapper around a file object that can 
> properly close down on errors or what not.  In fact, this might be a 
> better abstraction in some cases.  Consider:
> 
> (with-file-that-also-outputs-to-gui ... )
> (with-file-that-also-outputs-to-console ...)
> 
> to
> 
> (with-open-file (f ...
> 
> in this case, f is supplied by some constructor that wraps the file to 
> output to the gui or standard i/o and is passed around to various 
> functions.  Which is the better solution?
> 
> I'm not saying that lisp can't do this, it obviously can, but macros 
> might not be the appropriate solution to this problem ( they certainly 
> aren't in python ;) )

The WITH-OPEN-FILE macro is not really an example of a macro that
performs something unique.  It is, I find, simply a handy syntactic
abstraction around something that is more complicated than it appears at
first.  And, in fact, I find myself creating similar macros all the time
which guide the use of lower-level functions.  However, that doesn't
mean, for example, that I would try to defeat polymorphism with macros
(WITH-OPEN-FILE happens to be a very often used special case).  I would
write the macro to take advantage of that situation.

-- 
; Matthew Danish <mdanish at andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."