The example for GHC Generics is kinda broken
From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgenerics_example/:
The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b.
However, consider a :+: b :+: c.
If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1.
If it's a :+: (b :+: c), then a is 0, b is 10, c is 11.
The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later.
The manual, at http://hackage.haskell.org/package/generic-deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does.
I think this is a valid concern, and the manual should be at least updated to discuss this problem.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |
Activity
added Tbug Trac import documentation labels
Yes; certainly if the way the compiler nests sums in the automatic derivation of
Genericinstances changes, or if the user is giving their own instances, there is no guarantee that the serialisation outcome is the same. I could perhaps add a note to the example in the manual to highlight the fact that it doesn't try to work across different versions of the compiler. Updating the example to deal with different nestings would be overkill, I think.changed milestone to %7.10.1
changed milestone to %8.0.1
Trac metadata
Trac field Value Differential revisions - → D3782 mentioned in commit 88f20bdb
changed milestone to %8.4.1
added Pnormal label
