[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
directory streams
- To: MMCM at MIT-AI
- Subject: directory streams
- From: Richard M. Stallman <RMS at MIT-AI>
- Date: Sun ,3 Jan 82 21:14:00 EDT
- Cc: BUG-LISPM at MIT-AI
Date: 29 December 1981 12:08-EST
From: Mike McMahon <MMCM at MIT-AI>
Date: 26 December 1981 23:43-EST
From: Richard M. Stallman <RMS at MIT-AI>
I've changed the handling of unrecognized properties in directory
streams to be to read them, not to take them as strings.
This is more general.
On the contrary, strings are more general. They make no incorrect syntactic
assumptions. READ will be confused by /'s, :'s and spaces in dates; by spaces and
commas in textual lists; by unbalanced parens or double-quotes; stray #'s, etc.
If you use strings, then M-X Change File Properties always works, you just lose
the local error checking and canonicalization. With READ, in addition to getting
errors you can lose potentially significant case (in filenames and user names).
Sorry, but it is unacceptable for the values of random properties to
be restricted to strings. They have to be able to be symbols,
numbers, or lists (at least), and they have to appear as such in the
:DIRECTORY-LIST. The default definition of this operation (which
REMOTE currently uses) was formerly unable to return anything but a
string for unknown properties.
It is ok for protocols transmitting property values to make
assumptions about the value of a property whose meaning is defined by
the system -- such as, that the author is a string -- but they must
not assume that the :LAST-FROBBOZZ-DATE property (which they have
never heard of) has a string as its value. Its value is probably a
number, and if it is transmitted by PRIN1 and READ everything will work.
You can obtain the old behavior in the new system by outputting the
appropriate properties with PRIN1 rather than PRINC. However, there
was no way to obtain the new behavior in the old system.
Why transmit ANY property's value with anything other than PRIN1 and
READ? No circular lists are transmitted thru the directory stream
anyway, and people don't need to be able to read it. So what if a
date is transmitted as a number in decimal, as long as it turns into
the right thing in the :DIRECTORY-LIST?
Wouldn't it be more consistent to have SETTABLE-PROPERTIES<NL> turn into
(:SETTABLE-PROPERTIES T) rather than having to translate (:SETTABLE-PROPERTIES (T))?
It's fine with me either way.