Lisp - open in SBCL

Author

open in SBCL

Antonio Menezes Leitao

2004-04-29, 8:27 pm

Hi everybody,

My initial impression that CMUCL and SBCL would have many things in common
is rapidly disappearing.

According to the Hyperspec (Function open):

An implementation is required to recognize all of the open keyword
options and to do something reasonable in the context of the host
operating system. For example, if a file system does not support
distinct file versions and does not distinguish the notions of deletion
and expunging, :new-version might be treated the same as :rename or
:supersede, and :rename-and-delete might be treated the same as
supersede.

Now, if you open a file for :output, specifying that :if-exists is
:new-version, and the file in fact exists, CLISP, Allegro, Lispworks and
CMUCL (all in Linux) apparently follow the Hyperspec suggestion and
treat :new-version as :supersede.

Contrary to its venerated father (and the explicit recommendation of
the Hyperspec), SBCL (in Linux) apparently prefers to treat :new-version
as :error, meaning that an error is signalled.

Is there a rational to this behaviour?

Thanks,

Antonio Leitao.

nikodemus@random-state.net

2004-04-29, 8:28 pm

Antonio Menezes Leitao <Antonio.Leitao@evaluator.pt> wrote:

[I'm swapping the order of quoted bits here, sorry.]

> the Hyperspec), SBCL (in Linux) apparently prefers to treat :new-version
> as :error, meaning that an error is signalled.

Note that CLHS says:

> options and to do something reasonable in the context of the host
> operating system. For example, if a file system does not support

The operative words being "something reasonable"... I at least consider
:error a reasonable behaviour given that the filesystem doesn't do any
versions -- greatly preferable to :supersede and :rename-and-delete (I
don't want my files deleted or overwritten due to silly defaults), and
somewhat preferable to :rename (I don't want my deliberately made
backups overwritten).

The cost of implicit :error is the time required to write :if-exists
:supersede, or whatever the behaviour you want, but the cost of implicit
:supersede is data-loss.

The issue has been hashed over at least a couple of times on the sbcl
lists -- persusal of the archives may produce enlightenment.

Anyways, reading "For example..." as an explicit recommendation sounds
somewhat suspect to me, though you're quite right about SBCL being
against the grain here.

Cheers,

-- Nikodemus

Antonio Menezes Leitao

2004-04-30, 4:41 am

On Thu, 29 Apr 2004 18:16:12 +0000, nikodemus wrote:

> The operative words being "something reasonable"... I at least consider
> :error a reasonable behaviour given that the filesystem doesn't do any
> versions -- greatly preferable to :supersede and :rename-and-delete (I
> don't want my files deleted or overwritten due to silly defaults), and
> somewhat preferable to :rename (I don't want my deliberately made
> backups overwritten).
>
> The cost of implicit :error is the time required to write :if-exists
> :supersede, or whatever the behaviour you want, but the cost of implicit
> :supersede is data-loss.
>
> The issue has been hashed over at least a couple of times on the sbcl
> lists -- persusal of the archives may produce enlightenment.

I followed your suggestion and although I recognize there were some
good points being made, my experience with Lisp Machines is a bit
different.

On the Explorer Lisp Machine we had versions. This was not a
good replacement for a proper CVS but it was helpful, anyway. So I got
this habit of taking advantage of the Operating System facilities and,
whenever it made sense, I would ask for :new-version. But I was aware
that versions were not generally available on Unix (although I remember
that VMS add them) and, as a result, I knew that :new-version
would not be available in other Lisps and would have to be replaced by
something else. If I want to avoid #+ forms (which I do) what are my
options?

- Either choose the conservative solution that works in all
systems (which is :supersede) and forget about versioning on
systems that support it (like the Lisp Machines).

- Or take advantage of the "consensus" that the compiler would translate
:new-version to :supersede in systems that do not support versioning,
thus allowing me to take full advantage of the Lisp Machine file system
and, at the same time, being able to run the code in other systems.

The reason why I think that the translation from :new-version to
:supersede is OK is that when you use :supersede you are in fact creating
a "new version" of some file and setting the old one aside. :new-version
does exactly the same thing but, on file systems that support it, it
allows you to retrieve the older versions.

Note that changing the semantics of the operation is explicitly allowed
by the Hyperspec:

Where necessary to accomodate the file system, an implementation deviate
slightly from the semantics specified here without being disqualified for
consideration as a conforming implementation. If it is utterly impossible
for an implementation to handle some option in a manner similar to what
is specified here, it may simply signal an error.

This, combined with the suggestion in the Hyperspec:

For example, if a file system does not support distinct file versions
[...], :new-version might be treated the same as :rename or :supersede
[...].

gives me the feeling that allowing :new-version to gracefully
"downgrade" to :supersede is the appropriate solution here.

I know that there aren't many file systems nowadays that support
versioning so the :new-version is not doing much actually. However, the
SBCL approach will simply eliminate that option because it will force
programmers to always write :supersede.

Thanks for your comments,

Antonio Leitao.

PS: By the way, after strugling for more than two hours with the most
esoteric bug I have ever seen in my life, I managed to port my Linj
compiler to SBCL 0.8.10. The bug is amusing. Try this:

* (defparameter *f* #'identity)

* (defstruct foo
bar)

* (defun bug ()
(let ((foo-bar *f*))
(if (functionp foo-bar)
(funcall foo-bar 1)
nil)))

* (bug)

Maybe someone will find a shorter example that also triggers the bug.

Sponsored Links