Hello how about this old proposal? http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, Apr 04, 2006 at 11:06:59AM +0400, Bulat Ziganshin wrote:
how about this old proposal?
http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html (Making 'deriving' a separate declaration instead of a clause)
Orphan instances are discouraged in the GHC libraries, so there might not be much support for adding a feature designed to permit orphan derived instances.
Hello Ross, Tuesday, April 4, 2006, 4:55:09 PM, you wrote:
http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html (Making 'deriving' a separate declaration instead of a clause)
Orphan instances are discouraged in the GHC libraries, so there might not be much support for adding a feature designed to permit orphan derived instances.
sorry, i don't understand how them are discouraged? GHC can't support this because of it's internal limits? i think you mean some other thing but i can't understand you -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tuesday 04 April 2006 14:55, Ross Paterson wrote:
On Tue, Apr 04, 2006 at 11:06:59AM +0400, Bulat Ziganshin wrote:
how about this old proposal?
http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html
(Making 'deriving' a separate declaration instead of a clause)
Orphan instances are discouraged in the GHC libraries, so there might not be much support for adding a feature designed to permit orphan derived instances.
However, it would help programmers a lot, specialy library users. And it would lift some of the burden that is currently on the library writer to never forget to derive all possibly useful instances for public data types. Ben
Benjamin Franksen wrote:
However, it would help programmers a lot, specialy library users. And it would lift some of the burden that is currently on the library writer to never forget to derive all possibly useful instances for public data types.
If you allow 'deriving' in other modules it can violate the 'privacy' of modules. For example (if these instances were not declared):
deriving Data.Map.Map (Show)
Now I can look at what map nodes look like.
deriving Data.Map.Map (Data)
Now I can even mess with the internal structure, violating invariants. Twan
On Tuesday 04 April 2006 18:46, you wrote:
Benjamin Franksen wrote:
However, it would help programmers a lot, specialy library users. And it would lift some of the burden that is currently on the library writer to never forget to derive all possibly useful instances for public data types.
If you allow 'deriving' in other modules it can violate the 'privacy' of modules. For example (if these instances were not declared): deriving Data.Map.Map (Show)
Now I can look at what map nodes look like.
deriving Data.Map.Map (Data)
Now I can even mess with the internal structure, violating invariants.
Ouch! This would be bad. Hmm... not all exported data types are abstract. I guess we could allow it for data types with no hidden constructors, but then maybe it is not quite as useful as I thought... Ben
On Apr 4, 2006, at 12:46 PM, Twan van Laarhoven wrote:
Benjamin Franksen wrote:
However, it would help programmers a lot, specialy library users. And it would lift some of the burden that is currently on the library writer to never forget to derive all possibly useful instances for public data types.
If you allow 'deriving' in other modules it can violate the 'privacy' of modules. For example (if these instances were not declared):
deriving Data.Map.Map (Show)
Now I can look at what map nodes look like.
deriving Data.Map.Map (Data)
Now I can even mess with the internal structure, violating invariants.
The obvious solution is to allow out-of-defining-module deriving only for data types where all constructors are exported. Presumably, if someone explicitly hid (at least some of) the constructors of a data type, they did it for a reason and we can hope that they carefully considered the external interface of that type (including instances). Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
On Tue, Apr 04, 2006 at 01:13:32PM -0400, Robert Dockins wrote:
The obvious solution is to allow out-of-defining-module deriving only for data types where all constructors are exported. Presumably, if someone explicitly hid (at least some of) the constructors of a data type, they did it for a reason and we can hope that they carefully considered the external interface of that type (including instances).
indeed, that is actually a requirement of the original proposal. John -- John Meacham - ⑆repetae.net⑆john⑈
Hello John, Wednesday, April 5, 2006, 12:02:16 AM, you wrote:
The obvious solution is to allow out-of-defining-module deriving only for data types where all constructors are exported. Presumably, if someone explicitly hid (at least some of) the constructors of a data type, they did it for a reason and we can hope that they carefully considered the external interface of that type (including instances).
indeed, that is actually a requirement of the original proposal.
i can agree with it with one additional requirement to library writers - provide "internal" modules that export data definitions. without this, it's a big problem to add new functionality with optimal performance. for example, to add Binary instance for Data.Map, the only way is to use fromList/toList functions, what is not the fastest method (i still not tested whether TH provide access to structure of abstract types :) ) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Tue, Apr 04, 2006 at 01:55:09PM +0100, Ross Paterson wrote:
Orphan instances are discouraged in the GHC libraries, so there might not be much support for adding a feature designed to permit orphan derived instances.
This reminds me of something I was thinking about the other day, would overlapping instances be okay if orphan instances were disallowed on them? My reasoning is that in order to use any instance the data constructor must be in scope, therefore all revelant instances are. A simple rule like "for classes declared as overlapping, when declaring instances either the class definition must appear in the current module, or the data constructor at the head of the instance must be declared in the current module" the point would be to solve the unacceptable "importing a module might silently change behavior" problem with general overlapping instances John -- John Meacham - ⑆repetae.net⑆john⑈
participants (6)
-
Benjamin Franksen -
Bulat Ziganshin -
John Meacham -
Robert Dockins -
Ross Paterson -
Twan van Laarhoven