On Jul 22, 2004, at 1:24 PM, Christophe Rhodes wrote:
> Marco Antoniotti <marcoxa@...> writes:
>> As I said, I am more interested in "simple" typechecking rather that
>> "typechecking aimed at optimization". Of course, the second one is a
>> very good thing indeed.
> Right now, so am I, because at least the so-called "simple"
> typechecking is a tractable problem. Nevertheless, it is
> optimization, just not in the direction of speed.
>> As another interesting problem, think of the following
>> (defclass foo () ((bar :accessor bar :type vector)))
>> (defclass zot () ((bar :type string)))
>> (defclass zut (foo zot) ())
>> What should the FTYPE of BAR be at this point?
> I think this is precisely the wrong way to look at things, because of
> the defined dynamicity of CLOS. BAR is a function composed of many
> different parts, and certain invariants apply to certain parts. Given
> the (not very stringent) constraints on redefinition of functions in
> CLHS 126.96.36.199, I would say that there are only very few pieces of
> information that one can deduce about calls to BAR within the same
> file as these definitions (say, it takes one argument) and even fewer
> outside (since the user can later remove all the methods, then define
> a new function (with a prior fmakunbound if necessary), and other
> calls to BAR are defined to reflect the new definition.
I guess I am looking at the "compiler" from a "programming environment"
point of view.
I agree that the possibility of redefinition of functions, methods, and
classes would thwart most inferences about a "type" of a call, however,
I would still want the "compiler" to tell me that something may be
amiss. This would also apply to all the redefinition operations. Of
course this would open a can of worms with respect to what constitute
the "development environment" vs the "delivery environment", but for
CMUCL/SBCL this issue is a bit moot.
> What you seem to be after is checking above and beyond what is
> semantically allowable by the standard. That's fine, but for
> goodness' sake _say so_ up front so we don't talk past each other.
Well, yes. I am interested in more (friendly) type checking than what
is usually implied by the standard, but I would disagree with the
notion that this kind of type checking is not semantically allowable by
> am, right now, interested mostly in those implementable checks that
> are admissible by the semantics of the language, and probably (as an
> additional constraint to "implementable") those which do not require
> function or method body cacheing and automatic recompilation of method
> functions on class redefinition.
I think we are on the same track. I cannot deny that TRT would be to
have a lot of information cached about functions, methods, and classes.
OTOH, I would already cheer a CL that handled
(declaim (type (list integer) *L*))
Marco Antoniotti http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th FL fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.