Home > Archive > Scheme > November 2005 > Thant Tessman's Generic Functions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Thant Tessman's Generic Functions
|
|
| MSCHAEF.COM 2005-11-08, 6:59 pm |
| Has anybody reading this had much experience with Thant Tessman's
implementation of generic functions in Scheme? A paper describing
the system is available here:
http://www.standarddeviance.com/p45-tessman.pdf
Reading through the paper, it looks like a fairly simple and
understandable approach. My only concern is that maintaining
the database of subtype relationships seems like a fertile ground
for tricky, hard to diagnose errors. For those readers that
have used this in practice, has this been a real issue or not?
Thanks,
Mike
--
http://www.mschaef.com
| |
| Thant Tessman 2005-11-09, 7:01 pm |
| MSCHAEF.COM wrote:
> [...] My only concern is that maintaining
> the database of subtype relationships seems like a fertile ground
> for tricky, hard to diagnose errors. For those readers that
> have used this in practice, has this been a real issue or not?
Thanks for the kind words. I wanted to mention that it is expected (but
not required) that the declaration of subtype relationships be automated
as a part of whatever object system(s) you are using. In our system, the
act of declaring that a structure inherits from some other structure
automatically calls the 'is-a' function to notify the
multimethod-dispatch database of the subtype relationship.
So in theory, if your inheritance graph is deep and messy, then yes, it
can become a fertile ground for errors. But this is true for OO designs
in general. A point I should make that I didn't make in the paper is
that things can become genuinely ambiguous in the presence of multiple
inheritance. At least the dispatcher will signal an error if you declare
a circular set of subtype relationships (which are almost always a
serious design flaw).
Having said all that, in practice our inheritance graphs were shallow
and we never had a problem.
Hope this helps,
-thant
--
"That's not a good way to determine how good or bad things are, by
how many things are exploding." -- Lawrence DiRita, chief spokesman
for the United States Defense Department
| |
| MSCHAEF.COM 2005-11-10, 9:09 am |
| In article <dkt75t$q9t$1@news.xmission.com>,
Thant Tessman <adm@standarddeviance.com> wrote:
...
>Thanks for the kind words. I wanted to mention that it is expected (but
>not required) that the declaration of subtype relationships be automated
>as a part of whatever object system(s) you are using.
That's actually part of of the same problem that drew me to your paper in
the first place. I've been experimenting a little with 'classless'
objects, similar to those in NewtonScript, Self, and JavaScript, so there
really is no formal point at which subtype relationships are declared.
Multi methods that dispatch based on predicates seem like a reasonable
way to get multi methods without too much mechanism.
I guess I really ought to be reading more about Cecil, but your paper
seems like a good approach, given the limited amount of time I have to
commit to this.
>Having said all that, in practice our inheritance graphs were shallow
>and we never had a problem.
That was what I was hoping to hear. :-)
It also seems like it might be possible to define a debug mode that checks
the predicates for consistancy. That is, if you say
(is-a 'even? 'number?)
In 'debug mode' every time the system evaluates even?, it'd also evaluate
number? to verify that the is-a relatinship held. Slow, but maybe
useful... I don't really know.
>Hope this helps,
It does, very much. Thanks for your time.
-Mike
--
http://www.mschaef.com
|
|
|
|
|