ArchiveOrangemail archive

Haskell' - A Haskell Standard Revision - discussion list


haskell-prime.haskell.org
(List home) (Recent threads) (40 other Haskell lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 3,923 messages, beginning Jan 2006
  • 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

Wanted: local data, class, instance declarations

Ad
Johannes Waldmann 1138337984Fri, 27 Jan 2006 04:59:44 +0000 (UTC)
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/l...
This is exactly a work-around for not being able
to make local dictionaries, right?

Best regards,
Bulat Ziganshin 1138613240Mon, 30 Jan 2006 09:27:20 +0000 (UTC)
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
Manuel M T Chakravarty 1138831023Wed, 01 Feb 2006 21:57:03 +0000 (UTC)
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/l...
> This is exactly a work-around for not being able
> to make local dictionaries, right?
> 
> Best regards,
John Meacham 1138831320Wed, 01 Feb 2006 22:02:00 +0000 (UTC)
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
Bulat Ziganshin 1138869315Thu, 02 Feb 2006 08:35:15 +0000 (UTC)
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?
John Meacham 1138872269Thu, 02 Feb 2006 09:24:29 +0000 (UTC)
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
Home | About | Privacy