Functional dependencies *not* part of the next Haskell standard?

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

Functional dependencies *not* part of the next Haskell standard?

bf3
I tried to do something in CAL that I could not solve without functional
dependencies. In their support forum, it got mentioned that func.deps
propably won't make into the next Haskell standard... Any comments on that?

Now, the thing I tried to solve was:

       data Vector2 a = Num a => V2 a a

       class Vector a n | a -> n where
         dot :: a -> a -> n

       instance Num a => Vector (Vector2 a) a where
         dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2

       test1 = dot (V2 1.0 2.0) (V2 3.0 4.0)

Please note this is just some testing code (the math people in here might be
horrified by it ;), although any hints of how to do this in a clearer way
are welcome. As side-note, does Haskell have some easy to use good linear
algebra package for doing 2D, 3D and 4D math? Then I would not be writing
any of this code, although I did find it useful for learning.
 
Now without the funcdep a -> n in the type class declaration I get

    No instance for (Vector (Vector2 t) n)
      arising from use of `dot' at l:/Haskell/test/vector.hs:9:8-36
    Possible fix:
      add an instance declaration for (Vector (Vector2 t) n)
    In the expression: dot (V2 1.0 2.0) (V2 3.0 4.0)
    In the definition of `test1': test1 = dot (V2 1.0 2.0) (V2 3.0 4.0)

CAL seems to have the same problem, and without funcdeps I seem to be stuck
in that language.

PS(1): In the above I was using GHCI with extensions enabled.
PS(2): IMHO CAL is in some aspects easier to get started than Haskell
because of their nice Eclipse plugin and GEM Cutter environment for doing
learning experiments.

Thanks,
Peter


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

Re: Functional dependencies *not* part of the next Haskell standard?

Henning Thielemann

On Thu, 12 Jul 2007, peterv wrote:

> I tried to do something in CAL that I could not solve without functional
> dependencies. In their support forum, it got mentioned that func.deps
> propably won't make into the next Haskell standard... Any comments on that?
>
> Now, the thing I tried to solve was:
>
>        data Vector2 a = Num a => V2 a a
>
>        class Vector a n | a -> n where
>          dot :: a -> a -> n
>
>        instance Num a => Vector (Vector2 a) a where
>          dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2
>
>        test1 = dot (V2 1.0 2.0) (V2 3.0 4.0)


class Vector v where
   dot :: Num a => v a -> v a -> a

instance Vector Vector2 where
   dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2


This will work satisfyingly if you don't plan a larger type class
hierarchy.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Functional dependencies *not* part of the next Haskell standard?

Dave Bayer-2
In reply to this post by bf3
peterv <bf3 <at> telenet.be> writes:

> I tried to do something in CAL that I could not solve without
> functional dependencies. In their support forum, it got mentioned
> that func.deps propably won't make into the next Haskell standard...
> Any comments on that?

Here's a link "CAL for Haskell Programmers" for anyone who wondered
like myself...

http://quarkframework.blogspot.com/2006/09/cal-for-haskell-programmers.html

Functional dependencies were one of the first extensions I found a
need to learn, starting out in Haskell, as part of the crucial
extension "multiparameter type classes" which wouldn't work for me
without functional dependencies.

I then rewrote my code to avoid all of that, something one should
always consider doing. I'd still miss them in principle, and in
practice I'd expect to see them or something better survive in GHC, my
lone axe.

Maybe a certain conservatism in the language standards is ok, and
something better will come along. Wouldn't want people in 2017 seeing
this construct and having it read to them like the word "groovy".

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

RE: Functional dependencies *not* part of the next Haskell standard?

bf3
In reply to this post by Henning Thielemann
> instance Vector Vector2 where
>   dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2

Amazing, so simple it is, Yoda would say ;)

I did not realize one could perform "partial application" on types when
declaring instances (I mean not specifying the type of Vector2 in <instance
Vector Vector2>).

Now regarding these funcdeps, are they "ill" as the "rumor" goes?

Thanks,
Peter

