[clean-list] Some questions on typing in clean

[Thomas Antonini]

>Thomas:
>
>Why are there 2 functions fopen and sfopen ?, all the more because the
compiler can't know at compile time if some files are shared or not
>
>The compiler doesn't know at compile time. But if you open a file with
sfopen, you know that the program will work in the presence of other parts
of the program that also have sfopen-ed the file. If you sfopen or fopen a
file while the same file has been fopen-ed already, you will get an error
message. If you want to change a file, you have to use fopen (and not
sfopen). That gives you the ability to write (which sfopen does not
support), but the file can be opened once at a time. If you just want to
read the file, you can use sfopen, with the option to open the file multiple
times. You can't even close them anymore.
>
OK, but I think the overloading mechanism of Clean can solve that.


>-More generaly, what's the use of indicating *-attributes in types? This is
a problem of the compiler , not the programmer; it doesn't change the
("external")
>behaviour  of the program, unlike !-attributes
>
>Are you saying: the compiler can deduce uniqueness, so why could not the
compiler add uniquness attributes "under water " i.e. without the programmer
ever seeying them? I think that would be possible. On the other hand, if you
are writing a function, starting with the type signature, you can add
*-attributes so, whatever you code and recode, the compiler will help you
make sure that the end result will have the right uniqueness attributes.
Without manual *-attributes, a simple change in the function could destroy
uniqueness without you noticing. You would only find out later when you
compile a program that calls the function and would require the uniqueness.
So using *-attributes gives you the possibility to contain the uniqueness
information with the function. You can then state: "I only want this
function to be used with parameter x unique, so the array-implementation can
be fast, or so the file can be updated at all." Agreed, the external
behavior is not affected by uniqu!
>eness, but programmers are (also) required to control a function's
performance. Manual *-attributes are one way to do that.
>

Same thing.
As far as I have understood , the compiler will automatically deduce
uniqueness information and
make the appropriate optimisation or warn you if you share some object which
cannot be shared
like world. Moreover, it always give you the "best" type, so you have just
to check that uniqueness
appears in the type of your function infered by the compiler if don't want
your array to be shared
for example.
But it's just a matter of taste, I guess.

>- when one uses some function like fwrites acting on a console , it changes
the whole world too (!?)
>(unless World has no access to console) -Indeed, why not choosing to have
only one big world instead of several? (is it a matter of programming style,
clarity, speed or something deeper ?)
>
>If you have several sub-worlds derived (opened) from the one big world,
such as files, you can subsequently change those sub-worlds independently.
Say you have a system that concurrently writes a result file, an error file,
a log file and an invoicing file. Each file might be written a record to, in
response to reading a record from a huge input file. with only one world you
would have to chain that world from the result-writing-function to the
error-file-writing-function to the log-file-writing-function, to the
invoicing-file-writing-function, and onto the next input record. You would
have to serialize your program in ways that you would not want to.
>
OK, I didn't look at concurrency yet. Thank you.

>-Isn't it possible to implement some mechanism for exceptions (abort)
similar to the one for uniqueness, allowing exceptions carrying data to be
defined,
>raised and catched ("*type" would mean an object raising no exception,
"type" an object raising at most one)
>
>Maybe. Work it out. Explain the details you have in mind.
>
>Regards Erik Zuurbier
>
A function may not potentially raise two different abstactions, so you have
to check
that in the body of this function -say foo - , only one exception at most
ise used.
Moreover, you have to check that functions used in foo may raise or not a
potentially
unique exception ...etc. It can be solved in the same way as uniqueness.
But maybe I confuse referential transparency and confluence.
I tried to find some examples where exceptions destroy ref. transp. in vain.
If somebody has some references on that, please let me know...

Thomas Antonini
mailto:antonini@pps.jussieu.fr