> 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
I hope I am misunderstanding this
2011/9/2 Conor McBride
> 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 n
Hi
On 2 Sep 2011, at 10:55, Jonas Almström Duregård wrote:
On 31 August 2011 12:22, Conor McBride
wrote:
I become perplexed very easily. I think we should warn whenever
silent
pre-emption (rather than explicit) hiding is used to suppress a
default
instance, because it is bad --- it makes
Hi,
On 31 August 2011 12:22, Conor McBride wrote:
> I become perplexed very easily. I think we should warn whenever silent
> pre-emption (rather than explicit) hiding is used to suppress a default
> instance, because it is bad --- it makes the meaning of an instance
> declaration rather more cont
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
Hi,
First of all, I love the idea of default superclass instances!
About the opt-out feature, the problem with option 3 is only present
if the superclass instance is defined in another module (you won't see
unexpected behavior from your own instances). One solution is to use
option 3 if the offen
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
On 22 August 2011 10:10, Simon Peyton-Jones 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 m
| > 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 exte
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 t
>
> 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
On Mon, Aug 15, 2011 at 12:36 PM, Simon Peyton-Jones
wrote:
> (Adding GHC users, and changing title.)
>
> | Conor McBride wrote:
> | > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
> | > I don't know if it's likely to be implemented in GHC anytime soon,..
> | > So things are
[resend to GHC users, now I've subscribed!]
Hi Simon
On 15 Aug 2011, at 11:36, Simon Peyton-Jones wrote:
| Nice. But will it be happening soon, 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 alias
| > 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
29 matches
Mail list logo