-----Original Message-----
From: Henning Thielemann [mailto:[hidden email]]
Sent: Thursday, July 12, 2007 11:44 AM
To: peterv
Cc: [hidden email]
Subject: Re: [Haskell-cafe] Functional dependencies *not* part of the next
Haskell standard?


On Thu, 12 Jul 2007, peterv wrote:

> I tried to do something in CAL that I could not solve without functional
> dependencies. In their support forum, it got mentioned that func.deps
> propably won't make into the next Haskell standard... Any comments on
that?

>
> Now, the thing I tried to solve was:
>
>        data Vector2 a = Num a => V2 a a
>
>        class Vector a n | a -> n where
>          dot :: a -> a -> n
>
>        instance Num a => Vector (Vector2 a) a where
>          dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2
>
>        test1 = dot (V2 1.0 2.0) (V2 3.0 4.0)


class Vector v where
   dot :: Num a => v a -> v a -> a

instance Vector Vector2 where
   dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2


This will work satisfyingly if you don't plan a larger type class
hierarchy.

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

Re: Functional dependencies *not* part of the next Haskell standard?

Jules Bean
peterv wrote:

>> instance Vector Vector2 where
>>   dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2
>
> Amazing, so simple it is, Yoda would say ;)
>
> I did not realize one could perform "partial application" on types when
> declaring instances (I mean not specifying the type of Vector2 in <instance
> Vector Vector2>).
>
> Now regarding these funcdeps, are they "ill" as the "rumor" goes?

I don't think there is any danger of them being removed and not
replaced. The functionality is useful.

Associated Types is widely viewed as a successor/replacement, but no
complete implementation exists yet:

http://haskell.org/haskellwiki/GHC/Indexed_types

I'm sure FDs are here for a while yet.

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

Re: Functional dependencies *not* part of the next Haskell standard?

Benja Fallenstein
In reply to this post by bf3
2007/7/12, peterv <[hidden email]>:
> Amazing, so simple it is, Yoda would say ;)
>
> I did not realize one could perform "partial application" on types when
> declaring instances (I mean not specifying the type of Vector2 in <instance
> Vector Vector2>).

You ought to meditate on the type class 'Monad,' then, which was the
motivating example for allowing these kinds of classes in standard
Haskell ;-)

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

RE: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

bf3
Thanks for the advice. I did not really deeply investigate the monad type
classes yet...

It looks like its gonna take a long time for me to learn Haskell. I'm not
sure if my long history of imperative and object-oriented programming has
something to do with it. Reading Haskell books like SOE is one thing, but
writing software in Haskell is really difficult for me. Not only do I miss
the "spoiled OO programmer" IDEs with all their candy and code completion
and assistants, but I also get the feeling that although similar programs in
Haskell or typically N times shorter than their imp/OO counterparts, it
would take *me* at least N^2 longer to write them ;) (now I must admit I had
the same feeling when switching from 680x0 assembler to C++, but let's say
N*2 longer instread of N^2...) Is this true for Haskell in general? I mean
how long do experienced Haskell developers spent writing code "to get it
right" (excluding minor bugs and performance issues)? Or do they write down
Haskell fluently?

Regarding those monads, I read a lot of stuff about these beast, trying to
get a high-level understanding about them (and apparently I'm not the only
newby who struggled with that ;), but after having read "You Could Have
Invented Monads!" and then reading
http://research.microsoft.com/~simonpj/papers/marktoberdorf, it all became
much clearer. Those pictures really helped...

Monads were very confusing because I first looked at Concurrent Clean (it
comes with an IDE and games! :), and that language uses a simple "uniqueness
typing" approach where the "world" or "state" is explicitly passed as an
object, and where the compiler garantees "monadic" usage of that object
(warning: that was a lot of fuzzy talk from a newbie trying to look
impressive ;)

-----Original Message-----
From: Benja Fallenstein [mailto:[hidden email]]
Sent: Thursday, July 12, 2007 3:11 PM
To: peterv
Cc: Henning Thielemann; [hidden email]
Subject: Re: [Haskell-cafe] Functional dependencies *not* part of the next
Haskell standard?

