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
