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

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

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:lemming@henning-thielemann.de] Sent: Thursday, July 12, 2007 11:44 AM To: peterv Cc: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] Functional dependencies *not* part of the next Haskell standard? On Thu, 12 Jul 2007, peterv wrote: 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.

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

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:Bulat.Ziganshin@gmail.com

...

...

| 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_e...

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: tom.schrijvers@cs.kuleuven.be

2007/7/12, peterv :

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

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:Bulat.Ziganshin@gmail.com

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...

D.V. wrote:

On 7/12/07, Andrew Coppin 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. ;-)

Alexis Hazell wrote:

On Saturday 14 July 2007 05:21, Andrew Coppin wrote:

...

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.)

Well, how about this as a starting point (from a post i wrote in my blog):

"[In Haskell,] a monad simply seems to be a computational environment in which one can specify that certain types and methods of computation be performed, and in which the three monad laws are expected to hold."

What do people think?

Hmm... it doesn't leave me with either a strong sense of "oh, that sounds simple" or "oh, I understand what that means". I'm only one guy of course...

With regards to the last phrase, i seem to recall that there are monads which nevertheless actually /don't/ follow all three monad laws?

That is my recollection also. (Don't ask me *which* monads, mind you...) In the case in point, the law breakage never the less matches "intuition"; personally, I ignore the monad laws on the basis that if you're doing something "sane", the laws will automatically hold anyway. (But maybe I'm just a renegade?)

Hugh Perkins wrote:

On 7/14/07, *Andrew Coppin*

...

That is my recollection also. (Don't ask me *which* monads, mind you...) In the case in point, the law breakage never the less matches "intuition"; personally, I ignore the monad laws on the basis that if you're doing something "sane", the laws will automatically hold anyway. (But maybe I'm just a renegade?)

Yeah, the laws confused me for a while as well. Hint to guys writing Haskell documentation, we're not all doing CS phD you know ;-) We just want to get things done ;-)

Andrew, I found comfort and explanation in this article http://www.haskell.org/haskellwiki/Monads_as_containers :

"The functions return and bind need to satisfy a few laws http://www.nomaware.com/monads/html/laws.html#laws in order to make a monad, but if you define them in a sensible way given what they are supposed to do, the laws will work out. The laws are only a formal way to give the informal description of the meanings of return and bind I have here."

Oh, I *understand* the laws - I just think that if you're trying to explain how to *use* (not *write*) monads, you really don't need to emphasize this "laws" business. IMHO...

Well, can you provide an example of an implementation of bind that satisfies an intuitive definition of bind but does not satisfy the monad laws? On 7/14/07, Derek Elkins wrote:

-Documentation- damn well better have the monad laws. Something is not a monad if it does not satisfy the monad laws. Furthermore, the monad laws are almost the only thing that -does- define monads.

Yeah, the laws confused me for a while as well. Hint to guys writing Haskell documentation, we're not all doing CS phD you know ;-) We just want to get things done ;-)

teachers and tutorials making a fuss about some concept is the surest way to guarantee that learners will find that concept difficult (holds for Monads, functional i/o, Monad laws, Turing machines, higher order functions, and many other things [*]). the Monad type class tells you the interface (what operations you've got, and their types), the Monad laws tell you what all types implementing that interface should have in common. it is all just about getting things done!-) the monadic interface gives you two operations, one to throw things into a monad thing, and one to chain two monad things together. the monad laws tell you two useful facts about monad things thrown together in that way: whatever it is the monad does, anything just thrown into it will take no part in that action, and whichever way you use that chaining operation, the structure of chaining is irrelevant, only the ordering of chained monad things matters. hth?-) claus [*] digging out the original paper can often be surprisingly enlightening, in the algol way of the original being an improvement on all its successors. [**] "thing" is a technical term that would take too long to explain, closely related to those "apples" mentioned in another thread;-)

On Fri, 2007-07-13 at 15:08 +0200, D.V. wrote:

On 7/12/07, Andrew Coppin 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.

Agreed. More strongly, the main problem with monads nowadays is that there are gazillions of -bad- tutorials and only a few decent ones. Back in the day, when there were only a few tutorials, the main problem was people generalizing to quickly from particular instances. Those people went on to write monad tutorials. I think I'll make a "not monad" tutorial about what monads are not.

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:Bulat.Ziganshin@gmail.com