On 11/2/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
Hello Malcolm,Thursday, November 2, 2006, 12:46:43 AM, you wrote:> instance Num (Bar z) where> and> instance Num (Bar z)> The former declares that _no_ methods are defined (except for defaults),
> and the latter, with your proposal, tha
On Wed, Nov 01, 2006 at 03:51:57PM -0800, John Meacham wrote:
> On Wed, Nov 01, 2006 at 03:15:38PM -0600, Brian Smith wrote:
> > Instance hiding is an important feature in its own right.
>
> selective importing and exporting of instances is a really tricky
> technical issue for a lot of reasons, a
Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> > import M1 hiding (instance C T)
>
> i vote for this feature too.
> also, expicit instance imports was in prewvious Haskell versions.
I'm fairly confident that Haskell has never historically permitted the
explicit import and export of instances. It
Hello Malcolm,
Thursday, November 2, 2006, 12:46:43 AM, you wrote:
> instance Num (Bar z) where
> and
> instance Num (Bar z)
> The former declares that _no_ methods are defined (except for defaults),
> and the latter, with your proposal, that _all_ methods are defined. The
i join to th
Hello Brian,
Thursday, November 2, 2006, 12:15:38 AM, you wrote:
> In particular, I think having features like :
> import M1 hiding (instance C T)
> and
> module M hiding (instance C T)
> would eliminate the need for special-case handling of derived
> instances (if two imported modules h
On Wed, Nov 01, 2006 at 03:15:38PM -0600, Brian Smith wrote:
> How an instance is defined (explicitly or derived) should have nothing to do
> with how it is imported/exported in a module.
>
> In particular, I think having features like :
> import M1 hiding (instance C T)
> and
>module M hi
On 11/1/06, Malcolm Wallace <[EMAIL PROTECTED]> wrote:
"Brian Smith" <[EMAIL PROTECTED]> writes:> > http://haskell.org/haskellwiki/GHC/StandAloneDeriving
>> Basically, the syntax> for instances and derived instances would be identical, but derived> instances would just omit the "where" clau
"Brian Smith" <[EMAIL PROTECTED]> writes:
> > http://haskell.org/haskellwiki/GHC/StandAloneDeriving
>
> Basically, the syntax
> for instances and derived instances would be identical, but derived
> instances would just omit the "where" clause, while non-derived instances
> would need the
On 11/1/06, Ross Paterson <[EMAIL PROTECTED]> wrote:
On Wed, Nov 01, 2006 at 12:30:31PM -0600, Brian Smith wrote:In response to your point about duplicate derived instances, yes, itwould make derived instances different from explicit ones, but as I'veargued before, I think it's unavoidable:
http://
| > I think it is difficult to discuss things via a Wiki.
|
| Yes, a mailing list is much better for discussion.
I agree. But the Wiki is an excellent place to specify alternative
designs, and summarise their advantages and disadvantages. Otherwise
alternative designs can get lost in the twist
On Wed, Nov 01, 2006 at 12:30:31PM -0600, Brian Smith wrote:
> I think it is difficult to discuss things via a Wiki.
Yes, a mailing list is much better for discussion.
In response to your point about duplicate derived instances, yes, it
would make derived instances different from explicit ones, b
On 11/1/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
The thread about "stand-alone" deriving is long-ish now, so I have summarised the issues here:
http://haskell.org/haskellwiki/GHC/StandAloneDeriving
I think it is difficult to discuss things via a Wiki. I tried to add my comments to
--Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| John Meacham
| Sent: 30 October 2006 05:17
| To: haskell-prime@haskell.org
| Subject: Re: Proposal for stand-alone deriving declarations?
|
| On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrot
On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrote:
> On 10/6/06, John Hughes <[EMAIL PROTECTED]> wrote:
> >deriving (Eq Foo, Ord Foo)
> >
> >instead of
> >
> >deriving (Eq, Ord) for Foo
>
> So what does
>
> newtype Foo a = Foo a
> newtype Bar b = Bar b
> class C a b
> deriving (C (F
On Mon, Oct 09, 2006 at 01:19:38PM +0100, Simon Peyton-Jones wrote:
> | > I propose to add a top-level declaration on the form:
> | >
> | > 'deriving' qtycls 'for' qtycon
> | >
> | > which produces the same instance as a deriving clause in the
> | > declaration of the datatype or newtype would.
> |
On Thu, Oct 05, 2006 at 08:58:28PM +0200, Bjorn Bringert wrote:
> - When deriving instances of multi-parameter type classes (again non-
> standard), the newtype for which the deriving is made must be the
> last argument to the class. If the syntax were "deriving (Class
> T1 ... Tn)", it might
| > I propose to add a top-level declaration on the form:
| >
| > 'deriving' qtycls 'for' qtycon
| >
| > which produces the same instance as a deriving clause in the
| > declaration of the datatype or newtype would.
|
| If this is added (whatever the syntax), you'd also want to permit
multiple
| i
On 8 okt 2006, at 20.11, Brian Smith wrote:
On 10/8/06, Bjorn Bringert
<[EMAIL PROTECTED]> wrote:
I agree that "derive" would be nicer, but as you say, the problem is
that it would add a new keyword. Since the declaration would then
start with "derive", I don't that think it could easily be made
On 10/8/06, Bjorn Bringert <[EMAIL PROTECTED]> wrote:
I agree that "derive" would be nicer, but as you say, the problem isthat it would add a new keyword. Since the declaration would thenstart with "derive", I don't that think it could easily be made into
a special identifier. A deriving declaratio
On 8 okt 2006, at 18.22, Brian Smith wrote:
On 10/6/06, Björn Bringert <[EMAIL PROTECTED]> wrote:
John Hughes wrote:
> deriving (Eq Foo, Ord Foo)
>
> instead of
>
> deriving (Eq, Ord) for Foo
>
> I find the former syntax clearer and more readable, actually.
>
> John
I'll implement this syntax
On 10/6/06, Björn Bringert <[EMAIL PROTECTED]> wrote:
John Hughes wrote:> deriving (Eq Foo, Ord Foo)>> instead of>> deriving (Eq, Ord) for Foo>> I find the former syntax clearer and more readable, actually.>> John
I'll implement this syntax instead and then write up a Haskell' proposal.I am sure th
On 7 okt 2006, at 16.44, Twan van Laarhoven wrote:
The main use for this seems to be when a module defining a data type
lacks an instance you want, and for some reason you can't get the
original module changed.
If you continue this line of reasoning:
1. The only reason a module can not be ch
The main use for this seems to be when a module defining a data type
lacks an instance you want, and for some reason you can't get the
original module changed.
If you continue this line of reasoning:
1. The only reason a module can not be changed is that it is in some
library as opposed to y
On Thu, Oct 05, 2006 at 10:05:20AM +0200, Bjorn Bringert wrote:
> I propose to add a top-level declaration on the form:
>
> 'deriving' qtycls 'for' qtycon
>
> which produces the same instance as a deriving clause in the
> declaration of the datatype or newtype would.
If this is added (whatever
On 10/6/06, John Hughes <[EMAIL PROTECTED]> wrote:
deriving (Eq Foo, Ord Foo)
instead of
deriving (Eq, Ord) for Foo
So what does
newtype Foo a = Foo a
newtype Bar b = Bar b
class C a b
deriving (C (Foo a) (Bar b))
mean? I could see it meaning any or all of the following:
instance (C (Foo
John Hughes wrote:
What I implemented in GHC is an extension of the proposal below. The
proposal just mentions:
deriving Class for Type
In GHC I also added a form for newtype deriving of multi-parameter
type classes:
deriving (Class t1 ... tn) for Type
I think that it's c
Ketil Malde wrote:
"Iavor Diatchki" <[EMAIL PROTECTED]> writes:
A question about the syntax: would there be a problem if we made the
'deriving' declaration look like an instance?
And you might as well keep the 'instance' keyword when instantiating,
even if the instance is derived? Seems mor
"Iavor Diatchki" <[EMAIL PROTECTED]> writes:
> A question about the syntax: would there be a problem if we made the
> 'deriving' declaration look like an instance?
And you might as well keep the 'instance' keyword when instantiating,
even if the instance is derived? Seems more consistent to me
What I implemented in GHC is an extension of the proposal below. The
proposal just mentions:
deriving Class for Type
In GHC I also added a form for newtype deriving of multi-parameter
type classes:
deriving (Class t1 ... tn) for Type
I think that it's close to what we ende
Off-list, Greg Fitzgerald pointed out that:
Those wanting to use the SYB library may want to write something
like this for every datatype in their heirarchy:
deriving Data, Typable for Person, Team, Department, Company
That seems like a useful extension to me, and the meaning is obvious.
We considered that syntax, but decided against it. Stand-alone
deriving declarations are made to be as similar as possible to the
current deriving mechanism, rather than be similar to instance
declarations. The basic reason for maintaining a syntactic
distinction between instance declaratio
Hello,
A question about the syntax: would there be a problem if we made the
'deriving' declaration look like an instance? Then we would not need
the special identifier 'for', and also we have a more standard looking
notation. I am thinking something like:
deriving Show SomeType
deriving Eq (Ano
Simon Peyton-Jones wrote:
| What is not so nice is that you take a new keyword ('for'), which is
| quite likely to have been used as a variable name in existing code.
(Or
| does it work out to use one of the 'special' names here?)
The latter is what Bjorn has done. That is, 'for' is only specia
| What is not so nice is that you take a new keyword ('for'), which is
| quite likely to have been used as a variable name in existing code.
(Or
| does it work out to use one of the 'special' names here?)
The latter is what Bjorn has done. That is, 'for' is only special in
this one context. You
half Of
| Bjorn Bringert
| Sent: 05 October 2006 09:05
| To: haskell-prime@haskell.org
| Subject: Proposal for stand-alone deriving declarations?
|
| On http://hackage.haskell.org/trac/haskell-prime/wiki/
| DerivedInstances it says:
|
| "- There is no way to derive an instance of a class for
Bjorn Bringert:
> On http://hackage.haskell.org/trac/haskell-prime/wiki/
> DerivedInstances it says:
>
> "- There is no way to derive an instance of a class for a data type
> that is defined elsewhere (in another module)."
>
> Though there is no proposal to fix this. Would such a proposal be
: Proposal for stand-alone deriving declarations?
|
| On http://hackage.haskell.org/trac/haskell-prime/wiki/
| DerivedInstances it says:
|
| "- There is no way to derive an instance of a class for a data type
| that is defined elsewhere (in another module)."
|
| Though there is no proposal t
On http://hackage.haskell.org/trac/haskell-prime/wiki/
DerivedInstances it says:
"- There is no way to derive an instance of a class for a data type
that is defined elsewhere (in another module)."
Though there is no proposal to fix this. Would such a proposal be
appropriate for Haskell'?
38 matches
Mail list logo
