More on (B): the editor's "reading" of files

[Jon White <JLW@SU-AI.ARPA>]

In-reply-to: your message of 24-Apr-85 23:57 EST

OK, I buy the argument that the editor wants to be able to distinguish
various language types [egad, some even do so by looking at the "extension"
field of the file name]; but after having made that distinction, wouldn't
it be reasonable to dispatch off to a programmable attribute-parser that
could be quite different from one language to another?

That is, given that you know that a file is in Common Lisp syntax (as
opposed to, say, Franz, or Fortran, or random text), then some flavor
of specialized parser would rip along and find out attributes that are
possibly unique to common lisp and possibly shared with other lisps.
One of the problems with the ;;; -*- convention is its lack of
"tailor-ability" by the user; and as this whole line of discussions has
brought out, there are more and more things that seem to want to be
in the attributes lines.

Of course, these are only conventions for the initial, or default, settings
of various user-accessible switches on the READer -- as DLW pointed out,
one may still have to process the file "in order", form by form, to be
100% sure of the correct state at any paticular point in the file.  Yet,
if some convention like this isn't adopted, then will CL be substandard
compared to zetalisp or spicelisp?  One of the latter two conventions
could be adopted bodily into CL;  I'm sure you have a preference here.

Interlisp has a number of internal, non-READ parsers that inspect the first 
portion of a file for certain information.  But it is mainly a time-saving 
hack that READ isn't used, because such source files are virtually always
mechaniclly produced, and have a very rigid format; in Interlisp, you
can *always* READ the first expression or so of the file and look at it
with CAR and CDR etc, because the Interlisp reader has no errors other
than premature end of file.  [well, almost *no* errors -- there is the
problem that symbols are limited to 256 characters.  I fixed a bug related
to this limitation sometime last year.]

By the bye, I'm not sure if your reply laid to rest my "fear" that one
can produce an almost-correct common lisp source file which the zetalisp
editor can't even bring in to a buffer (previous note used "load") because
it dies trying to READ some little part of it that happens to be total
garbage.  What's the scoop?


-- JonL --