[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: Type inferencing [ was Re: Re: possible dotimes enhancem
From: |
Paul F. Dietz |
Subject: |
[Gcl-devel] Re: Type inferencing [ was Re: Re: possible dotimes enhancement] |
Date: |
Sun, 03 Aug 2003 13:59:35 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 |
Camm Maguire wrote:
BTW, did you have any comments on my last suggestion for dotimes? I
feel that is safer than the do* code I submitted, as it would really
require a read only scan of the loop body.
I'll be sending a reply to that sometime today.
In general, I suppose we're touching on type inferencing. If my tests
so far extend to other areas, it can be a *major* performance win. Of
course the real place to do this is in the compiler, and its probably
not the highest priority. Are there any thoughts/suggestions as to
how to proceed on this front generically?
There's something to be said for making type inference visible to the
user, at macro expansion time. The &environment argument of a macro
could be used to carry declaration information. There's no standard
way to access this information (although a proposal to do so was made
and rejected). You'd also want a user-level type propagator (so you
could ask 'what can you tell me about the type of this form in this
environment'.)
CMUCL/SBCL does type propagation at compile time, after macro expansion
has occured. With the macros gone it can tell if a variable is going
to be assigned to, so it can more accurately propagate type information
from bindings to uses. The macro-time type propagator would have
to have some summary information about whether the macros expand
to code that does assignments.
Someone has suggested using CMUCL/SBCL's compiler as a lisp->lisp
translator, which would introduce type annotations for other compilers.
I don't know how practical this would be.
Paul