Re: readtable within fasl

[JonL.pa@XEROX.ARPA]

The problems with a user-tailorable READ is one of the reasons why, over
12 years ago, we chose a format for MacLisp's FASL files that is
somewhat akin to a position-independent list encoding.  (But in fact, it
was primarily for speed that the READ-oriented option was abandoned).

However, there was still the need to introduce load-time evaluation, in
order to create structures that can't be known even faintly at compile
time; there is an "internal" marker, accessible to the MacLisp user as a
global variable (named SQUID, I believe), so that the portions of a
structure that need to be eval'd at load time could be marked.  E.g.
    (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE))))
and the #, signals a spot for load-time evaluation, even though the
overall structure is essentally a QUOTE form.  

One needn't imagine that #, is the only client of this "internal" marker
-- it provides the way to get all but the trivial datatypes into
quotified structures; for example, I may have an input syntax for
arrays, but still PRINT won't put them out (MacLisp PRINT won't, at
least), and certainly not every conceivable datatype needs a special
encoding for the FASL file format; merely a LIST, which is viewed as a
general program by EVAL, is satisfactory to create any createable
datatype instance.

Interlisp too has a loadtime evaluation construct, but it may only
replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such
as indicated by the #, above.  A primary reason for this limitation is
the similarity of Interlisp's and Franz's compiler output formats --
basically an ascii string to which READ is applied.   MacLisp's loader
is indeed quite more complex, but it results in a space savings for the
FASL files and a considerable time savings when loading them.

-- Jon L White --