Dylan compared to Python

[Tim Peters]

[Paul Prescod]
> It seems like Dylan implements polymorphism by allowing a "generic
> function" to dispatch on multiple arguments. How does this work with
> separate compilation?
>
> In Python I can do this:
>
> def a( foo ):
> 	foo.a()
>
> and foo could take an infinite number of types. This code can be
> "compiled" (byte-compiled) without knowing what type foo will take at
> runtime. To implement this feature in statically typed languages usually
> requires pre-declared interfaces and/or subclassing. Is this the case
> with Dylan?

All of the above, Paul!  The Harlequin Dylan environment can be asked to
color-code call sites to show what level of optimization it was able to dope
out for each call.  There are six colors, from "don't have a clue -- we'll
figure it out from scratch at runtime", to "we threw this call away because
we know everything about it *and* determined that making the call couldn't
make any difference to the outcome".

Which color you get depends largely on how many (optional) type annotations
you've added, how specific they are, how close the match between declared
types and actual types at the call site, and how "sealed" things are.  From
the docs (Chapter 9 of the Dylan Reference Manual):

    The sealing directives include:

    Declaring a class to be sealed or open. This controls whether a
    class can be directly subclassed outside the library in which it
    is defined.

    Declaring a class to be abstract or concrete. This controls whether
    a class can have direct instances.

    Declaring a class to be primary or free. This controls how a class
    can be used for multiple inheritance.

    Declaring a generic function to be sealed or open. This controls
    whether methods can be added to the generic function from outside
    the library in which the generic function is defined.

    Using define sealed domain, or using the abbreviations define sealed
    method and sealed slot. These disallow the addition of some methods
    from outside the library in which the generic function is defined.

    With the exception of define sealed domain, these directives are
    expressed as adjectives on the generic function definition, class
    definition, method definition, or slot specification.

Put it all together, and you get lovely <wink> rules like "A class C (with
direct superclasses D1...Dm) that is not explicitly known in L may be
created only if no method in G actually blocks C.  A method M (with
specializers S1...Sn) in G potentially blocks C at argument position i if
there exist j and k such that Dj is a pseudosubtype of Si, Dk is a
pseudosubtype of Ti, and Dk is not a pseudosubtype of Si. A method M
actually blocks C if M potentially blocks C at some argument position, and
for every argument position i where Si and Ti are disjoint, M potentially
blocks C at i.".

Of course rules like that never apply to anything people actually write --
until the last-minute change before the killer demo <wink>.

constraints-don't-help-if-they-aren't-constraining-ly y'rs  - tim