Re: File open modes

[Quinn Dunkan]

Arrghh!  I did it again!  Sorry Nobbi!  Note to self: *always* look at To:
before sending.

Hmm, I didn't see Fergus' post either on the list or the newsgroup, so things
must be getting munched somewhere.

Nobbi wrote:
> Alternative aproach: Why not have different classes for the different 
> open modes? That would be the only way that makes sense to me! (Of 
> course you still have different modes for append and create, but that 
> should be possible to handle!
> 
> On Tue, Oct 03, 2000 at 11:48:55AM +0000, Fergus Henderson wrote:
> > address@hidden (Quinn Dunkan) writes:
> > 
> > >The FILE class has open_for_this, open_for_that, etc. which are just 
> > >wrappers
> > >around various fopen modes.  I'm curious as to why it doesn't simply 
> > >provide a
> > >open(fname:STR, mode:STR):SAME or create method.
> > 
> > Probably for the same reasons that Ada, C++, Haskell, and Mercury all
> > provide their own interface rather than using fopen() mode strings.

Well, I agree that mode strings are not the end-all be-all.  But I think they
work well.

> > >I see the mode string in
> > >fopen as being a "little language", like printf format strings, that 
> > >becomes a
> > >large set of unwieldy methods when moved to another language.
> > >
> > >mode string pros:
> > >compact
> > >easy to read
> > >easy to write
> > >
> > >cons:
> > >must be learned for "easy to read" and "easy to write" to be true
> > 
> > How many C programmers know what "a+b" means in a mode string?

All of them, I hope.  If not, it's a man page away.  The documentation issue
is unfair to sather because a well-documented interface doesn't imply a good
interface, but if you can't trust a programmer to know how a basic library
function works, you're fighting a losing battle.  The mode string is not as
clear and simple as it could be.  But it's not that bad.

> > I would argue that the Sather/Ada/C++/Haskell/Mercury approach is more
> > readable than the C approach.
> > 
> > Readability is much more important than writability,
> > because code is written once, but during code reviews
> > and maintenance it is read many many times over.

I'm with you 100% on that one.  But I think that

open("foo", "w");

is easier to read than

open_for_writing("foo");

for the same reason I think

loop while!(a.length < i) ...

is easier to read than

loop while!(array.length < index_of_array) ...

When I first saw references to the CPX class, I had no idea what it was.  But
I still think it's a perfectly readable name, since readability of the basic
features of the language should be optimized to people who already know them.
Non-core features / classes / libraries should probably be more descriptive.

I argue that opening a file is as "core" (if not more so) as complex numbers.
Certainly I forsee working with more FILEs than CPXs but I'm no engineer :)

> > Additional cons for the C approach include
> >     - error-prone (e.g. you might try using "rw"
> >       to open a file in for both reading and writing)

Just as someone might say open_for_writing instead of open_for_write.  That's
just a matter of memorizing the interface or reading the documentation.  Both
interfaces must be memorized.  I think the (single-letter) C one happes to be
easier to memorize, but that's subjective.  Method names can be checked at
compile time, while mode strings can't, so, while you didn't specifically make
the "mode strings are theoretically more dangerous" point, I'd have agreed if
you had :)

> >     - can lead to portability problems
> >       (e.g. some implementations may silently accept
> >       "rw" and do what you expect, while others may
> >       do something that you don't expect and don't want;
> >       also omission of "b" causes a lot of porting
> >       problems between Unix and non-Unix systems)

I'd put this under the heading of "sather shouldn't be affected by its
plaform's libc braindamages", which is a good point.  While a straight wrapper
around fopen would be the simplest, if people really thought platform libc
bugs where fopen accepts the wrong thing were a problem (I don't think so)
then FILE::open can easily do some checking itself (hey, we even have
preconditions!).  The consensus for "scripting" languages like python and perl
seems to be that it's not the language's responsibility to check those things
except where it poses a real practical problem.  Since sather seems to be
oriented more towards "correctness" and specifically "well-defined" while
scripts go more for "simplicity", it's reasonable if sather wants to check.
Put this way, it sounds a bit like classic New Jersey vs. MIT, and I
understand if sather wants to be MIT :)

I don't agree with the omission of "b" point, though... \r\n systems are
always going to need some kind of distinction which is not necessary on
"normal" systems, and there's not much a language can do to force people on
"normal" systems to make the distinction (well, at least not given the
standard "a file is a stream of bytes" thing, and I might be wrong anyway).
The old stdlib requires you to use a whole seperate BFILE class, which means
that when you need to fix your porting problem, you not only need to change
the the file object instantiation, but you also need to alter the signatures
of all methods that expect a file.  I suspect the people who wrote the old
stdlib did it on \n systems :)  Or perhaps they did it on purpose, as it would
be an error for a routine that wants a binary file to get a text one.  I note
that the new library has both FILE and BIN_FILE deriving from $FILES, which
means that if you wrote your "don't care" routines with a $FILES signature,
only the instantiation need be changed.

I still think, however, that multiple methods on multiple classes is not the
ideal solution, especially to the 'binary file' problem.  Although strings are
not necessarily the best structures from a safety point of view, I'd rather
see one open method that takes a mode argument.  I don't know mercury (it is
on the queue, though), but haskell uses

openFile :: FilePath -> IOMode -> Handle

where IOMode is a sum type over ReadMode, AppendMode, WriteMode, and
ReadWriteMode.  So, in the face of your arguments, I'll revise my position
that it's not the mode *string* I like, but the simplicity of only one FILE
class, with only one method to open a file.

Of course, a string is more extensible and simpler than a sum type, and more
languages support strings than sum types, so a string is often a better choice
in a similar way that mess of ad-hoc text files is often a better choice than
one monolithic binary database.

Unfortunately, this isn't reflected in my email, as my arguments tend to also
be messy, confused, and ad-hoc, but *still* not simple :)  I'd have to
eliminate the over-use of passive voice and subjunctive :)