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


re: Consider (again) this code:
       . . . 
       (fix-base-system 'lisp)
       (fix-base-system 'kee)
       (fix-base-system 'umass-utilities)
    This tells the compiler that I am not going to redefine "CONS" and "CAR"
    and "CDR" and the other 500 functions.  The compiler can do constant
    folding and open coding or whatever is valid and appropriate for
    calls to those functions.  But I want the compiler to assume that
    my functions are full of bugs (too true, too often) and calls to 
    those functions should be tracable/redefineable/debugable.
    . . . 
    Is there some combination of FTYPE/INLINE that provides a portable
    substitute for the above? ...

The very question as to whether such a declaration would be at all useful,
as well as the degree of its utility, depends on how an implementation does 
function-to-function interfaces.  Few people in the common lisp community 
have been desirous of imposing particular Lisp-system implementation 
techniques into the portable standard; thus it's not surprising that few 
are interested in standardizing on implementation specific tricks. 

On the other hand, what is useful about the "constant-foldable" declaration
is that the transformation (sqrt 2.0) ==> 1.414...  is independent of how 
any Lisp system (or compiler) is built [except to the degree that you view 
this as a "compiler optimization".]  User-level macros can do the same 
thing, but probably less thoroughly than the compiler.  It only depends 
upon knowing some simple properties about the function SQRT.

Also, the type system in Common Lisp isn't purely a "compiler efficiency"
hack; although I'm not aware of a really good "type inferencing" CL
compiler, this declarational information can be used in the sense of
"strong typing".  Thus its justification is not merely that fixnum
declarations can make compiled code run faster.  [But I admit that there
are so many systems wanting at least some type declarations for efficiency
that a few lone "hold outs" against them probably couldn't prevent their
appearance in CL].

Perhaps "block compilation" is a better line of pursuit since it has some 
implications for "modularity" as well as potential for code efficienty.

Note that lots of somewhat-incompatible redefinitions of functions don't 
invalidate FTYPE, or INLINE, or "constant-foldable" assumptions; but they 
would invalidate the definition you have given (again!) for "constant 
function", i.e. that it merely means "I won't redefine this function at 
runtime".  [This is the point you said didn't make sense to you; I'm sorry 
I don't know how to put it in any plainer words].  Thus even in an 
implementation whose compiler could profit from such information, the 
declaration seems like overkill because it is too easy to violate its 
contract without violating any useful requirement.  It needs to be more 
specific (thus I would call it "vague" for not being that specific).

Note also that there is a proposal to the x3j13 "cleanup" committee to make 
it an error to redefine any function named in the Lisp package; this would 
cover your case (fix-base-system 'lisp).  But the proposal is not particlarly
for the purpose of enabling potential compiler tricks; rather (I think) it 
is for the purpose of facilitating reasonable standards for code sharing.  
I.e., how can you absorb my portable code that uses lisp:append if you have 
redefined it to do something totally different.

-- JonL --