Haskell Typeclasses

[Alex Martelli]

Kay Schluehr <kay.schluehr at gmx.net> wrote:
   ...
> > typeclass mapping:
> >   def __getitem__(self, key):
> >     _notthere=[]
> >     result = self.get(key, _notthere)
> >     if result is notthere: raise KeyError
> >     return result
> >   def get(self, key, default):
> >     try: return self[key]
> >     except KeyError: return default
> >   # etc etc
   ...
> 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.

> 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.  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.

> By the way I also don't understand Guidos concerns. Maybe he is against
> the whole idea of creating frameworks and partial implementations? It's
> not very clear for what reasons he likes interfaces. 

Just read his blog on artima -- and maybe, if something there is unclear
to you, comment about it to see if you can get him interested in
explaining better.


Alex