No subject
Fri Sep 2 19:57:00 CEST 2011
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, fa=
r
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 explici=
t
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 fo=
r
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 i=
s
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=F6m Dureg=E5rd 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 ca=
n
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
--0016364ee420e213fd04ac06d87e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 10:05 AM, Max Bolingbroke <span dir=3D"ltr"><<a =
href=3D"mailto:batterseapower at hotmail.com">batterseapower at hotmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 21 August 2011 21:03, Alexey Khudyakov <<a href=3D"=
mailto:alexey.skladnoy at gmail.com">alexey.skladnoy at gmail.com</a>> wrote:<=
br>
> I don't completely understant how does it work. Does client need t=
o enable<br>
> language extension to get default instances?<br>
<br>
</div>I think that the extension would only be required to *define them*,<b=
r>
not for them to be generated. The more conservative choice would<br>
indeed be to require the extension for both, though.<br>
</blockquote><div><br></div><div>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 "conserva=
tive" choice, while I would like to call it the "only sensible&qu=
ot; choice.</div>
<div><br></div><div>1. In particular: adhering to this principle makes it m=
uch much easier to achieve consistency between different compilers and tool=
s 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 i=
f GHC will always have the proper context available, it is by no means cert=
ain that other tools will. In this particular instance, it is certainly not=
inconceivable or even improbable that tools other than compilers might wan=
t to analyse a module containing instance declarations, without knowing a p=
riori that some default superclass instances are assumed. Having a flag alw=
ays makes this clear.</div>
<div><br></div><div>(As an example, GHC already breaks this principle in (a=
t least) one instance - MPTC when used as contexts - which creates problems=
for haskell-src-exts).=20
=A0</div><div><br></div><div>2. If you are worried about breakage of legacy=
code, you can always achieve silent enabling by having a flag and having i=
t on by default. Then GHC can declare that it, by default, compiles a Haske=
ll extension and not the standard. This could still create problems when pr=
ogrammers 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 i=
n client code (with the appropriate -XNo... flag). </div>
<div><br></div><div>From a principle point of view this is still not a perf=
ect solution, and I would prefer that an explicit flag was always needed (u=
nless and until the extension is adopted in the proper Haskell' revisio=
n). I realise this would break a lot of code though, and having a flag enab=
led by default is far, far better than not using a flag at all.</div>
<div><br></div><div>3. I must admit I don't fully see how client code c=
an 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 chan=
ge - are you really suggesting that we enable new syntax without the need t=
o declare what language (i.e. extensions) the file uses? Of course, there i=
s 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 c=
ase like to voice my very strong opinion against such a choice.</div>
<div><br></div><div><br></div><div>That said - I definitely like the genera=
l idea of default superclass instances, I think the proposed extension is v=
ery elegant and fixes a definite wart. But please let's not introduce o=
ther problems by adopting it!</div>
<div><br></div><div>To be concrete, I propose the following named extension=
s (exact names up for bike-shed discussion):</div><div><br></div><div>* Def=
aultSuperInstances: Enables the full SHE-bang (pun fully intended), includi=
ng in particular the syntactic additions in class and instance declarations=
.</div>
<div>* SilentDefaultSuperInstances: Enables ONLY the possibility for client=
code to use inherited default instances. This extension is subsumed by Def=
aultSuperInstances (except for error/warning behavior discussed below), jus=
t like RankNTypes subsumes Rank2Types.</div>
<div><br></div><div>I further propose that GHC enables SilentDefaultSuperIn=
stances by default, as a pragmatic choice to avoid legacy issues, but not D=
efaultSuperInstances. </div><div><br></div><div>If (only) SilentDefaultSupe=
rInstances is enabled, I propose that Option 2 is used. It makes perfect se=
nse 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.</div>
<div><br></div><div>
<br>2011/9/2 Conor McBride <span dir=3D"ltr"><<a href=3D"mailto:conor at st=
rictlypositive.org">conor at strictlypositive.org</a>></span><br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
<div class=3D"im">On 2 Sep 2011, at 18:19, Jonas Almstr=F6m Dureg=E5rd wrot=
e: =A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">=
The recent discussion concerns whether option 2 should eventually be<br>
shifted to option 1. Everyone seems to agree that option 2 should be<br>
used initially.<br>
</div></blockquote><div>=A0</div><div>With my proposal this discussion beco=
mes moot. SilentDefaultSuperInstances effects option 2, DefaultSuperInstanc=
es effects option 1. The discussion can then instead turn to whether or not=
DefaultSuperInstances should be adopted in Haskell', and (only) at tha=
t point there will be an automatic switch to option 1.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;">
A similar warning should perhaps indicate that a "hiding" clause =
has<br>
nothing to hide, as Jonas suggests.<br>
</blockquote><div><br></div><div>Yes, I agree with this.</div><div>=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;">I'm in favour of Option 2 now and Opti=
on 1 later, where "later" has<br>
non-disruptiveness criteria attached. A bit like being in favour of<br>
the pound now and the euro later.<br></blockquote><div><br></div><div>... a=
nd the proper transition process from one to the other is the Haskell' =
process.</div><div><br></div><div>What sayeth ye all?</div><div><br></div>
<div>Cheers,</div><div><br></div><div>/Niklas</div></div>
--0016364ee420e213fd04ac06d87e--
More information about the Glasgow-haskell-users
mailing list