On 2021-07-31 20:11, John Cowan wrote:
> 1) Since you have a hierarchy of predicates, if you redefine a
> predicate at the REPL you break the hierarchy.  For this reason,
> fast-generics[*] associates each predicate in the hierarchy with a
> type, represented as a symbol.  You add a new type with a define-type
> macro that takes a predicate, a new symbol for it, and the symbol for
> the parent predicate it is subsumed by.
>
> Adding the idea of independent hierarchies to the fast-generics design
> also has the advantage that you can construct and use hierarchies of
> symbols without reference to predicates and generic functions; in this
> way, creating a parent-child relationship between symbols is detached
> from associating those symbols with predicates.

Hmmm. I see what you mean. This is a good idea.

One thing I noticed about Clojure's multimethods (which I blatantly
stole
the hierarchy idea from, btw) is that a dispatch function is provided
that has
fine-grained control over what method is dispatched to. By default I
believe
it uses a list of keywords that represent the types. Maybe that is
something
we can borrow as well?

> 2) I think that it is much more important to have defining macros, as
> in CL and fast-generics, than to have defining procedures.  Macros can
> provide a great deal of optimization.  In particular, the
> define-generic macro of fast-generics (which should be called
> define-method) can, if all its arguments are constant, actually
> construct a function at compile time that effectively unrolls type
> testing for you, rather than running what amounts to an interpreter
> across a list of type signatures and methods.  The latter is still
> possible, of course.

> But your various reflection procedures make that kind of efficiency
> impossible.  Providing generic? means that a generic function cannot
> be a procedure, as the only thing you can portably do with a procedure
> is to call it.  By not distinguishing between procedures and generic
> functions, there is no problem whether the body of the GF is compiled
> or interpreted: its interface is still that of a procedure.  The same
> thing is true of method? and reflective procedures on methods: after
> compilation there is no Scheme object corresponding to a method.

I think that the reflection procedures are useful for building
abstractions on
top of the generic procedure system, and I would hate to see them go.

In particular, I can see implementing a Go-like structural 'interface'
type/predicate that responds `#t` if a set of generics are implemented
for that type. That possibility goes away if we can't look inside a
generic to see what sort of values it is specialized on. Maybe we could
do something similar
and provide a symbol->generic-procedure lookup table, sort of like what
we can do
with the procedures above? Or would that still necessarily cause
problems if we do
*any* sort of reflection? Or maybe we can simply wait for later SRFIs to
provide an
even better method of specifying groups of procedures that implement an
interface?

> 3) You don't specify how method resolution is done when there are
> multiple arguments.  The two alternatives AFAIK are strict
> left-to-right precedence and symmetric multimatching, in which all
> arguments are considered regardless of order.  I favor the first
> because it is simpler and easier to understand, even if it sometimes
> returns the "wrong" answer.

I agree and that's what I was thinking when I wrote it. I will make this
clear in the
document.

>
> [*] See
> <https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.1025&rep=rep1&type=pdf>
> for the original paper (the implementation described there has been
> superseded), <http://wiki.call-cc.org/eggref/5/fast-generic> for the
> Chicken wrapper around the portable implementation, and
> <https://gazette.call-cc.org/issues/14.html#omelette-recipes> for
> examples of its use.

I will definitely take a look at this, though my macro-fu may not be
developed enough
to understand it fully.

Thanks for the response!

--

Ben Davenport-Ray