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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
| 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 |
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 |
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 |
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 |
>>> | 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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |