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

Re: Sundry Dylan Questions

On Mon, 25 Jun 2001 12:42:49 +0100, Roland Paterson-Jones
<rolandpj@bigfoot.com> wrote:
>
> 1. Can you import classes/generic functions from another library and
>    then seal them?

No, since sealing has global semantics.

Suppose you have a library L1 that exports an open class <foo>. Now
if library L2 extends <foo> with a subclass <bar>, and library L3
declares <foo> sealed, then you have an inconsistency.

What you *can* do is to declare a subclass of <foo> and seal that, or
for generics define a sealed domain over part of the type hierarchys.

> 2. Why would a type be sealed but not primary (e.g. <function>)?

You might want to use a multiple inheritance-heavy style within your
library, but prevent extensions outside it.

Eg, suppose that within the runtime we want to distinguish between
generics and methods, whether a function closure captures any
variables or not (this determines whether you need to do work building
a record of the captured variables), and whether a function has 1, 2,
3 or 4+ arguments (so we can optimize the calling convention for
low-arity functions).

Each of these aspects is orthogonal to the rest, so expressing each
property as a set of mixable subclasses of <function> is reasonable,
but we don't want to let users subclass <function> (which could break
a whole bunch of your implementation assumptions). Henced the class
should be sealed but not primary.

Also, note that this example is completely cooked up off the top of my
head -- I don't think actual Dylan compilers do this, for what are
probably excellent reasons. :)

> 3. How is singleton dispatch implemented efficiently?

A lot of uses of singleton dispatch are very stereotyped, and a good
compiler can recognize and optimize them.

IIRC, GD can recognize a pattern like

  define constanct <mode> = one-of(#"hard", #"easy);
  
  define generic frob! (mode :: <mode>) => ();
  
  define method frob! (mode == #"hard") => ();
    wibble();
  end method frob!
  
  define method frob! (mode == #"easy") => ();
    thud();
  end method frob;

and turn the dispatch into a pointer comparison (or eliminate the
dispatch altogether if it's obvious). IIRC, it also does a good job
on singletons of numbers. Together that's about 95% of the uses I
put singletons to.


Neel
Follow-Ups: References: