#2110: Rules to eliminate casted id's
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: feature request | Status: new
Priority: lowest | Milestone: 7.6.2
Component: Compiler | Version: 6.8.2
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by nomeata):
I find that I disagree. Consider a library that uses newtypes to hide the
implementation:
{{{
newtype Nat = Nat { natToInteger :: Integer }
safeNat x = if x >= 0 then Nat x else error "negative"
...more operations on nat...
}}}
now the user of the library has a value ```l :: [Nat]``` around, but wants
to go back to Integers. The natural way of doing it is ```map natToInteger
l```. And I find it reasonable to have the compiler (with the help of the
library writer) to optimize that to a cast.
The programmer cannot be the one to have to think about it, because he
might not even know that Nat ist but a newtype. (Although it might be
documented somewhere, so he might be expecting zero-overhead over Ints,
and hence expecting the map to be free.)
With my proposition, the burdon of writing the rule is not even with the
library author, but the author of the data structure, in this case the
list. I find it reasonable to expect him to worry about such things, it is
no less tricky than using RULES for list fusion.
If I read your suggestion in comment:23 correctly, you want to introduce a
type cast operator to the Haskell syntax that checked whether the types
really have the same representation? Might also be useful, but isn’t this
risky? We would not want the user to be able to write
{{{
let x :: Map Int = ....
y = x |> Map (Down Int)
}}}
would we? How would that be prevented?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2110#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
