When we're talking about ASCII I/O, I have *not* been counting the fact that
you can use the File->Open menu and choose an ASCII converter to save an
ASCII file, nor that I can drag and drop an ASCII file into my Oberon
application and it reads it just fine. These do demonstrate ASCII I/O
support in Oberon/F, but this isn't what we're talking about. We're talking
about being able to write code that opens an ASCII file, reads from it,
writes to it, and saves it without any user interactions needed in between.
This is needed frequently in engineering applications which may have a dozen
input and output files for a given "run". And if I have a dozen output
files, it would be completely ridiculous to display them all and give the
user the option to save each file in any format he/she wants!
However, as several of us have pointed out, Oberon/F has implemented ASCII
I/O to the level where most of us are getting by just fine using TextMappers
and Converters. Several of us have also written our own interfaces to
simplify the complexity of dealing with the provided interface. Oberon
Microsystems has certainly helped out by supplying the example
module ObxAscii, but they stopped short by not implementing ReadLn,
ReadLInt, ReadReal, ReadLReal, WriteLInt, WriteReal, and WriteLReal.
Certainly one solution is for them to implement these remaining calls, and
then let people use this as their "standard" ASCII I/O module if they want
to. This way it's not part of the framework (making the "purists" happy :-)
), but also folks don't have to waste the time implementing their own ASCII
I/O module -- we've seen from the posts on this list that at least 3 people
have had to do this...
But I agree with your main point -- Oberon/F's positives far outweigh it's
negatives...I wonder how easy it is to create a dialog box (or a menu item,
or a hypertext help system) in Ada95? ;-)
-- Marc Martin, marc.martin@boeing.com