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
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
, 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.
Even when superclass defaults are implemented, people will
occasionally implement classes without realizing
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 instance). People will start using the new class and give
separate instances for the superclass, and eventually
in the
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 instance). People will start using the new class
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
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,
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.
|
| I agree that such a scenario is possible
: 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 but to do things badly, but things often get done
| 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 but to do things badly, but things often get done badly
...@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 Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk
-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 Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk@gmail.com wrote:
|
| Won't
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
On Wed, Aug 31, 2011 at 4:21 PM, Simon Peyton-Jones
simo...@microsoft.com 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
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
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 find my
are or are not
generated! For superclass defaults there is no such ambiguity.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Won't option 1 Reject this as a duplicate
On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk@gmail.com 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,
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 superclass defaults there is no such ambiguity.
Simon
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.
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
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
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 note
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
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 much the implementation effort (athough that is always an issue).
Rather, it's uncertainty
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't (and
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
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
This seems to be a frequently requested feature of Haskell: the ability
to declare default members in a superclass for a particular class.
Here's an example:
class Functor f where
fmap :: (a - b) - f a - f b
class (Functor f) = Monad f where
...
The idea is that it should be
On Mon, Jul 21, 2003 at 06:21:33AM -0700, Ashley Yakeley wrote:
Well I don't doubt this would be a very useful extension to the Haskell
language: indeed it would eliminate code in all my Haskell projects. But
before we can propose this, we have to work out what the syntax would
look like.
At 11:14 97/05/22, Koen Claessen wrote:
..[It] already applies at less complex examples, such as the
following:
module A where
class Foo a where
foo :: a - Int
class Foo a = Bar a where
bar :: a - Int
foo = bar
module B where
import A
instance Bar Int
32 matches
Mail list logo
