Superclass defaults

[Jonas Almström Duregård]

> What sayeth ye all?

I approve of your suggestion. Well said!

> 3. I must admit I don't fully see how client code can be kept from the need
> to enable the extension. In particular, if client code must use the explicit
> opt-out, this is a rather obvious syntactic change - are you really
> suggesting that we enable new syntax without the need to declare what
> language (i.e. extensions) the file uses?

I can only speak for myself, but I believe the intention was never to
allow the syntactic changes without a flag. The only part that I
understood to be be flag-less is exactly the extension you call
SilentDefaultSuperInstances.

Now about the names...

I suggest IntrinsicInstanceDeclarations for the auto-enabled
extension, and just IntrinsicSuperclasses for the larger extension.

Regards,
Jonas


On 3 September 2011 12:21, Niklas Broberg <niklas.broberg at gmail.com> wrote:
> 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).
> From a principle point of view this is still not a perfect solution, and I
> would prefer that an explicit flag was always needed (unless and until the
> extension is adopted in the proper Haskell' revision). I realise this would
> break a lot of code though, and having a flag enabled by default is far, far
> better than not using a flag at all.
> 3. I must admit I don't fully see how client code can be kept from the need
> to enable the extension. In particular, if client code must use the explicit
> opt-out, this is a rather obvious syntactic change - are you really
> suggesting that we enable new syntax without the need to declare what
> language (i.e. extensions) the file uses? Of course, there is precedent for
> such a move with the ugly MPTCs-in-contexts mentioned above - a precedent
> that I would very much like to see revoked. I would in any case like to
> voice my very strong opinion against such a choice.
>
> That said - I definitely like the general idea of default superclass
> instances, I think the proposed extension is very elegant and fixes a
> definite wart. But please let's not introduce other problems by adopting it!
> To be concrete, I propose the following named extensions (exact names up for
> bike-shed discussion):
> * DefaultSuperInstances: Enables the full SHE-bang (pun fully intended),
> including in particular the syntactic additions in class and instance
> declarations.
> * SilentDefaultSuperInstances: Enables ONLY the possibility for client code
> to use inherited default instances. This extension is subsumed by
> DefaultSuperInstances (except for error/warning behavior discussed below),
> just like RankNTypes subsumes Rank2Types.
> I further propose that GHC enables SilentDefaultSuperInstances by default,
> as a pragmatic choice to avoid legacy issues, but not DefaultSuperInstances.
> If (only) SilentDefaultSuperInstances is enabled, I propose that Option 2 is
> used. It makes perfect sense to warn if you override a default instance,
> just like it is sensible to warn about name shadowing. Option 3 strikes me
> as strictly worse. However, if DefaultSuperInstances is enabled (which must
> then be done explicitly), I propose that Option 1 is used instead.
>
> 2011/9/2 Conor McBride <conor at strictlypositive.org>
>>
>> On 2 Sep 2011, at 18:19, Jonas Almström Duregård wrote:
>>
>> The recent discussion concerns whether option 2 should eventually be
>> shifted to option 1. Everyone seems to agree that option 2 should be
>> used initially.
>
>
> With my proposal this discussion becomes moot. SilentDefaultSuperInstances
> effects option 2, DefaultSuperInstances effects option 1. The discussion can
> then instead turn to whether or not DefaultSuperInstances should be adopted
> in Haskell', and (only) at that point there will be an automatic switch to
> option 1.
>>
>> A similar warning should perhaps indicate that a "hiding" clause has
>> nothing to hide, as Jonas suggests.
>
> Yes, I agree with this.
>
>>
>> I'm in favour of Option 2 now and Option 1 later, where "later" has
>> non-disruptiveness criteria attached. A bit like being in favour of
>> the pound now and the euro later.
>
> ... and the proper transition process from one to the other is the Haskell'
> process.
> What sayeth ye all?
> Cheers,
> /Niklas
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>