[bitc-dev] Type Classes: Pragmatics Questions

[Mark P Jones]

| This makes me inclined to rule out specialization, because it 
| also seems to rule out *dynamic* linking. In the BitC context,
| our objectives are not restricted to compiling a microkernel.
| There are certainly cases where we will engage in whole-program
| analysis, but I would prefer a design that does not obligate us
| to do so to obtain reasonable results.

I'm not sure that it rules out dynamic linking altogether, but
I think you would need to add some kind of "dynamic specialization"
to make the combination work.  For example:

- The source for program P contains an overloaded function f
  that gets used at two different types, t1 and t2.

- The executable for program P contains:
   1) code for f that has been specialized to type t1
   2) code for f that has been specialized to type t2
   3) code that will generate new versions of f, on demand,
      for other types.  (Maybe 1 and 2 were created by
      running this function twice when P was first loaded).

- An extension E that is going to be linked in dynamically to
  the running program P requires instances of f at type t1 and
  type t3.

- When the extension E is loaded, the linker notices that we
  already have a version of f at type t1 (item 1 above) that it
  can reuse, but it must run the code generator (item 3 above)
  to produce a new version of the code for f at type t3.

- Creating new specializations of f may also require the creation
  of new specializations of other functions that are used in the
  definition of f.  A dynamic linker must take steps to make sure
  that all the necessary specializations are created.  Think of
  this as JIT specialization (and you'd probably want JIT optimization
  too ...)

Conclusion: I don't think that dynamic linking and specialization are
fundamentally incompatible.  (But yes, the combination comes at the
price of some more sophisticated machinery than we get with current,
off-the-shelf dynamic linking mechanisms.)

All the best,
Mark