[Wiping egg off face.]
This was a knee jerk response made without fully thinking things out.
For that I apologize.
See comments below.
On Fri, 2004-01-30 at 05:46, Christophe Rhodes wrote:
> Craig Lanning <CraigL@...> writes:
> > On Sun, 2004-01-25 at 13:57, Christophe Rhodes wrote:
> >> Hi all,
> >> In a world with no pathname versions worth speaking of, what should
> >> :if-exists :new-version do?
> > I think that :error is a very bad choice because it makes it harder to
> > write portable programs. I always try to make my lisp code portable
> > across Unix Lisps, Windows Lisps, and Symbolics Lisp Machines. (Yes,
> > there are still some around. I have one at home and used one at work
> > until just a couple of years ago.) While Unix and Windows don't support
> > file version, the Lisp Machines do.
> Right. But when you write :if-exists :new-version, what is more
> important to you? That you do not get an error if the file already
> exists, or that you do not silently lose information that you already
Now that I read your response and reread your original message I realize
that when I read it the first time I was thinking that the default value
for :if-exists is :new-version and that you were wanting to make it
signal an error if the file already existed.
What really matters to me is the default value of :if-exists. On the
Lisp Machine :if-exists defaults to :new-version, obviously. What I'd
like to see is a default value on Unix that is compatible. This would
probably be either :supersede or :new-version, with :new-version
generating either the ~42~ syntax or making a simple backup file of some
kind. (BTW, a Symbolics creating versioned files on a Unix host makes a
pathname like "filename.ext.~42~".)
> > One of my favorite things about lisp is that I can write a program and
> > compile it on Unix, Windows, and a Lisp Machine and have very few #+'s.
> > C has #ifdef's just between different Unix systems and it gets worse if
> > you add Windows to the mix.
> In the particular area of filesystem handling, I think that this
> "easy" portability is in fact a chimera, and providing a route towards
> the chimera in fact does a disservice to those users who want portable
> code. In other words, I think it's already hard to write even /de
> facto/ portable programs, but this difficulty is disguised by an easy
> 90% solution.
> For instance, I might be inclined to write what you presumably mean by
> :new-version by using a construction such as (with apologies for the
> probable syntax errors):
> (let ((stream
> (handler-bind ((file-error (lambda (c)
> (invoke-restart 'supersede c))))
> (open file :direction :output :if-exists :new-version))
> (supersede () (open file :direction :output :if-exists :supersede)))))
> (when (open-stream-p stream)
> (close stream)))
> The point being that I enviseage that my typical use of :new-version
> would rather signal an error if the file already exists. In other
> words, I think we differ on what a Lisp should do if it finds itself
> unable to fulfil a request from the programmer.
> It's arguable that on this basis, :rename is the best translation of
> :new-version... it just feels a little suspiciously DWIMish and
> fragile, which is why I'm slightly reluctant about it.
I think the most important thing is to setup reasonable defaults to
begin with. This should take care of most of the problems.
> >> Consider the logical pathname translations for "FOO" being of the form
> >> (("*.*.1" "/tmp/my/files/1/*.*")
> >> ("*.*.2" "/tmp/my/files/2/*.*"))
> >> and a request for (open "FOO:BAR.TXT.1" :if-exists :new-version) being
> >> made. What happens if /tmp/my/files/1/bar.txt exists? Should we
> >> attempt to open /tmp/my/files/2/bar.txt?
> > In 19 years of lisp programming, I have never seen a mapping like this.
> Isn't life fun? The above represents a way of faking Lispm-like
> versions on a filesystem which doesn't support them (which may explain
> why you've never seen such a thing; if normally you're happy with
> whatever your Unixoid lisp is happy to do with :new-version). It's
> not a very good imitation, obviously, but it could possibly be made to
> work in certain well-controlled circumstances.
They would certainly have to be very controlled circumstances since the
translation calls out explicit version numbers. The translation rules
could easily become unmanageable.
P.S. As a general comment to the list: I really like SBCL and I
especially like the philosophy of being able to easily compile it from
I have a large project that I hope to eventually be able to develop
using SBCL instead of LispWorks.
Keep up the good work.