Re: naming data sets

[Ben Pfaff]

I'm getting ready to commit, in the next day or two,
approximately what we agreed upon earlier.  Here's my original
plan along with some of the details, to give folks on the list a
chance to comment before I commit.

> Thus, I propose that we support multiple data sets, each of which
> has an independent dictionary.  We introduce a new type of file
> handle for these data sets.  Tentatively I'll call these
> "temporary" file handles and "temporary" data sets (but better
> terminology is welcome).  Access to temporary data sets is
> through temporary file handles, using the usual commands for
> accessing system files (GET, SAVE, XSAVE).

I'm still calling them "temporary" and I'm still not that happy
with it.

> Here's what I'd add to the PSPP language:
>
>         * Some extra syntax on FILE HANDLE for declaring
>           temporary file handles (MODE=TEMPORARY perhaps).

I dropped this.  There is no need to declare a temporary file
handle in advance.  Instead, any file handle with a name that
begins with $ is a temporary file handle.

>         * A new command for destroying temporary file handles
>           (e.g. CLOSE FILE HANDLE or DELETE FILE HANDLE), so that
>           the memory or disk space used to store them can be
>           freed up.

I'm going to call it CLOSE FILE HANDLE and I'm going to extend it
to work on any kind of file handle, not just temporary handles.
I'm using a ref-counting scheme for memory safety.

>         * GET, SAVE, XSAVE would be extended to read and write to
>           temporary file handles.  I'd introduce some kind of
>           syntactic sugar so that it wasn't strictly necessary to
>           declare temporary file handles in advance,
>           e.g. something like XSAVE OUTFILE=TEMPORARY
>           <HANDLENAME> would work properly.

The "syntactic sugar" is the $ prefix, so that you just write,
e.g., XSAVE OUTFILE=$MYTMPNAME.

The main mechanism I'm introducing for programmatically dealing
with temporary file handles is "any-writer" and "any-reader".
You pass either one of these objects a file handle and it figures
out what kind of thing it is and handles it appropriately.  If
you pass it a temporary file handle, it'll deal with it in
memory.  If you pass it a file name, then (for reading) it'll
open up the file and figure out whether it's a portable file or a
system file and read it properly either way or (for writing)
it'll look at the file name extension and decide whether to write
a system file or a portable file.  The programmatic interface is
the same regardless of the underlying storage.

How's this sound?  It's mostly implemented, just a few loose ends
to tie up now.
-- 
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver."
--Daniel Pead