2007/7/12, peterv <[hidden email]>:
> Amazing, so simple it is, Yoda would say ;)
>
> I did not realize one could perform "partial application" on types when
> declaring instances (I mean not specifying the type of Vector2 in
<instance
> Vector Vector2>).

You ought to meditate on the type class 'Monad,' then, which was the
motivating example for allowing these kinds of classes in standard
Haskell ;-)

All the best,
- Benja

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

Re[2]: Functional dependencies *not* part of the next Haskell standard?

Bulat Ziganshin-2
In reply to this post by bf3
Hello peterv,

Thursday, July 12, 2007, 5:03:29 PM, you wrote:

> I did not realize one could perform "partial application" on types when
> declaring instances (I mean not specifying the type of Vector2 in <instance
Vector Vector2>>).

this feature, called "constructor classes" was in Haskell since 1.2 or
1.3 version. you can find more info about it here:
http://www.haskell.org/haskellwiki/Research_papers/Type_systems#Type_classes

in particular, i suggest you to read "Type classes: exploring the design space"


--
Best regards,
 Bulat                            mailto:[hidden email]

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

Re[2]: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

Bulat Ziganshin-2
In reply to this post by bf3
Hello peterv,

Thursday, July 12, 2007, 6:01:43 PM, you wrote:

> Monads were very confusing because I first looked at Concurrent Clean (it
> comes with an IDE and games! :), and that language uses a simple "uniqueness
> typing" approach where the "world" or "state" is explicitly passed as an
> object, and where the compiler garantees "monadic" usage of that object

btw, internally most haskell compilers do the same and monad syntax is
just syntax sugar above this. look at http://haskell.org/haskellwiki/IO_inside
to complete the picture. and ST monad does the same too

--
Best regards,
 Bulat                            mailto:[hidden email]

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

RE: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

Derek Elkins
In reply to this post by bf3
On Thu, 2007-07-12 at 16:01 +0200, peterv wrote:

> Thanks for the advice. I did not really deeply investigate the monad type
> classes yet...
>
> It looks like its gonna take a long time for me to learn Haskell. I'm not
> sure if my long history of imperative and object-oriented programming has
> something to do with it. Reading Haskell books like SOE is one thing, but
> writing software in Haskell is really difficult for me. Not only do I miss
> the "spoiled OO programmer" IDEs with all their candy and code completion
> and assistants, but I also get the feeling that although similar programs in
> Haskell or typically N times shorter than their imp/OO counterparts, it
> would take *me* at least N^2 longer to write them ;) (now I must admit I had
> the same feeling when switching from 680x0 assembler to C++, but let's say
> N*2 longer instread of N^2...) Is this true for Haskell in general? I mean
> how long do experienced Haskell developers spent writing code "to get it
> right" (excluding minor bugs and performance issues)? Or do they write down
> Haskell fluently?

Skilled Haskell programmers write Haskell fluently, but I'd say that
that still tends to require more thought per line on average than a
typical imperative language.  A single line of Haskell tends to do a
heck of a lot more than a single line of mainstream imperative
languages.  Usually, though, once you get a nice base encoding your
domain concepts, things move faster.  The more code you write the -less-
thinking you should need to do relative to imperative languages.
Haskell code complexity grows (much) slower with size as compared to
most imperative languages.

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

Re: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

Andrew Coppin
In reply to this post by bf3
peterv wrote:
> It looks like its gonna take a long time for me to learn Haskell. I'm not
> sure if my long history of imperative and object-oriented programming has
> something to do with it. Reading Haskell books like SOE is one thing, but
> writing software in Haskell is really difficult for me.

It takes practice. ;-)

> Not only do I miss
> the "spoiled OO programmer" IDEs with all their candy and code completion
> and assistants

Ah, but in Haskell, you don't need to *write* as much code in the first
place! :-D

> but I also get the feeling that although similar programs in
> Haskell or typically N times shorter than their imp/OO counterparts, it
> would take *me* at least N^2 longer to write them ;)
> Is this true for Haskell in general?

