Wanted: local data, class, instance declarations
in today's Haskell, all data and instance declarations are global, which sometimes leads to violations of the information hiding principle. E. g. if there is a function sort :: Ord a => [a] -> [a], and I want to sort a list of items w.r.t. a specified ordering, then I would want to write let instance Ord Item where ... xs :: [ Item ] ; xs = ... in sort xs but I don't want to make the instance Ord Item global because I might need a different instance in another place, or there already is a global instance but I don't want it. So, the local instance should override an outer or global one. Shouldn't be too difficult, the compiler just has to insert the proper dictionary (the "most local" one that's visible at the call site). With current all-global instances, a sort function of the given type is not very flexible, leading to supplementary functions (sortBy), see "Generalized functions" e. g. in http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#22 This is exactly a work-around for not being able to make local dictionaries, right? Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Hello Johannes, Friday, January 27, 2006, 1:00:42 PM, you wrote: JW> let instance Ord Item where ... JW> xs :: [ Item ] ; xs = ... JW> in sort xs are you familiar with generic haskell? one of its features is the local definitions of the special cases for generic functions, what is close to what you propose -- Best regards, Bulat mailto:bulatz@HotPOP.com
Unfortunately, local instance declarations threaten the coherence property of type classes and principle types. See for example, ``Functional pearl: implicit configurations—or, type classes reflect the values of types'', Sect 6.1, for a bit of discussion. So, this extension would require a very carefully thought out proposal. Manuel Johannes Waldmann:
in today's Haskell, all data and instance declarations are global, which sometimes leads to violations of the information hiding principle.
E. g. if there is a function sort :: Ord a => [a] -> [a], and I want to sort a list of items w.r.t. a specified ordering, then I would want to write
let instance Ord Item where ... xs :: [ Item ] ; xs = ... in sort xs
but I don't want to make the instance Ord Item global because I might need a different instance in another place, or there already is a global instance but I don't want it. So, the local instance should override an outer or global one. Shouldn't be too difficult, the compiler just has to insert the proper dictionary (the "most local" one that's visible at the call site).
With current all-global instances, a sort function of the given type is not very flexible, leading to supplementary functions (sortBy), see "Generalized functions" e. g. in http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#22 This is exactly a work-around for not being able to make local dictionaries, right?
Best regards,
On Wed, Feb 01, 2006 at 09:58:15PM -0500, Manuel M T Chakravarty wrote:
Unfortunately, local instance declarations threaten the coherence property of type classes and principle types. See for example, ``Functional pearl: implicit configurations—or, type classes reflect the values of types'', Sect 6.1, for a bit of discussion.
So, this extension would require a very carefully thought out proposal.
Also, the need for it is questionable if we were to allow polymorphic components and newtype deriving. if your data acts differently then it should be a different type with a newtype and derive all the properties where it acts the same. if you want to do different things to the same data then packaging them up as values in a record with polymorphic components makes perfect sense and is more functional in nature. That class instances are global is a great feature of them, not a weakness. John -- John Meacham - ⑆repetae.net⑆john⑈
Hello John, Thursday, February 02, 2006, 6:03:06 AM, you wrote:
Unfortunately, local instance declarations threaten the coherence property of type classes and principle types. See for example, ``Functional pearl: implicit configurations—or, type classes reflect the values of types'', Sect 6.1, for a bit of discussion.
So, this extension would require a very carefully thought out proposal.
JM> Also, the need for it is questionable if we were to allow polymorphic JM> components and newtype deriving. if your data acts differently then it JM> should be a different type with a newtype and derive all the properties JM> where it acts the same. if you want to do different things to the same JM> data then packaging them up as values in a record with polymorphic JM> components makes perfect sense and is more functional in nature. That JM> class instances are global is a great feature of them, not a weakness. John, local definitions used in Generic Haskell (which you may don't know) and even in the SYB. are you really think that if we need two different algorithms of processing Identifier inside folds, then we should define two different Identifier types? -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Thu, Feb 02, 2006 at 03:34:57PM +0300, Bulat Ziganshin wrote:
JM> Also, the need for it is questionable if we were to allow polymorphic JM> components and newtype deriving. if your data acts differently then it JM> should be a different type with a newtype and derive all the properties JM> where it acts the same. if you want to do different things to the same JM> data then packaging them up as values in a record with polymorphic JM> components makes perfect sense and is more functional in nature. That JM> class instances are global is a great feature of them, not a weakness.
John, local definitions used in Generic Haskell (which you may don't know) and even in the SYB. are you really think that if we need two different algorithms of processing Identifier inside folds, then we should define two different Identifier types?
hmm? no. that is why I said if you want to do different related things to the same data then higher order functions packaged with polymorphic components is the way to go. In any case, the gist wasn't so much don't implement something as much as please don't break the current class global scope invarients in the process. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (4)
-
Bulat Ziganshin -
Johannes Waldmann -
John Meacham -
Manuel M T Chakravarty