Superclass defaults

On Mon, Aug 22, 2011 at 10:05 AM, Max Bolingbroke <
batterseapower at hotmail.com> wrote:
> On 21 August 2011 21:03, Alexey Khudyakov <alexey.skladnoy at gmail.com>
> wrote:
> > I don't completely understant how does it work. Does client need to
> enable
> > language extension to get default instances?
>> I think that the extension would only be required to *define them*,
> not for them to be generated. The more conservative choice would
> indeed be to require the extension for both, though.
>
Please allow me to voice my not-so-humble opinion that, as a rigid
principle, any extension is ALWAYS enabled with a flag, and never enabled
silently. This is what Max calls the "conservative" choice, while I would
like to call it the "only sensible" choice.
1. In particular: adhering to this principle makes it much much easier to
achieve consistency between different compilers and tools working with
Haskell code. GHC is currently in so strong a position as to make its own
laws, but with great power comes great responsibility. Even if GHC will
always have the proper context available, it is by no means certain that
other tools will. In this particular instance, it is certainly not
inconceivable or even improbable that tools other than compilers might want
to analyse a module containing instance declarations, without knowing a
priori that some default superclass instances are assumed. Having a flag
always makes this clear.
(As an example, GHC already breaks this principle in (at least) one instance
- MPTC when used as contexts - which creates problems for haskell-src-exts).
2. If you are worried about breakage of legacy code, you can always achieve
silent enabling by having a flag and having it on by default. Then GHC can
declare that it, by default, compiles a Haskell extension and not the
standard. This could still create problems when programmers expect other
tools to work on their GHC-specific files, but then at least we have a clear
story and can put blame where blame is due (on GHC). Other tools can then
also opt to enable the same extensions by default, or by flag. Also, it
would make it possible to explicitly remove the flag in client code (with
the appropriate -XNo... flag).