[bitc-dev] Haskell question: exceptions

Iavor Diatchki iavor.diatchki at gmail.com
Fri Aug 12 16:40:19 EDT 2005


Hello,
I am not sure of the details (they are in this paper that I
mentioned), but the difference between these two is that in the one
case the polymorphic variable appears in a negtaive position (i.e. as
an argument), while in the other it is in a positive position.  Here
is an example:

# let fNeg x = 1;;
val fNeg : 'a -> int = <fun>
# let fPos 1 = undef 1;;
val fPos : int -> 'a = <fun>
# let test1 = if true then fPos else undef 1;;
val test1 : int -> 'a = <fun>
# let test2 = if true then fNeg else undef 1;;
val test2 : '_a -> int = <fun>

-Iavor

On 8/12/05, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> On Fri, 2005-08-12 at 11:29 -0700, Iavor Diatchki wrote:
> 
> > I think the original ML value restriction said that only expressions
> > that syntactically look like values can be polymorphic.  Then it is
> > surprising that the following works:
> >
> > # let r = if true then [] else raise Xn;;
> > val r : 'a list = []
> >
> > because the expression is not a value, and yet it became polymorphic....
> 
> Yes, it is coming back to me now. SML requires that a binding can be
> treated as polymorphic only if it is initialized by a "syntactic
> constant." I looked at one point, and I was not able to find a rigorous
> definition of syntactic constant, but the intuition is that the value of
> the initializing expression must be computable at compile time.
> 
> So what is happening in the case above is that the entire expression is
> being reduced at compile time to "[]", which is polymorphic.
> 
> So now the question is: what is the difference between the following two
> cases that causes the value restriction to be invoked in one but not the
> other:
> 
> # let r = if true then [] else raise Xn;;
> val r : 'a list = []
> 
> # let q = if true then id else raise Xn;;
> val q : '_a -> '_a = <fun>
> 
> Clearly there is something different in the handling of type
> constructors ("[]") vs. functions.
> 
> shap
> 
>



More information about the bitc-dev mailing list