> 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.brob...@gmail.com> wrote: > On Mon, Aug 22, 2011 at 10:05 AM, Max Bolingbroke > <batterseapo...@hotmail.com> wrote: >> >> On 21 August 2011 21:03, Alexey Khudyakov <alexey.sklad...@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 <co...@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@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users