[Haskell-cafe] Re: [darcs-conflicts] how to nicely implement phantom type coersion?
On 12/8/05, David Roundy [EMAIL PROTECTED] wrote: So is there some other approach that I can use for easily coercing phantom types based on runtime checks? Any suggestions? None here. Since H-M uses type unification to do type inference, you can't auto-create a program based on the inferred types around it. -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-conflicts] how to nicely implement phantom type coersion?
On Thu, Dec 08, 2005 at 09:23:22AM -0500, David Roundy wrote:
data EqContext a b = EqContext { safe_coerce :: f(a,b) - f(b,a) }
where f(a,b) is a function of two types that returns a type, so the value
of f(a,b) might be (Patch a b) or (Patch x b) or something like that.
But I'm not sure if this is possible in Haskell, and if it is, then it
definitely requires some sort of tricky extension that I'm not familiar
with...
I'm a bit confused, but if you have:
sc :: p a b - p a c
sc = unsafeCoerce#
then (with Either standing in for Patch, PatchList etc and some concrete
types as parameters to simplify things)
sc (undefined :: Either Int Char) :: Either Int Bool
is well-typed but
sc (undefined :: Either Int Char) :: Either String Char
isn't. Is that what you want?
Thanks
Ian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-conflicts] how to nicely implement phantom type coersion?
Ralf Hinze wrote: the type a :=: b defined below goes back to Leibniz's principle of substituting equals for equals: If you like this, check out two of Ralf's papers: First-class phantom types: http://techreports.library.cornell.edu:8081/Dienst/UI/1.0/Display/cul.cis/TR2003-1901 Fun with phantom types: http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf The first (in section 2.4) explains a limitation of :=: I highly recommend both papers. Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
