First Class File IO

Marco Pil marcop@cs.kun.nl
Mon, 5 Jan 1998 17:35:04 +0100


Erik Zuurbier posted four good questions related to the article "First Class
File IO" (about Dynamic types in Clean). I will try to answer them.


1. It looks like the only way that the type of a file can be accessed
 > is matching it against an assumed type. If it does not match, that is it.
 > The clean compiler's type checker gives error messages with some
 > details about why two types did not unify. Will such details be available
 > for run time type checking also?

The following function is intended to be made available:

  typeToString :: Dynamic -> String

such that, for instance, the expression  typeToString (dynamic 5 :: Int) will
evaluate to  "Int". The expression  typeToString (dynamic [5] :: [Int])  will
result in the relatively much longer string  "List Int, where List a = Cons a
(List a) | Nil"
Using this typeToString function, we can write functions that produce some
details about the run-time unification errors:

  DynApply :: Dynamic Dynamic -> Dynamic
  DynApply (x::a->b) (y::a) = dynamic (f x) :: b
  DynApply (x::a->b) (y::c) = dynamic
                                ("Error in 'DynApply': Cannot unify "
                                 +++ (typeToString W::a) +++ " with "
                                 +++ (typeToString W::c) +++ " ."
                                ) :: String
  DynApply (x::a)    (y::b) = dynamic
                                ("Error in 'DynApply': "
                                 +++ (typeToString W::a)
                                 +++ " is not a function type."
                                ) :: String
  W :: a
  W = W

Is this what you wished for, Erik?


2. If a particular file's type is simply not known (forgotten, that is),
 > will there be some utility program that can be used to reveal the type?

No, for reason that it is not possible to write such a utility program.
In general, one cannot (re)construct the type of the expression from the
data that represents it (its graph).


3. If we want real safety, we do not want a hacker to take a file and
 > edit some of it without this being noticed by the clean program that
 > subsequently uses the file. Is there going to be some protection?
 > E.g. adding a signature of the file (a hash value) on closing the file
 > and checking the signature on opening it again.

We do not intend to solve this problem in the near future. Security problems
(other than being type secure) are not of our primal interest. I do not
think Dynamic typing and security problems are strongly related.


4. If a file contains a value of type [a] or Tree a, or whatever container
type,
 > will there be the possibility to subsequently read selected values
 > (of type a) only, or will the whole container have to fit in the heap when
 > the file is read?

This question keeps me busy for some time already. I am sure such possibility
has to be made available, but I am not sure in which form. Perhaps this is
going to be made possible only for arrays -- arrays are born for efficiency.
One can imagine that library functions exist for reading and updating specific
fields of the array, while the array itself is not downloaded in the heap.
Perhaps something can be invented for lazy datastructures (lazy lists) as well.

One of the problems is that for the compiler it is hard to decide whether
data should preferably remain on disk or should be downloaded to the heap
immediately. Perhaps some (more) annotations must be introduced.


Regards,

Marco