Lambda the Ultimate

The point wasn't to decide how to *extend* the language, but rather to discover to what extent *removing* an extension would hurt common idioms, and what possible (ideally, more tractable) features could replace that extension.

This is sort of like regression testing against hackage, but for language features rather than API changes.

I have a problem in my code which I would like to solve with overlapping instances (...)

...and then you'd have two problems!

Seriously though, if it's not too far off topic, what is it you hoped to accomplish with overlapping instances? Usually that's only necessary for heavy duty type-level metaprogramming, and if you're talking about HaskellForMaths I don't immediately see where it would need that kind of stuff.

Personally, I tend to view overlapping instances as an irredeemably bad idea that is, regrettably, as yet the only way to implement certain useful things in GHC-flavored Haskell. So I'm curious how other people feel about the extension.

... was the following.

An algebra is a vector space which is also a ring (plus some additional conditions). Many algebras arise from a basis which is a monoid. For example, the algebra of commutative polynomials arises from the monoid of commutative monomials; the group algebra arises from a group (which is a monoid). However, not all algebras are of this form, for example the complex numbers as an algebra over the reals (because i^2 = -1, not 1).

So the overlapping instances are:
- That I want to say that whenever the basis is a monoid, we have the monoid algebra. Something like:
instance (Fractional k, Monoid m) => Algebra k m where ...
- But I also want to say, for some specific bases which are not monoids, that they give rise to an algebra. For example:
data CBasis = Re | Im
instance Algebra Double CBasis where ...

It seems to me that in maths, overlapping instances are probably all over the place, just because we tend to define structures at a level of abstraction for which there are many different ways to provide concrete instances.

(Another example that springs immediately to mind is (finite) projective planes. Given any (finite) field k, then PG2(k) is a projective plane, which leads to a family of instances. However, there are also more anomalous non-desarguesian planes, which may require case by case construction of the instances.)

Ah, I see. In the general case, though, would overlapping instances even work anyway? It won't help when there's no unambiguous instance. For example, at least four plausible instances of Monoid exist for something like Float.

Something to disambiguate is necessary; the standard libraries tend to use newtype wrappers, which aren't ideal but get the job done. Could you do something similar, e.g.:
instance (Fractional k, Monoid m) => Algebra k (MonoidWrapper m) where ..., perhaps? I'm not sure what would be useful, since I unfortunately don't really know much about the maths in question (despite the fact that just today I was writing something closely related... and probably making a complete hash of it).

The example you gave, though, is the usual sort of "want to select an instance based on class membership of parameters" thing, which is one place where using overlapping instances is particularly grating--since typically, the instances shouldn't actually overlap (e.g., CBasis isn't an instance of Monoid), and if they do it's likely to be a bug. Ugh.

Suspect compared to what? The alternative method that I know is to drive language design decisions by divine inspiration.