[clean-list] Troubles using a function as parameter to another function

[Arjen]

At 23:41 14-02-2002 +0100, you wrote:
>op 2/14/02 8:03 PM schreef Claudio Potenza op claudio.potenza@mclink.it:
>
> > I get this error:
> >
> > Uniqueness error [test.icl,5,Start]:"argument 1 of processFiles"
> > attribute at  indicated position could not be coerced
> > (File -> (*File -> ^ *(*Files -> *(String,*File,*Files))))
> >
> > I have found a workaround for this by playing around with the definition of
> > the function "doWork", but it is so ugly I don't want to show it here!
> > Another strange fact is that if I defined a function "doWork" that doesn't
> > have the "*Files" parameter, but only the two File, it works!
> >
> > I cannot understand why this happen (and the exact meaning of the error
> > message). Am I overlooking something about the uniqueness typing?
> >
>
>I'm sure someone else can explain the error you get better than I can. The
>easiest solution here is to tuple the function arguments. The following
>version compiles without errors:
>Start :: *World -> String
>Start world = processFiles doWork "input.txt" "out.txt" world
>
>processFiles :: !((File, *File, *Files) -> (String,*File,*Files)) String
>String *World -> String
>processFiles doWork inputName outputName world = undef
>
>doWork :: (File, *File, *Files) -> (String,*File,*Files)
>doWork (inF, outF, files) = undef
>
>Regards,
>
>Diederik van Arkel

The function has three arguments (File, *File and *Files) and can therefore 
be used in a curried way (giving the function only one or two arguments). 
But the result of the partial function application on two arguments must 
yield a unique function because it 'contains' a unique object (the second 
argument: *File). Clean requires and detects this, but it does not 
automatically adjust the type accordingly.

The problem can be solved using a more common (but less Clean) way to write 
function types:

processFiles :: (File -> (*File -> *(*Files -> *(String,*File,*Files)))) 
String String *World -> String

The compiler can now be certain that the partial application of doWork (or 
any other function that matches this type) does not violate the laws of 
uniqueness typing.

Grouping the arguments in a tuple (as Diederik has done) also works because 
partial application of the function is not possible since it has only one 
argument (the 3-tuple).

kind regards,
         Arjen van Weelden