Yeah, Haskell is definitely *not* a language for "hacking away as fast
as your fingers can type without thinking too much". It's more like a
game of chess - you spend a lot of time trying to bend your mind around
the best way to achieve a thing. But then, when you actually start
typing, you often get there faster.

Or realise that the type system is going to stop you... :-/

> Regarding those monads, I read a lot of stuff about these beast, trying to
> get a high-level understanding about them (and apparently I'm not the only
> newby who struggled with that ;), but after having read "You Could Have
> Invented Monads!" and then reading
> http://research.microsoft.com/~simonpj/papers/marktoberdorf, it all became
> much clearer. Those pictures really helped...
>  

Monads take a while to "get used to", but they're not so scary after that...

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

Re: Functional dependencies *not* part of the next Haskell standard?

Donald Bruce Stewart
In reply to this post by Jules Bean
jules:

> peterv wrote:
> >>instance Vector Vector2 where
> >>  dot (V2 x1 y1) (V2 x2 y2) = x1 * x2 + y1 * y2
> >
> >Amazing, so simple it is, Yoda would say ;)
> >
> >I did not realize one could perform "partial application" on types when
> >declaring instances (I mean not specifying the type of Vector2 in <instance
> >Vector Vector2>).
> >
> >Now regarding these funcdeps, are they "ill" as the "rumor" goes?
>
> I don't think there is any danger of them being removed and not
> replaced. The functionality is useful.
>
> Associated Types is widely viewed as a successor/replacement, but no
> complete implementation exists yet:
>
> http://haskell.org/haskellwiki/GHC/Indexed_types

I think the implementation is some 90% complete though, in GHC head.
Certainly you can write many associated types programs already -- the
missing part is finishing off associated type synonyms, iirc.

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

RE: Functional dependencies *not* part of the next Haskell standard?

Simon Peyton Jones
| I think the implementation is some 90% complete though, in GHC head.
| Certainly you can write many associated types programs already -- the
| missing part is finishing off associated type synonyms, iirc.

...and we have a working implementation of that too, thanks to Tom Schrijvers.  It's not in the HEAD yet, but it will be in a few weeks.

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

Re[2]: Functional dependencies *not* part of the next Haskell standard?

Bulat Ziganshin-2
Hello Simon,

Friday, July 13, 2007, 11:37:59 AM, you wrote:

> | I think the implementation is some 90% complete though, in GHC head.
> | Certainly you can write many associated types programs already -- the
> | missing part is finishing off associated type synonyms, iirc.

> ...and we have a working implementation of that too, thanks to Tom
> Schrijvers.  It's not in the HEAD yet, but it will be in a few weeks.

so it will be a part of 6.8? great news! afaiu, ATS, rather than AT,
is direct substitution for FD?


--
Best regards,
 Bulat                            mailto:[hidden email]

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

Re: Functional dependencies *not* part of the next Haskell standard?

Jules Bean
In reply to this post by Simon Peyton Jones
Simon Peyton-Jones wrote:
> | I think the implementation is some 90% complete though, in GHC head.
> | Certainly you can write many associated types programs already -- the
> | missing part is finishing off associated type synonyms, iirc.
>
> ...and we have a working implementation of that too, thanks to Tom Schrijvers.  It's not in the HEAD yet, but it will be in a few weeks.


Excellent news!

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

Re: Functional dependencies *not* part of the next Haskell standard?

Donald Bruce Stewart
In reply to this post by Bulat Ziganshin-2
bulat.ziganshin:

> Hello Simon,
>
> Friday, July 13, 2007, 11:37:59 AM, you wrote:
>
> > | I think the implementation is some 90% complete though, in GHC head.
> > | Certainly you can write many associated types programs already -- the
> > | missing part is finishing off associated type synonyms, iirc.
>
> > ...and we have a working implementation of that too, thanks to Tom
> > Schrijvers.  It's not in the HEAD yet, but it will be in a few weeks.
>
> so it will be a part of 6.8? great news! afaiu, ATS, rather than AT,
> is direct substitution for FD?

Functional dependencies desugar to indexed type families, an extension
of the original associated, in GHC head already. For the full story,
see the wiki page.

    http://haskell.org/haskellwiki/GHC/Indexed_types

