Why is LOAD-LOGICAL-PATHNAME-TRANSLATIONS in ANSI CL ??? LISPOS people ??
Rainer Joswig
Does LOAD-LOGICAL-PATHNAME-TRANSLATIONS do **anything** useful?
I mean I can't even call it a second time. Seems not to be a useful
interface
to a repository of logical pathnames (whatever it may look like).
Was there ever a useful proposal for a CLOS-based system facility, which
makes
*intelligent* use of logical pathnames ? There must be something.
I would want something that
- loads /redefines logical pathnames on demand and gets rid of physical
pathnames completely
- uses its own packages and doesn´t clutter cl-user
- doesn´t create random packages like LISP, USER, ... in ANSI CL
- doesn´t redefine CL-USER or CL to use FUTURE-COMMON-LISP or something
similar ugly
- where a system is a CLOS object
- defines useful restarts (reload system, skip system, reload logical
pathname, ...)
- defines and maintains a repositiory of system definitions and pathname
translations
- supports the creation of documentation (documents module interfaces)
- supports text type conversions (CRLF -> LF, ...) for different OS
versions
- is patchable
- supports multiple binary directories
- can generate a plan
- let's define additional system actions
- maintains a log of applied operations
- can deal with users, groups, capabilities, ...
Who has done work in such a thing? If there isn't such a thing, could we
create a working group
defining and implementing it? Can't be that difficult to get something
going.
If the LISPOS people want start, start now with something *simple*. We
grow from that...
I want one and not ten system faclities.
Who joins?
Who has proposal?
Marc Wachowitz
Rainer Joswig <jos...@lavielle.com> wrote:
> If the LISPOS people want start, start now with something *simple*. We
> grow from that...
A radical suggestion: Forget all that mess from the application's point
of view: no hosts/devices/etc., only nested names. Use something simple,
like the "pseudo-file-system" name concept of Inferno, and map the ugly
details onto such a logical structure. For some more inspiration, read
http://www.lucent-inferno.com/namespace.html
Provide hooks which allow a "logical file" or "logical directory" to be
implemented (as a kind of very high-level "device driver"), such that e.g.
a "directory" /net may map nested names to network hosts. However, don't
let such a "driver" interact directly with the other layers, but restrict
it to a simple "conceptual file" interface. Avoid deeply interdependent
structures - the full power of OO is likely to fight back in this area.
A "file" is (and remains) first of all a sequence of bytes, which can be
passed/accessed through arbitrary filters (which result in yet another
logical "file") to provide the desired structure. Combine simple tools
- which know how to do one thing very well - with simple means, similar
(in principle, not necessarily in implementation) to Unix pipes/filters.
Above all keep it simple, fight complexity. In practicel, Unix-style
text stream connections - despite all their theoretical "uncleanliness" -
are much more flexible than horribly complex "binary" file structures,
where you can't do much beyond the intentions of the respective application
without lots of low-level programming or special-purpose tools.
Application-typed files are evil. ONE editor is the ultimate "browser", if
only there's an intelligent origanization of the naming system and logical
data structures, with decent (self-)documentation (at that point, Unix
unfortunately lost much for which it did provide a good foundation). Of
course, this doesn't prevent the creation of specific (though most likely
merely customized) menu-directed user interfaces, for those users who
don't want (or shouldn't be able) to manipulate the text structure.
At the application-level, s-expressions are the exchange-format of choice.
With some general conventions, they provide readability, easy parsing
or pretty-printing, and enough room for extensions which can be ignored
by tools which are only interested in a subset of the information. We
may need a kind of concept-oriented SGML based on s-expressions (perhaps
Erik can give some advice in that area?). Maybe XML can be exploited -
I didn't yet look at it very closely, though, and I fear that it might
be (or become) yet another big bag of special cases and low-level hacks.
If you can't use a plain-text-based information structure, use something
more appropriate (like e.g. a self-descriptive relational database, not
necessarily implying the ugliness of SQL and its limitations), but chose
something which is very general, not a myriad of ad-hoc data formats.
This is really only the second-choice, if mere text doesn't work - and
should still use text-based format as contents, where that's reasonable.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>