On May 12, 2009, at 6:45 PM, Michele Simionato wrote:
Consider for instance an implementation of (Tiny)CLOS.
AFAIK such implementations are based on side
effects to populate a hash table of functions.
That's just one possibility among many others. There
are also other OO systems that are not CLOS-like and
their implementation would naturally be different.
If I have a module which just imports the base
generic function, and adds multimethods to
it with define-method, without exporting other
variables,
I have seen this "define-method" somewhere before and
was confused by it because it was not actually defining
anything: it was just filling some table. A better
name might have been "add-method!" or something like
that. If it was really a "define-method", then the
method should be defined to have some value and
exported/imported like any other definition.
I wonder if Ikarus would instantiate
that module and populate the generic functions with
the methods, or not, because of the import "lazyness".
If you have to wonder about whether X is guaranteed by
system Y, you can always err on the conservative side,
assume "no", and be explicit about your assumptions.
For example, if you have to ask about whether map applies
the procedure to the elements of the list sequentially
(because, say, the procedure performs some side effects)
it's always safe to define your own "map-sequentially"
procedure that's explicit about evaluation order. Same
principle applies here. Yes, it's not too convenient
some times, maybe, but it pays in the long run to have
your code clearly reflect your intentions (IMHO).
BTW, I think you did implement some version
of TinyCLOS in the past; did your implementation work without
relying on side effects? And how so?
No, it wasn't me. There is some code at
https://launchpad.net/r6rs-clos
which is originally from Xerox and was ported to R6RS
and now maintained by Christian Sloma. I don't know
about the details of how it's implemented, but the
code is there anyways.
Aziz,,,