which includes an example of porting functional dependencies to
associated types

    http://haskell.org/haskellwiki/GHC/Indexed_types#A_associated_type_synonym_example

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

Re: Functional dependencies *not* part of the next Haskell standard?

Tom Schrijvers-2
>>> | I think the implementation is some 90% complete though, in GHC head.
>>> | Certainly you can write many associated types programs already -- the
>>> | missing part is finishing off associated type synonyms, iirc.
>>
>>> ...and we have a working implementation of that too, thanks to Tom
>>> Schrijvers.  It's not in the HEAD yet, but it will be in a few weeks.
>>
>> so it will be a part of 6.8? great news! afaiu, ATS, rather than AT,
>> is direct substitution for FD?
>
> Functional dependencies desugar to indexed type families, an extension
> of the original associated, in GHC head already. For the full story,
> see the wiki page.
>
>    http://haskell.org/haskellwiki/GHC/Indexed_types
>
> which includes an example of porting functional dependencies to
> associated types
>
>    http://haskell.org/haskellwiki/GHC/Indexed_types#A_associated_type_synonym_example

It's really simple to replace a functional dependency with a type
function.

A class declaration

  class C a b | a -> b

becomes:

  class FD a ~ b => C a b where
           type FD a

and an instance

  instance C [x] x

becomes

  instance C [x] x where
           type FD [x] = x

That's it: only class and instance declarations have to be modified.

Now you can start to drop dependent parameters, if you want.

There are a few examples in my slides as well (if you don't mind
the pptx): http://www.cs.kuleuven.be/~toms/Research/talks/Tyfuns.pptx

Cheers,

Tom

--
Tom Schrijvers

Department of Computer Science
K.U. Leuven
Celestijnenlaan 200A
B-3001 Heverlee
Belgium

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

Re[2]: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

Bulat Ziganshin-2
In reply to this post by bf3
Hello peterv,

Thursday, July 12, 2007, 6:01:43 PM, you wrote:
> Haskell or typically N times shorter than their imp/OO counterparts, it
> would take *me* at least N^2 longer to write them ;) (now I must admit I had
> the same feeling when switching from 680x0 assembler to C++, but let's say
> N*2 longer instread of N^2...) Is this true for Haskell in general?

there is well-known observation that programmer productivity,
measured in lines of code, doesn't depend on the language ;)

the difference between my coding styles in C and Haskell (both fluent,
unlike English ;) is that after i've understood algorithm i want to
implement, i write it immediately in Haskell, and write a tons of
boilerplate code in C

Haskell allows to easily write much more complex algorithms and this
may trick you - you tend to implement more complex algorithms in
Haskell and this, naturally, leads to the fact that you think much
more while programming in Haskell. try to implement algorithm of the
same complexity in C and Haskell and compare processes


--
Best regards,
 Bulat                            mailto:[hidden email]

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

Re: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

David Virebayre
In reply to this post by Andrew Coppin
On 7/12/07, Andrew Coppin <[hidden email]> wrote:

> Monads take a while to "get used to", but they're not so scary after that...

The problem with monads is that there is a gazillion tutorials to
explain them, each with their own analogy that works well for the
author but not necessarily for you.

It adds to the complexity of something that is indeed, not so
difficult after all.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Haskell & monads for newbies (was "Functional dependencies *not* part of the next Haskell standard?")

Andrew Coppin
D.V. wrote:

> On 7/12/07, Andrew Coppin <[hidden email]> wrote:
>
>> Monads take a while to "get used to", but they're not so scary after
>> that...
>
> The problem with monads is that there is a gazillion tutorials to
> explain them, each with their own analogy that works well for the
> author but not necessarily for you.
>
> It adds to the complexity of something that is indeed, not so
> difficult after all.

What was the phrase? "Monads are possibly the most tutorialised concept
ever..."?

Still, while the concept is simple, it's hard to sum up in just a few
words what a monad "is". (Especially given that Haskell has so many
different ones - and they seem superficially to bear no resemblence to
each other.)

Maybe I'll give it a shot some day. ;-)

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