> 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
> sugge
On Mon, Aug 22, 2011 at 10:05 AM, Max Bolingbroke <
batterseapo...@hotmail.com> wrote:
> On 21 August 2011 21:03, Alexey Khudyakov
> 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 extens
gård
> | Sent: 02 September 2011 16:50
> | To: Conor McBride
> | Cc: GHC users
> | Subject: Re: Superclass defaults
> |
> | > The question then comes down to whether that warning should ever be
> | > strengthened to an error.
> |
> | Indeed.
> |
> | > I agree th
16:50
| To: Conor McBride
| Cc: GHC users
| Subject: Re: Superclass defaults
|
| > The question then comes down to whether that warning should ever be
| > strengthened to an error.
|
| Indeed.
|
| > I agree that such a scenario is possible. The present situation gives
| > no choice bu
ll-users-
| boun...@haskell.org] On Behalf Of Jonas Almström Duregård
| Sent: 02 September 2011 16:50
| To: Conor McBride
| Cc: GHC users
| Subject: Re: Superclass defaults
|
| > The question then comes down to whether that warning should
ever be
| > strengthened to an error.
|
| Indeed.
|
|
Hi
On 2 Sep 2011, at 16:34, Brandon Allbery wrote:
I hope I am misunderstanding this
I wrote:
I agree that such a scenario is possible. The present situation gives
no choice but to do things badly, but things often get done badly the
first time around anyway. Perhaps I'm just grumpy, bu
> The question then comes down to whether that warning should ever be
> strengthened to an error.
Indeed.
> I agree that such a scenario is possible. The present situation gives
> no choice but to do things badly, but things often get done badly the
> first time around anyway. Perhaps I'm just gr
;> future, but I'm not as optimistic about that.
>>
>> Even when superclass defaults are implemented, people will
>> occasionally implement classes without realizing that there is a
>> suitable intrinsic superclass (or add the superclass but not the
>> default i
ore precision,
one way or another.
Also, if I understand you correctly, you say the current situation is
exceptional, and suggest option 2 as a temporary solution to it. You
seem convinced that these kind of situations will not appear in the
future, but I'm not as optimistic about that.
Eve
esign goal, but
like you say the design goal might be at fault.
Also, if I understand you correctly, you say the current situation is
exceptional, and suggest option 2 as a temporary solution to it. You
seem convinced that these kind of situations will not appear in the
future, but I'm not as opt
On Wed, Aug 31, 2011 at 4:21 PM, Simon Peyton-Jones
wrote:
> There seems to be a lot of support for Option 3... but what about Option 2
> (ie pre-empt but give a warning)?
I notice that the idea to only issue a warning if the explicit and
implicit instances are in different modules was already h
Hi
Sorry to be late again...I'm trying to have what's laughably described
as a holiday, but it seems more like the common cold to me.
On 31 Aug 2011, at 08:52, Jonas Almström Duregård wrote:
| > There seems to be a lot of support for Option 3... but what about
Option 2 (ie pre-empt but give a
;
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org
> [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Sebastian Fischer
> | Sent: 30 August 2011 03:49
> | To: Bas van Dijk
> | Cc: glasgow-haskell-users@haskell.org; Simon Pey
ginal Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Sebastian Fischer
| Sent: 30 August 2011 03:49
| To: Bas van Dijk
| Cc: glasgow-haskell-users@haskell.org; Simon Peyton-Jones
| Subject: Re: Superclass defaults
|
| On
I was thinking about the design of superclass default instances. I
think that we can get relatively far using the following extensions
together:
1) Multiple instance declarations
instance (Functor[a], Monad [a])
where
fmap = map
(>>=) = flip concatMap
return = (:[])
-- Declaration
On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk wrote:
> Won't option 1 "Reject this as a duplicate instance declaration, which
> indeed it is." conflict with design goal 1: "a class C can be
> re-factored into a class C with a superclass S, without disturbing any
> clients"?
If yes, I prefer opti
gt; "Variations" we discuss the "silent-opt-out" choice. But it's bad enough
>> knowing exactly what instances are in scope (given that they are not named),
>> let alone having that control what further instances are or are not
>> generated! For supercla
On 29 August 2011 11:11, Aleksey Khudyakov wrote:
>> "Option 3 avoids that problem but risks perplexity: if I make use of
>> some cool package which introduces some Foo :: * -> *, I might notice
>> that Foo is a monad and add a Monad Foo instance in my own code,
>> expecting the Applicative Foo in
> "Option 3 avoids that problem but risks perplexity: if I make use of
> some cool package which introduces some Foo :: * -> *, I might notice
> that Foo is a monad and add a Monad Foo instance in my own code,
> expecting the Applicative Foo instance to be generated in concert; to
> my horror, I fi
t Conor and I proposed. See
> http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances. Under
> "Variations" we discuss the "silent-opt-out" choice. But it's bad enough
> knowing exactly what instances are in scope (given that they are not nam
uot; choice. But it's bad enough
knowing exactly what instances are in scope (given that they are not named),
let alone having that control what further instances are or are not generated!
For superclass defaults there is no such ambiguity.
Simon
On 21 August 2011 21:03, Alexey Khudyakov 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 choi
On 15.08.2011 14:36, Simon Peyton-Jones wrote:
With help from Conor we have made some progress on this: we have a draft design:
http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
If you care about the issue, maybe you can help resolve the above questions. In
particular,
On 8/15/11 7:44 AM, Conor McBride wrote:
This is a recurring issue, at least as far as mailing list heat is
concerned, but it would be good to have more evidence of substantial
impact. The Monoid vs Semigroup issue is a case in point, perhaps.
Folks, what do you think?
For my work it'd certainl
On 8/15/11 7:44 AM, Conor McBride wrote:
On 15 Aug 2011, at 11:36, Simon Peyton-Jones wrote:
But, concerning proposed extensions to GHC about class
aliases/superclass defaults etc, the truth is that the biggest reason
for inertia here at GHC HQ is not so much the implementation effort
(athough
>
> My only input is that we have at least 2-3 (depending on whether the
> latter two are to be considered separate) hierarchies in want of
> refactoring: Functor/Applicative/Monad, Num and friends, and Monoid.
> Ideally any solution would "solve the problem" for all of them, but
> even if it doesn
oon, or not? And how soon is
> | soon?
>
> Not soon enough to be useful for this mappend question.
>
> But, concerning proposed extensions to GHC about class aliases/superclass
> defaults etc, the truth is that the biggest reason for inertia here at GHC HQ
> is not so
class aliases/
superclass defaults etc, the truth is that the biggest reason for
inertia here at GHC HQ is not so much the implementation effort
(athough that is always an issue). Rather, it's uncertainty about
(a) Is there a reasonably large group of users who really want such
a change?
| > If someone felt able to act as moderator for the discussion, willing
| > to summarise conclusions, open questions, and so on, on the wiki
| > page, that would be enormously helpful.
|
| I'm up for that role, if that's appropriate.
I'll take you up on that, thank you! I've added some "SLPJ n
ning proposed extensions to GHC about class aliases/superclass
defaults etc, the truth is that the biggest reason for inertia here at GHC HQ
is not so much the implementation effort (athough that is always an issue).
Rather, it's uncertainty about
(a) Is there a reasonably large group of
30 matches
Mail list logo
