[clean-list] relationship between uniqueness types and single-threaded lambda calculus?

Edsko de Vries devriese at cs.tcd.ie
Tue May 29 12:09:57 MEST 2007


Hi Adam,

I had a quick read through the paper you mentioned. However, since that
was the first time I read about the STPLC, I find it hard to compare it
to uniqueness typing. I agree that one difference is that the example
they give in the paper:

swap! a i j = 
  let* x = lookup a i
       y = lookup a j
  in update! (update! a i y) j x

cannot be typed in Clean. However, I'm not sure if this is due to the
lack of the "r" mode Instead, I would venture that this is due to the
absence of a "let*" construct in Clean.  I'm not sure why it isn't there
actually, and it would be relatively straightforward to add it (I might
just do that in the system I'm proposing :) Clean *does* take the
evaluation order into account in some cases however; in particular, in
conditionals. For example, if we have

is_blank :: Array -> Bool
clear :: *Array -> *Array

then the following is a well-typed Clean program:

  \arr. if (is_blank arr) arr (clear arr)

even though there are three references to "arr", this program is
well-typed, because the conditional must be evaluated before both
branches (and is_blank only requires a non-unique array), and then only
one of the two branches will be evaluated. Note that "is_blank" does not
return any array.

But I have to admit I'm not 100% sure about the three different
properties they mention in the paper and all their permutations - it
seems to be that that at least is one advantage of uniqueness typing -
less properties to think about :)

Another thing I'm not sure about is exactly how polymorphic their
calculus is, but perhaps you can tell me: for example, in STPLC, what
would be the type of 

 \x. x
 \x. \y. x
 \f. \x. f x

It may be interesting to compare the types of those functions to their
types in Clean (and maybe to the types in my own uniqueness system :)

Edsko


More information about the clean-list mailing list