Proposal: fileRead() fileWrite()

[newboerg]

OT: Is there a Roadmap for Structorizer?

Back to Topic: What if there where SIMPLE read/ write functions for files?

This would obviously produce Problems with the code Generators, but would open a lot of potential for teaching how to handle files (EOF,EOL and so on).

At least add an Option to pipe the "Output to console" into a file.

[fesch]

OT: No ;-)

[codemanyak]

@newboerg

What if there where SIMPLE read/ write functions for files?

Thank you for this proposal! Actually, I have been "pregnant" with this idea for some time, too. In a way, I have been waiting for someone to request it...

What are the main challenges:

1. We talk about an operating system resource, which has to be handled. We would need some kind of file type, and it can hardly be a direct Java class like File or some kind of (buffered) stream. So what would it be? Some specifically designed wrapper class behind the scenes, obviously.
2. What kind of files could we support? Hardly anything more than text files in a simple approach. No problem with writing but how to read data from a text file? Entire lines? Substrings matching some literal syntax of (untyped!) variables? How to handle reading/scanning errors? The most straigtforward thing would be to read a text line and parse it as if it were the content of the input dialog, implying an automatic type decision according to the syntax of the string. So this is best handled in close analogy to the existing input/output instructions.
3. Is it better to offer an API similar to that of Pascal (assign, open, read, write, close) allowing to manipulate unopened files on the file system level (delete, move, rename) or should the life span of a file handle be restricted to the period between (f)open and (f)close call like in C? The Pascal approach (also represented by the File class in Java) would cause even more difficulties on export because it brings stronger OS dependency in.
4. Would we need a try context according to proposal #56 in order to ensure closing an opened file? Not necessarily, of course.
5. As you correctly mentioned, it would be a(nother) huge challenge for code export.

At least add an Option to pipe the "Output to console" into a file.

Ah, well, I had hoped that the possibility to copy the text content from the console window would be sufficient for a while... ;-) I will think about such an option (would rather be a "tee" i.e. a spawning of the output where the executor messages would have to be filtered out from the file stream while the output window still shows all).

[newboerg]

2. As Structorizer is good to teach Basic Concepts, a very easy-to-use way would be the best.

readFile() could return the file line wise per call, until of course EOF would be reached.

maybe do it like this, so ist working similar to Input

oh and fileRead() should be green then :)

4. Opening and closing should not be the Focus, because there is not much to learn from in this scope.

[codemanyak]

I agree with you that it should be as easy as possible. I do not agree with you that open and close are neglectible. I think there is a lot students can and should learn from it:

1. First of all that a file is not like a variable residing in local memory but an external resource that is to be "borrowed" from the OS for the time it is needed.
2. Next that there is not a unique file such that an eof function without argument would be ambiguous.
3. Third that an open file has a status (a writing/reading position) influenced by every write or read. Instruction fileRead("test.txt") would be ambiguous with this respect: Is it a repeated read behind the former position or is it an attempt to read again from start?

So I suggest to introduce a set of procedures and functions using a simple integer value generated by the Structorizer (a unique counter) as file handle. The first three functions would open a file and produce a handle that can be used until fileClose() has been called with this number as handle.

fileOpen(path: String): Integer (for reading access)
fileCreate(path: String): Integer (for writing access, overwriting from start)
fileAppend(path: String): Integer (for writing access, writing from previous end)
fileWrite(handle:Integer; value: Object)
fileRead(handle: Integer): Object
fileClose(handle: Integer)
fileEOF(handle: Integer): Boolean

In files opened with fileCreate() or fileAppend() the routine fileWrite() can be used, in files opened by fileOpen() functions fileRead() and fileEOF() can be applied. If the opening fails then a handle value of 0 might be returned or possibly some negative number serving as error code. The use of an inactive file number would cause an error at runtime.

[codemanyak]

I just updated my previous comment - I had closed the issue by mistake instead of putting something to the begun text.

[codemanyak]

A demo for the reading of the values from a text file would look like this with my proposed approach: You may see by this design that I prefer a predicting EOF test (in contrast to the C function feof, which only detects the file end after a failed reading attempt has already discovered it). Internally this is less efficient, of course, bevause it requires a failing read attempt that has to be undone or buffered behind the scenes, but it is way more understandable and easier for the beginner learning to work with files. This approach is relying on built-in library functions and procedures rather than configurable "keywords", which could be highlighted. I don't see how we could level this difference without the simplifications you suggested but I don't regard as helpful.

[codemanyak]

Don't expect the prototype for this enhancement before Christmas, please.

[newboerg]

Well, this Sir would be Great to have indeed.

[codemanyak]

Specification update: It turned ot, that it will be more practical to provide some more procedures and functions for a sensible working with text files:

fileOpen(path: String): Integer (for reading access)
fileCreate(path: String): Integer (for writing access, overwriting from start)
fileAppend(path: String): Integer (for writing access, writing from previous end)
fileWrite(handle: Integer; value: Object)
fileWriteLine(handle: Integer; value: Object)
fileRead(handle: Integer): Object
fileReadChar(handle: Integer): Character
fileReadInt(handle: Integer): Integer
fileReadDouble(handle: Integer): Double
fileReadLine(handle: Integer): String
fileClose(handle: Integer)
fileEOF(handle: Integer): Boolean

Some explanations: fileWrite will write an arbitrary value just as is without any additional separators, line feeds etc. This allows to compose arbitrary texts without Structorizer interference. fileWriteLine will do the same but add a newline character. fileReadChar will return the next character of the file (including a blank or newline character). fileReadInt will return an integer value if and only if the next token in the file is an integer literal, otherwise it will raise an error. fileReadDouble will return a floating-point number if and only if the next token in the file is a number literal (be it integral or not), otherwise it will raise an error. fileRead may return:

• an integral number if an integer literal (e. g. -17) follows at the current reading position;
• a floating point number if a floating-point literal (e. g. 3.6e17) follows at the current reading position;
• an array of simple-type elements if a comma-separated sequence of primitive-type literals, enclosed in curly braces, (e. g. {0, 25, foo, "text without commas", 6.9}) follows at the current reading position;
• a string consisting of the content of a quoted character sequence (e. g. "This text, however, might contain commas, but no escaped quote") following at the current reading position;
• a string comprising the next character sequence not interrupted by a blank (e. g. foo) in any other case.

fileReadLine will always return a string comprising the (remainder of the) current line up to but not including the next newline character. The newline character will be consumed, though.

[codemanyak]

Updated API proposal is implemented and seems to work. More complex tests will have to be performed, particularly to verify robustness against different kinds of exceptions. No code export activity so far. Will have to be cared of before release 3.26.

[newboerg]

disable the file i/o article on the page till features are active :-)

[codemanyak]

@newboerg As it is difficult to disable the uploaded User Guide passages without deleting them from the server, I did my best to mark them as preview. TO DO checklist:

• [x] User Guide update
• [x] Pascal/Delphi generator
• [ ] Oberon generator
• [x] Perl generator
• [x] BASH / KSH generator
• [x] C generator
• [x] C++ generator
• [x] C# generator
• [x] Java generator
• [x] PHP generator
• [x] Python generator
• [ ] BASIC generator
• [x] Batch mode function check