Random thoughts about typeclasses

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Random thoughts about typeclasses

Robert Clausecker
Hello!

I found out, that GHC implements typeclasses as an extra argument, a
record that stores all functions of the typeclass. So I was wondering,
is there a way (apart from using newtype) to pass a custom record as the
typeclass record, to modify the behavior of the typeclass? I thought
about something like this:

    f :: Show a => [a] -> String
    f = (>>= show)

    -- So, f becomes something like this?
    __f :: ClassShow a -> [a] -> String
    __f (ClassShow __show) x = x >>= __show

    -- And if I call the function, it looks somewhat like this:
    g :: [Int] -> String
    g = f

    __g = __f instanceShowInt

    -- But is it possible to do something like this?
    g2 = __f (ClassShow (return . fromEnum))

Tis is just a random thought, some compilers like JHC implement them by
another way. But would this theoretically be possible?

Yours, FUZxxl


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Random thoughts about typeclasses

Ertugrul Söylemez
Robert Clausecker <[hidden email]> wrote:

> I found out, that GHC implements typeclasses as an extra argument, a
> record that stores all functions of the typeclass. So I was wondering,
> is there a way (apart from using newtype) to pass a custom record as
> the typeclass record, to modify the behavior of the typeclass? I
> thought about something like this:
>
>     f :: Show a => [a] -> String
>     f = (>>= show)
>
>     -- So, f becomes something like this?
>     __f :: ClassShow a -> [a] -> String
>     __f (ClassShow __show) x = x >>= __show
>
>     -- And if I call the function, it looks somewhat like this:
>     g :: [Int] -> String
>     g = f
>
>     __g = __f instanceShowInt
>
>     -- But is it possible to do something like this?
>     g2 = __f (ClassShow (return . fromEnum))
>
> Tis is just a random thought, some compilers like JHC implement them
> by another way. But would this theoretically be possible?

If I understand you right, you would like to decide about the instance
at run-time instead of at compile-time.  This is actually possible in
practice.  A suitable search term is "implicit configurations", in
particular "reification".


Greets,
Ertugrul


--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Random thoughts about typeclasses

Casey McCann
In reply to this post by Robert Clausecker
On Mon, May 16, 2011 at 8:10 AM, Robert Clausecker <[hidden email]> wrote:
> I found out, that GHC implements typeclasses as an extra argument, a
> record that stores all functions of the typeclass. So I was wondering,
> is there a way (apart from using newtype) to pass a custom record as the
> typeclass record, to modify the behavior of the typeclass? I thought
> about something like this:

Would GHC's implicit parameter extension possibly suit your purposes
here? Your example would translate as:

    {-# LANGUAGE ImplicitParams #-}

    type ShowClass a = a -> String

    f :: (?showC :: ShowClass a) => [a] -> String
    f x = x >>= ?showC

    g :: [Int] -> String
    g = let ?showC = show in f

    g2 :: [Int] -> String
    g2 = let ?showC = (return . toEnum) in f

...where:

    > g [72, 97, 115, 107, 101, 108, 108]
    "7297115107101108108"
    > g2 [72, 97, 115, 107, 101, 108, 108]
    "Haskell"

Clearly this doesn't allow you retrofit such functionality onto
existing code using existing type classes, but I'd be wary of doing
that anyway--type class instances are not something that code will
expect to have changing out from under it. Otherwise, this seems to be
exactly what the implicit parameters extension is designed for,
judging from the way the GHC user's guide describes it.

- C.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Random thoughts about typeclasses

Dominique Devriese-2
In reply to this post by Robert Clausecker
Robert,

2011/5/16 Robert Clausecker <[hidden email]>:
> I found out, that GHC implements typeclasses as an extra argument, a
> record that stores all functions of the typeclass. So I was wondering,
> is there a way (apart from using newtype) to pass a custom record as the
> typeclass record, to modify the behavior of the typeclass? I thought
> about something like this:

You may be interested in Agda's upcoming "instance arguments"
(inspired upon Scala implicits and Agda's implicit arguments). These
will be available in Agda 2.2.12 (you may find references to an older
name "non-canonical implicit arguments"). The new type of function
arguments are automatically inferred from call-site scope unless they
are explicitly provided. Type classes are directly (not just under the
hood) modelled as records, and you can do what you suggest. You can
also define "local instances", and there are other advantages. We have
chosen a more limited-power instance search though. More discussion
online.

  http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.InstanceArguments
  http://people.cs.kuleuven.be/~dominique.devriese/agda-instance-arguments/

I believe a similar Haskell extension (perhaps with a less principled
instance search) would improve and simplify Haskell's type class
system.

By the way, Kahl and Scheffczyk proposed extending Haskell with "named
instances" in 2001 which allowed something like this to a limited
extent. Look for "Named instances for Haskell Type Classes" in Google
Scholar.

Dominique

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe