# Talk:Typeclassopedia

### From HaskellWiki

(→Link not working anymore: new section) |
(respond to comment re: functor law exercise) |
||

(3 intermediate revisions by 2 users not shown) | |||

Line 57: | Line 57: | ||

In 6.5: "Cale Gibbard’s article on how to use monad transformers" | In 6.5: "Cale Gibbard’s article on how to use monad transformers" | ||

gives a 404. Is it still available somewhere? | gives a 404. Is it still available somewhere? | ||

+ | |||

+ | == The use of the ~> type operator will break with GHC 7.6 == | ||

+ | |||

+ | In GHC 7.6.1 (Release Candidate 1), the TypeOperators extension has changed, so this will no longer work (in [http://www.haskell.org/haskellwiki/Typeclassopedia#Category §12 Category]): | ||

+ | |||

+ | <haskell> | ||

+ | class Category (~>) where | ||

+ | id :: a ~> a | ||

+ | (.) :: (b ~> c) -> (a ~> b) -> (a ~> c) | ||

+ | </haskell> | ||

+ | |||

+ | More precisely, all type operators are now constructors, rather than variables. Put another way: the parser treats type operators as "capitalized". | ||

+ | |||

+ | See the discussion [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021611.html on the mailing list] and [http://www.reddit.com/r/haskell/comments/y3vzd/ghc_761_release_candidate_1/c5s7uat on Reddit]. | ||

+ | |||

+ | == Functor laws == | ||

+ | |||

+ | Is there an error in exercise 1 in section 3.3? | ||

+ | <blockquote>"Although it is not possible for a Functor instance to satisfy the first Functor law but not the second, the reverse is possible. Give an example of a (bogus) Functor instance which satisfies the second law but not the first."</blockquote> | ||

+ | I think it is the other way around, i.e. '''can''' satisfy the first (fmap id = id) without satisfying the second. See e.g. https://stackoverflow.com/a/8323243 | ||

+ | -- [[User:Arno|Arno]] ([[User talk:Arno|talk]]) 21:30, 12 August 2014 (UTC) | ||

+ | |||

+ | It is certainly not the other way around; read the other comments in that thread. However, that comment does show that it is not technically true that the first law implies the second, IF we consider seq/undefined. I had not realized this before. I updated the discussion of the functor laws with some additional links and a clarifying note. | ||

+ | |||

+ | -- [[User:Byorgey|Byorgey]] ([[User talk:Byorgey|talk]]) 17:47, 18 August 2014 (UTC) |

## Latest revision as of 17:47, 18 August 2014

## Contents |

## [edit] 1 Adding Exercises

I'd like to add a bunch of explicit, typographically distinguished exercises to the text. For example, the Haskell wikibook typesets exercises in a centered box. I don't know a lot about wiki markup -- does anyone have ideas on a good way to do this?

Byorgey 16:09, 26 November 2011 (UTC)

https://en.wikibooks.org/wiki/Template:Exercises If you look at the source, it doesn't seem too complicated to copy over - only calls 1 or 2 other templates an those may not be important. --Gwern 16:20, 26 November 2011 (UTC)

That works great, thanks! Byorgey 17:34, 26 November 2011 (UTC)

## [edit] 2 §6.4 Other monoidal classes

This section states that instances of Alternative/MonadPlus/ArrowPlus are sometimes the same as the Monoid instance, and sometimes different. It would be helpful (imo) if it was explained why this is: whether it would be better if instances of Alternative/MonadPlus/ArrowPlus were the same as the Monoid instance, and that sometimes they are not due to accidents of history; or whether sometimes these instances should be different, and giving guidance as to when those times are.

--Dave4420 17:16, 26 November 2011 (UTC)

Hmm, where does it say that? Byorgey 17:40, 26 November 2011 (UTC)

Search forA simple example of a--Dave4420 09:54, 27 November 2011 (UTC)`MonadPlus`

instance is`[]`

, which is exactly the same as the`Monoid`

instance for`[]`

: the empty list represents failure, and list concatenation represents choice. In general, however, a`MonadPlus`

instance for a type need not be the same as its`Monoid`

instance;`Maybe`

is an example of such a type.

- Ah, I see now. I think it's mostly due to history. Many of these types could have many different
`Monoid`

instances. I'll put in some additional discussion. --Byorgey 03:44, 28 November 2011 (UTC)

## [edit] 3 References/bibliography

I'm not entirely happy about the situation with citations. Although I like having inline links, a bunch of information is lost by just giving a link rather than a full bibliography entry. I plan to add more citations so just linking to the old .bib file is insufficient. What would be the best way to maintain the actual citation/bibliography info? Is it as easy as copying over some wikipedia citation templates? --Byorgey 18:46, 26 November 2011 (UTC)

## [edit] 4 <code> vs <hask> tags

I'd like to standardize on using <haskell> tags to surround code blocks, but <code> tags to surround inline code. My reasons:

- <hask> tags seem to break a lot of things (e.g. they cannot be used inside links, etc.)
- The formatting with <hask> tags is inconsistent: andMonadare different colors,Applicativedoes not look right, etc. Even if the formatting were&&&
*consistent*it would still be*distracting*: having different sorts of things be different colors helps when reading a code block, because it gives you some visual structure. Having different-colored things in the middle of paragraphs, on the other hand, only serves to distract one's attention when trying to read.

## [edit] 5 Broken sidebar

Typeclassopedia#Further_reading_3 has a broken sidebar and I can't figure out how to fix it. --Dag 02:05, 27 November 2011 (UTC)

- The problem was that the sidebar content contained an = symbol. See [1]. The solution is to either surround each = with double curly braces like {{=}}, or to prefix the content with 1= (like {{note|1=...}}) to treat it as a named rather than anonymous argument to the template. I've also had to watch out for this when typesetting exercises containing things like
`(>>=)`

. --Byorgey 06:25, 27 November 2011 (UTC)

## [edit] 6 Diagram in SVG?

If HaskellWiki has the SVG support properly configured and the diagram exists in SVG form, perhaps replace the PNG and let MediaWiki convert it into PNGs of appropriate sizes on the fly? --Dag 12:10, 27 November 2011 (UTC)

- Hmm, I just tried this and it ended up looking worse. Maybe I was Doing It Wrong? At any rate, an SVG version is now here: [2] so others can play with it if they wish. --Byorgey 03:25, 28 November 2011 (UTC)

- You can specify a width to scale to:
- --Dag 16:37, 28 November 2011 (UTC)

## [edit] 7 Link not working anymore

In 6.5: "Cale Gibbard’s article on how to use monad transformers" gives a 404. Is it still available somewhere?

## [edit] 8 The use of the ~> type operator will break with GHC 7.6

In GHC 7.6.1 (Release Candidate 1), the TypeOperators extension has changed, so this will no longer work (in §12 Category):

class Category (~>) where id :: a ~> a (.) :: (b ~> c) -> (a ~> b) -> (a ~> c)

More precisely, all type operators are now constructors, rather than variables. Put another way: the parser treats type operators as "capitalized".

See the discussion on the mailing list and on Reddit.

## [edit] 9 Functor laws

Is there an error in exercise 1 in section 3.3?

"Although it is not possible for a Functor instance to satisfy the first Functor law but not the second, the reverse is possible. Give an example of a (bogus) Functor instance which satisfies the second law but not the first."

I think it is the other way around, i.e. **can** satisfy the first (fmap id = id) without satisfying the second. See e.g. https://stackoverflow.com/a/8323243
-- Arno (talk) 21:30, 12 August 2014 (UTC)

It is certainly not the other way around; read the other comments in that thread. However, that comment does show that it is not technically true that the first law implies the second, IF we consider seq/undefined. I had not realized this before. I updated the discussion of the functor laws with some additional links and a clarifying note.