>As far as I can tell, there seems to be no agreement on what is
>meant by "subtyping", and whether this implies some kind of object
>system with inheiritance, something like the typeclass-based approach
>of ML-family languages, or some other approach to generic programming.
...
>I do hope that, in discussing Scheme types, we consider the research
>that has been done in the field of type theory, and don't limit the
>discussion to ideas drawn from the OOP community.  Typeclasses[1],
>in particular, have proven to be a very successful approach, in
>other languages, to generalizing operations across various types.

Yes, the ML-style typeclass is more along the lines what I was thinking, not necessarily Java-style interfaces. I figure typeclasses would be more suitable given their success in other functional languages.

However, I can see some difficulty in unifying a typeclass-like generic dispatch with the traditional Lisp values of being extensible and redefinable on the fly, since as far as I am aware all of these have the method declarations in one syntactic construct (`impl` for Rust, `instance` for Haskell, etc).

For example, I would personally appreciate being able to redefine one of the methods for a typeclass instance from the REPL, without having to re-type or copy in the whole instance declaration.

I was considering doing a sort of namespacing for generic functions, which would allow for the redefinition at any time. Something like this, perhaps?

```
; Implemented typeclass methods are a list at operator position, not an identifier
(define-method ((fmap <functor>) f (l <list>))
  (map f l))
```

It's a tiny change from the usual CLOS-style generic methods, but I think it's a natural one. IMHO, separating each method would allow for typeclasses to coexist peacefully with the Lisp philosophy.

>> I think this issue can be sidestepped by instead dispatching over
>> predicates
>
>Comparators provide a simple version of this idea, restricted to
>types which can be meaningfully compared for equality, ordered, or
>hashed.  The approach used by SRFI 128--bundling sets of procedures
>and dispatching based on type predicates--is easy to generalize

Agreed. Essentially, that's what I'm aiming for here, with some fancy syntax. We can use identifier properties to store the implementations with the type predicate or the record type identifier, off the top of my head.

The only thing I would want to work on here would be unifying these constructs with generic functions. I can see multiple dispatch with this being a killer feature, if we can hash out exactly how it would work. :)
--
Sent from my Android device with K-9 Mail.