[clean-list] Wish list =+ New *World

lethevert acatofearlgrey at ybb.ne.jp
Fri Aug 24 17:34:51 MEST 2007


Hello all,


Peter Achten wrote:
 > More difficult is one with a string parameter to point to a specific file:
 >
 >    newFile2 :: String -> *File
 >
 > because for two expressions str1 and str2 such that str1 = str2,
 > (newFile2 str1) = (newFile2 str2). It can not be determined at
 > compile-time whether two expressions yield the same result. One would
 > have to resort to run-time error messages, but this is undesirable due
 > to unpredictable evaluation orders: either the first is evaluated and
 > the second aborts, or vice versa, or, worse, one is performed after the
 > other is completely done and everything seems all right!

I think it's not true because the following function brings no problem.

copyStr :: String -> *String
copyStr s = {c \\ c <- s}

Perhaps such a rule must be considered that if the result type is unique,
a compiler should not optimize two expressions into a single one.


BTW,

Andrew Butterfield wrote:
 > Edsko de Vries wrote:
 >> On Thu, Aug 23, 2007 at 08:16:55AM -0700, Shivkumar Chandrasekaran wrote:
 >>> But this still requires that an extra *File parameter be threaded
 >>> down from Start to the local call site. I still don't see why we
 >>> couldn't (well I guess I could using C functions?) have a
 >>> createFiles :: *Files call that returns a blank nameless partition
 >>> from the FileSystem? This would be very convenient for any systems
 >>> programming task requiring functional access to /tmp......
 >>
 >> Yes, I guess if you can guarantee that that the *Files you get is
 >> pointing to an 'empty partition', you're safe. But I wouldn't be too
 >> sure how to implement that.
 >
 > The file-system implementation in Clean would have to
 > manage such a invisible (not empty) partition, and ensure that it
 > was not observable by file/directory accesses coming from other parts
 > of the program.
 >

I thought those discussion was how to implement memoizing calculation
in some external area, but does creating *File object solve the problem?

If we can create *File object from nothing, it must go along with the
calculation all the way and I think its still cumbersome.

In this case it's ok if there is any trick to help memoizing function.
For example,

memoize :: (a -> b) a -> b

f` = memoize f

would produce a memoized version of function f which calls the f at the
first call, stores the result value in some (external) area and then
return the value after the second call.

However, it cannot be implemented with a *File object if I have a newFile
function and it should be implemented in some magical way.
(Moreover it is difficult to decide when the area to store result values
  will never be used and can be freed.)

I examined this theme when I created a reference type in the past
and I am still thinking about it but I have no clue.
I think multithreading and channel system might be a key to the solution....

But in many cases, referential transparency enables us to rearrange
a structure of a program more easily and safely in Clean than in other
languages. Decoupling the calculation might be the fastest way to solve
the problem ;p


Regards,

lethevert
lethevert at users.sourceforge.net
http://lethevert.blogspot.com/


More information about the clean-list mailing list