[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Read macros vs. macro-->declare

    Date:  7 May 1985 1319-PDT
    From: Rem@IMSSS
    Subject: Read macros vs. macro-->declare

    ...  would it be feasible to have a continuation read-macro that 
    produces a scheme-style continuation that gets evaluated the first time
    anybody tries to perform an operation upon it, even a trivial one 
    like PAIRP?

You're already (implicitly) performing "an operation" upon it if you
assume the expression is code at all. The bad part about readmacros
is that they force me to think "language semantics" at times when I might
only want to think "symbol manipulation". eg, I can't write an editor 
utility which calls normal READ to get
out of the buffer, manipulate the expression, and PRINT it back into
the buffer with any hope it that it will run on a system with different
characteristics than those I used to edit it. Here the expression is 
not code but data. Something along the lines of
works much better because you can READ-manipulate-PRINT it all day
without worrying that it's code, then can READ-COMPILE-FASDUMP or
READ-ABSORB-EXECUTE the processed code in some other system than
you did the original processing in without fear that you've lost a
read conditional.

By the way, this made me think of an interesting point on a slightly
different point, which is that one might imagine files full of (non-program) 
symbolic data which want to be read in certain package, but which because
it will never be EVAL cannot use the IN-PACKAGE strategy. That's another
example of inferring too strongly that anything that will be seen by
READ must be code and another argument for -*- ... Package: ... -*-
rather than IN-PACKAGE. ie, I'd rather use

  ;;; -*- Package: KEYWORD; -*-
  ;;; My data file

  (3 FOO BAR 7)
  (16.0 3/7 (X Y Z))

and be able to just repeatedly call READ on the file contents than
continually do some kludge to look for an IN-PACKAGE form at the head
of data files, as in:

  ;;; My data file

  (3 FOO BAR 7)
  (16.0 3/7 (X Y Z))

or worse

  (EXPORT '(...))
  (3 FOO BAR 7)

where it might be ambiguous whether EXPORT, etc. are part of the package
spec or part of the data.