(Seems this too didn't make it on the first attempt, resending.)
Howard R. Stearns wrote: [1999-08-26 09:34 -0500]
|...|
> Imagine that Unix open() was not provided, and that applications had to
> look up inode numbers themselves. In this case, there wouldn't even be
> a "operating-system string" used for access.
But this is a hypothetical case. Even if there is an operating system
in use that does not itself provide the mapping from file names to
file objects (inodes or whatever), it would be so exotic that one
would not have to worry about it. (After all, why not imagine that
Lisp would have to access the raw devices themselves (we get a
Lisp Machine I suppose...).)
> On Windows, as I understand it, the open function in the ASCII library
> can be used to access ASCII file names, but I'm not to sure about how
> "character code tables" come into this. Furthermore, there is an open
> function in a wide character library that can be used to access "any"
> file name. Suppose the wide characters used by the operating system are
> not consistent with the wide characters used to represent extended-char
> in the Lisp implementation. (Suppose the Lisp doesn't support
> extended-char at all!) For example, if one is fixed width wide and the
> other is a different fixed width wide or multi-byte, what should
> string-for-host return? Should there also be a "bytes-for-host"
> function? Should the thing returned not be a Lisp string at all? After
> all, if we're talking about what gets passed to the OS, maybe the OS
> byte-string should be returned as foreign data.
The `string-for-host' function could return different kinds of strings
depending on the flavour of the file system interface function that
gets called, e.g. strings of 8-bit characters or strings of 16-bit characters
as appropriate. If the characters available in the Lisp implementation
do not match directly the characters available in the operating system
environment, then the Lisp implementation would have to have some
translation mechanism for characters anyway.
> What about a Lisp system that supports pathname access to a database,
> where individual records in the database are packaged up and stored on
> the OS filesystem as a single big file? (I.e., the database uses it's
> own mechanism for accessing individual database "files" within the OS
> file.) Suppose further that the database API operates not by
> namestrings, but by "record numbers".
Isn't this a very hypothetical example? Anyway, I suppose that if
this is implemented properly, the pathnames involved would have
a host and/or device component such that it does not exist in the
OS filesystem world, so there will be a way to identify such a case
programmatically.
|...|
Vassil Nikolov. (See header for additional contact information.)
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.