Re: *safe* coerce, for regular and existential types

2003-08-02 Thread oleg
Does this technique extend to polymophic types? Yes, of course. The type F a b in the earlier message was polymorphic. Let's say we have the following type: data D a = C | D a Is it possible to index the type D a? I have just lifted the polymorphic Maybe -- which is isomorphic to your

Re: *safe* coerce, for regular and existential types

2003-08-01 Thread Ralf Laemmel
[EMAIL PROTECTED] wrote: ... loads of cunning stuff omitted Software-engineering-wise your approach suffers from an important weakness: a closed world assumption. The programmer has to maintain your TI and pass it on in all kinds of contexts for the array of types to be handled. I also had a

Re: *safe* coerce, for regular and existential types

2003-08-01 Thread Wang Meng
I admire the elegancy of your code which makes the changes to add new data types minimum. There is one question I want to ask: Does this technique extend to polymophic types? Let's say we have the following type: data D a = C | D a Is it possible to index the type D a? Or there is some

*safe* coerce, for regular and existential types

2003-07-31 Thread oleg
This message describes functions safeCast and sAFECoerce implemented in Haskell98 with common, pure extensions. The functions can be used to 'escape' from or to existential quantification and to make existentially-quantified datatypes far easier to deal with. Unlike Dynamic, the present approach

Re: *safe* coerce, for regular and existential types

2003-07-31 Thread Derek Elkins
Throughout this message you imply, if not outright state, that Dynamics requires unsafeCoerce/unsafePerformIO. This is simply not the case. GHC implements Dynamics with unsafeCoerce, or did last time I checked, but it can easily be implemented using only existentials. (I presume that this