Re: Casting dynamic values
27 Nov 2001 17:31:10 -0700, Alastair David Reid [EMAIL PROTECTED] pisze:
If GHC is able to inline these functions, construction and
deconstruction of the pair can probably be eliminated.
cast is compiled to something similar to this:
coerce :: a - b -- this generates no runtime code
type Typeable a = a - TypeRep
cast :: Typeable a - Typeable b - a - Maybe b
cast t1 t2 x =
case t1 x of
rep1 - case t2 (coerce x) of
rep2 - case eqTypeRep rep1 rep2 of
True - Just (coerce x)
False - Nothing
Instances of Typeable should not look at their argument to determine
TypeRep of its type but unfortunately the compiler can't in general
assume that.
But I don't think GHC can do this because AFAIK, GHC will not reduce
literal string comparisions at compile time.
Since Oct 1 it tries to. Unfortunately string literals seem to be
floated out to toplevel before there are recognized as literals being
arguments of (==), and the rule doesn't work.
[This is assuming that GHC's implementation of Typeof still uses
strings. This may not be true though since there was talk of adding
direct compiler support to make the implementation of typeof more
efficient and, more importantly, less prone to programmer error.
It doesn't use strings for comparison but uniquely generated numbers.
But it's not safe either: uniqueness of these numbers relies on TyCon
objects being defined at the toplevel, with {-# NOINLINE #-}, and
I'm not sure if common subexpression elimination doesn't mess this up
(it corrupts similar cases).
Anyway equality on statically known TypeRep is not done at compile
time. I don't know why.
--
__( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^
QRCZAK
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Casting dynamic values
It would occasionally be nice to have a function cast :: (Typeable a,Typeable b) = a - Maybe b which returns Just a if a and b have the same type, and Nothing otherwise. This may seem rather a curious need, but it arises with existential types; if you have data A = forall a . (context) = A a (context including Typeable a) then this allows you to getB :: (Typeable b) = A - Maybe b getB (A a) = cast a and so extract a value from A, if you can guess its type. Clearly we can implement cast = fromDynamic . toDyn My question is: is this the most efficient way of doing it, or is there a better way? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Casting dynamic values
George Russell [EMAIL PROTECTED] writes: cast :: (Typeable a,Typeable b) = a - Maybe b cast = fromDynamic . toDyn My question is: is this the most efficient way of doing it, or is there a better way? I think I'd do it that way. toDyn and fromDynamic are both pretty simple functions. toDyn x pairs x with a representation of its type. fromDynamic checks the type is correct and returns x. That is, the cost is: 1. construct the representation of type a 2. construct the pair 3. deconstruct the pair 4. construct the representation of type b 5. compare the representations of types a and b If GHC is able to inline these functions, construction and deconstruction of the pair can probably be eliminated. That leaves just building the representations and comparing them. I believe GHC could construct the representations at compile time - all it has to do is inline some pretty-trivial method bodies. It'd be nice if GHC could perform some parts of the comparision at compile time. For example: Int =?= Int- True Int =?= Float - False [a] =?= [b]- [a] =?= [b] But I don't think GHC can do this because AFAIK, GHC will not reduce literal string comparisions at compile time. Int == Int - True Int == Float - False App List a == App List b - List == List a == b - True a == b - a == b [This is assuming that GHC's implementation of Typeof still uses strings. This may not be true though since there was talk of adding direct compiler support to make the implementation of typeof more efficient and, more importantly, less prone to programmer error. The motivation to do this was the realization that one could break type safety by writing a bad instance of typeof.] -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
