First Class File IO

[Nick Kallen]

Having read the document, I am quite impressed. But...
    Forgive me if I'm way off here, but it seems to me that the proposed
implementation of Dynamic types goes a long way towards making types
first-class.
    For example, the document talks about type-pattern variables:

h :: Dynamic Dynamic -> Dynamic
/* If types don't look first-class here, I don't know what does: */
h (f :: X -> Y) (x :: X) = dynamic (f x) :: Y
h df dx = dynamic "Error" :: String

Heck, the whole concept of an object as a tuple of data and type almost
necessitates that types are first-class.

So, I have a few questions:

1. Does anyone else agree that this implementation of Dynamic types flirts
with types as first-class?

2. What are the advantages and disadvantages for both the programmer and the
language implementor of having types be first-class?

3. Are first-class types compatible with Clean? Does anyone think adding
first class types to Clean would be a good idea?

4. Clean imlementors: what do you think about adding first-class types to
the language.
--
Couldn't a programmer use dynamic types to create functions on types like I
semi-proposed in "Defining Types"?

The following is an edited response Marko van Eekelen provided to my
"Defining Types":

> > I was playing around and tried:
> > :: Env a b :== [(a, b)]
> > :: Member (Env a b) :== (a, b) // This doesn't work!

> I have the feeling that what you want is functions on types (is that the
case?).
> This would indeed be a significant extension...

I think I could use dynamic types (albeit in an inelegant way) to implement
the Member "function":

Member :: Dynamic -> Dynamic
Member (whoCares :: Env A B) = dynamic whoCares` :: (A, B)

(I used capital letters because I assume that's the convention for
type-pattern variables. Is this required?)