Haskell Typeclasses

[Kay Schluehr]

Alex Martelli wrote:

> > I don't see why your typeclass illustration does not apply to ABCs as
>
> Because in a class, A or B or not, this code WOULD mean mutual recursion
> (and it can't be checked whether recursion terminates, in general).  In
> a typeclass, it means something very different -- a dependency loop.
> It's easy to check that all loops are broken (just as easy to check that
> all purely abstract methods are implemented) in an adaptation.

I see. The problem is that a class *should* permit mutual recursion in
general while the semantics of a typeclass is different and a typeclass
instance must resolve the dependency loop introduced by the typeclass.

>
> > well? The sanity checks for typeclasses you describe seem to be a
> > particular feature of Haskell or other pure functional languages
> > without destructive updates and messy aliasing problems. It's hardly
> > believable that this would be possible in Python and runtime checks
> > won't help much in this case.
>
> Checks would happen at adapter-registration time, which is runtime: but
> so is the time at which a 'class' or 'def' statement executes, of
> course.  Little but syntax-checks happens at compile-time in Python.
>
> Nevertheless the checks would help enormously, and I don't see why you
> would think otherwise.

I don't think otherwise. I was just asking whether they are feasible.
The typeclass concept itself is very beautiful but it is structural and
I don't see how Python can deal with callgraph structures.

> Prototypes of this (a metaclass performing the
> checks upon inheritance, i.e. non-abstract-subclass creation, but that's
> the same algorithm that could be run at adapter registration time if we
> got rid of the requirement of inheritance in favor of adaptation) have
> been posted to this group years ago.  If a programmer does weird dynamic
> things to a type or an adapter after the checks, fine, they'll get
> exceptions if they later try to call (directly or indirectly) some
> method that's disappeared, or the like, just like they would with ABC's,
> interfaces, inheritance, or whatever else -- very few types are
> dynamically altered in this way in most production programs, anyway, so
> I won't lose any sleep over that possibility.

In case of class instantiation we have inheritance hierarchies
resulting from the actions of metaclasses. But the hierarchy is still a
structural property of a collection of classes i.e. an order on classes
that is exteriour to any of the classes. The mro can alsways be made
explicit. In case of a function call graph that has to be analyzed for
dependencies I don't see that such a simple distinctive scheme could
work. Or maybe it works and I just have no clue how completely opaque
call graphs as they appear in functions like this

def f(x):
     h = g(x)
     h()

can be tracked sufficiently in "register-time" in order to capture
dependencies. It is not clear what h can be unless g is called and it
might be as hard as type-inference or completely impossible to figure
this out without executing g. If otherwise the checker can guarantee
detection of a few obvious cycles where dependencies can be tracked
also syntactically, at least in principle like in your example, what
exactly is ensured by the checker and how can the definition of a
typeclass be adapted accordingly? 

Kay