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

Recognizing AUTOLOADing macros

The following deficiency in COMPLR is now corrected:
    Date: 9 February 1982 23:10-EST
    From: Christopher C. Stacy <CStacy at MIT-AI>
From:     DEVON@MIT-MC (Sent by DEVON0@MIT-MC)
Date: Thu, 2 Apr 82 05:14:37 GMT
Original-Date: 02/04/82 01:14:37 EDT
    Isn't it reasonable for compiled and interpreted code to have the same
    environment?  I tried
    (eval-when (compile)
      (load "guest5;devon lisp"))
    which puts autoload properties on many of my commonly used macros, etc,
    but the compiler ignores that, and I've been reduced to keeping two
    copies of everything, one for the compiler and one for the interpreter
    since I don't know how to make the compiler recognise synonyms and do
    autoloads!  And I keep having to fix the smae bugs twice!!!  Help!!!
Actually, some parts of the COMPLR did already "recognize" these autoload
properties (e.g., top-level forms), but there was a deficiency in the
way that "code" was being macroexpanded which caused it to ignore
autoloadable macros unless they had a FUNTYP-INFO property.  I've changed
this so that it will try autoloading unless the function is already
FBOUNDP.  I've tried this out with your macros on a little test file:
	(eval-when (compile)
	      (load "guest5;devon lisp"))
	(defun foo (x) (iff (eq x 'FOO) 5))
and it wins now.  Unfortunately, the net to AI was down, so the patch is 
only on MC and ML as of now.

By the bye, DEVON, did you know that there is a function ARRAYP in the
file MLSUB (for MacLisp SUBroutines)?  It checks to be sure that the
array isn't one of the "funny" kind, like READTABLE, FILE, SFA, or
whatever;  these "funny" kinds are of typep ARRAY, but are of
differing array-type.   This function may be documented soon.