I/O example

[G.P.H. Josten]

# Many thanks to those who sent me I/O examples showing me how to read in
# a file into a list of chars, munge it, and then write it out. Very
# very helpful.
# 
# As a followup query Artie wrote the following to me:
# > Also, your comment about "I want to read it into a list because it's
# > small" (or something to that effect) requires further examination--think
# > in terms of lazy evaluation. The WHOLE list of input may never need to 
# > exist all at once (as long as it's unique). So the size of the input 
# > doesn't matter.
# 
# I realise that lazy evaluation may mean the the while list may never
# need to exist at once, but in this case I wondered if the presence of
# I/O may force the whole list to be constructed. To be more specific
# my example was as follows,
# 
# 1) read a file into a list of chars.
# 2) munge the list a bit.
# 3) write the list out to another file.
# 
# If step 1) is done lazily then there is a potential problem -- namely
# that step 3) overwrites the file I am reading from, making a mess. Hence
# I wondered if the presence of the I/O forces step 1) to be done strictly
# and hence the whole list does exist at once. Or does Clean avoid this
# problem without losing laziness, by not allowing a write to a file that
# is already open for a read?
# 
# graham
# 

A year ago, I wrote some parser-combinators, that could parse files directly 
(instead of just char-lists of which parser-combinators were already 
available, in Clean ofcourse). You can find those at the Clean-repository of 
Nick Kallen, also member of this list. (I don't recall the correct link at the 
moment, but it is somewhere near http://clean.teklab.com). Take a look at 
those...


The problem or question you stated, has to do with reading and writing files, 
actually the same ones at the same times. Clean can't allow this, just because 
you get unpredictable result and you don't want that. So Clean just doesn't 
allow this, at least, if you don't use shared files. (writetofile (f, a), 
writetofile (f, b)) as like it's written, two write commands at the same time 
and of undefined order, because they are stated next to each other in a tuple 
(tuples can be evaluated left-first or right-first, you never know, might even 
be a mixture), is a result (of another function) that Clean won't parse. I 
don't recall what the compiler will complain about, but it won't compile it, 
you need to give an answer like write (write(f, b), a) or write (write (f, a), 
b)...


A lot of this has to do with the '*' flags with which you marks arguments and 
results for uniqueness, the compiler will verify if only one function at the 
same time can have access to that argument (which could be a file for 
example)...


Hopefully this is a bit clear for others to understand, otherwise, ask again. 
Oh, and I recall that I wrote writer-combinaters as an anti-pole for 
parser-combinators, you find them in the same repository, look for both the 
parser and writer combinaters for the program called MolVaC, a simple molecule 
viewer and converter...


Greets to all,
Geert Josten

Chemistry student at
the University of Nijmegen
The Netherlands