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

Re: Sealed as Source Annotation

    Date: Fri, 14 Jul 2000 13:15:40 -0400
    From: P T Withington <ptw@callitrope.com>
    Subject: Re: Sealed as Source Annotation
    
    Maury Markowitz maury@remove_this.sympatico.ca.invalid on  2000-07-14 12:45 wrote:
    >> In the case of Dylan, a large part of the reason for having "sealing" is
    >> to enable more static, faster, code to be generated.
    > 
    > Why is this? I understand a little of the reasoning in Java, but much of
    > this is foreign to my Obj-C experience - the only language/runtime I feel I
    > have any basic grasp on it's inner workings. This information does what to
    > the compiler's output exactly?  Does it increase dispatch times?
    
    As an extreme example:
    
    define class <foo> () end;
    define method frob(x :: <foo>) ... end;
    define variable y :: <foo> ...;
    frob(y);
    
    will not do any dispatching at all.  Because classes and methods are sealed
    by default, and the compiler knows y is a <foo> and it knows there is only
    one method for the generic function frob that applies to <foo>s, it can
    compile the generic function call directly into a call to the method.

Even more: if frob is not exported from its module and is not used anywhere else
in the library, then the compiler knows there's only 1 call site, and can INLINE
the method body.  Inlining in a language like Dylan can sometimes actually lead
to space REDUCTION (counter-intuitively), since that means method bodies can be
specialized to particular arguments, not just argument types.  Very weird, very
useful.

(Now, if only you'd declared y to be constant, maybe it could be compile-time
evaluated, too... :)