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

A NAM Veteran muses ...



[Please paron the politically-incorrect Subject line ;-)]


Having been thinking about various Dylany things recently, the following
language extension idea popped into my head the other day ...


Although Dylan allows pretty tight control over dynamism, there's a
trade-off against static knowledge.  In particular, if you want to leave a
(domain of a) generic function open for other libraries to extend, you
risk getting "No applicable method" (NAM) errors, and it seems to be very 
hard to tell whether or not they'll happen before they actually do.  Even
if you provide a default method, you still can't tell at compile time
whether clients of your GF might get a NAM, because someone can call
remove-method on an open GF.


So, how about a new declaration like this (adjust adjective to taste):

  define implemented domain my-gf (<string>);

which would disallow remove-method on the domain, while still allowing
add-method (and methods added by "define method")?


I haven't thought this through, but points to be addressed include:

1) Would this actually provide the compiler with enough information to
give a useful list of definite NAMs at compile time?  As the langage
stands at the moment (even assuming a "best possible compiler"), I believe
that in a statically-determined list of possible NAMs you can easily have
most never actually happen, making it much less useful as a debugging
tool.

2) The phrase "at compile time" here is not clear enough.  I probably mean
something like "after all methods explicitly known [i.e., defined or
imported] in the library are taken into account".  I don't have my DRM to
hand to think about order of execution and interaction with top-level
expressions (e.g., global initialisation of objects, as in
Harlequin-Dylan's "define table") more clearly.

3) You might get a new class of errors which can't be predicted at compile
time, through newly disallowed calls to remove-method.  However, this
seems much less likely in practice (and from experience) and doesn't seem
to make the situation worse. 

4) I'm not sure whether this is orthogonal to "sealed" or subsumed by it.
It probably depends on the answer to the "timing" question in issue 2.


What think ye?
-- Hugh




Follow-Ups: