io module issues

[KimBruce]

I'm starting to write the chapter on files for my text, Programming with Grace. A couple of issues, some substantial, some not. The 2nd and the last are probably the most important.

1) Shouldn't the "getline" method be "getLine" to be consistent with our naming style? Would "line" be even better? 2) When reading a file, what should be the behavior of a read after eof is true? In minigrace, getline returns a blank line if eof is true. It seems to me that it should throw an exception. 3) eof and hasNext seem to be the same. If so, perhaps the documentation should say that. The documentation gives different descriptions to each. 4) The documentation for io should specify that trying open a non-existent file for reading should result in throwing an EnvironmentException. 5) The write method for file output is inconsistent with the same method for system.output. If you write

myFile.write "really done"
myFile.write "really!"

then the file associated with myFile holds

really donereally!

On the other hand if you write:

inout.output.write "really done"
inout.output.write "really!"

where inout is the internal name of the "io" library, then the output shows:

really done
really!

The write method on standard output seems to model the behaviour of the standard "print" command, which makes sense, but having write work differently on the two kinds of output files makes little sense to me.

Looking back, it seems like we should have had both print and println in the standard dialect, with the second adding a "\n" to the output. Then the print would be similar to write. It may be too late to make a change that substantial.

[kjx]

it seems like we should have had both print and println in the standard dialect, with the second adding a "\n" to the output.

I still like just having print. while on general principles I think we have too many escapes, I quite like the idea of yet another gratuitous escape ("-" perhaps) that surpasses the newline at the end of the string..

Then the print would be similar to write.

yes, but I think it's more important that the basic print is as simple as possible - better to make write and friends parallel print. Then again, I think print needs a bit more magic. In mg for example, if an asString (or debugString) method crashes, that crashes print --- print should probably handle things like that more gracefully (or not).

It may be too late to make a change that substantial.

If it's too late to make a change that minor then I've been wasting my time for the last month

[kjx]

or perhaps a better way to put it: settling issues like this (and others: inheritance is still listed as tentative in the spec) is why I think some kind of meeting to go over stuff could be useful.

[KimBruce]

In minigrace, trying to open a file for input that doesn't exist in the browser file pane raises an exception, as expected. Trying to open a non-existent file for output also raises an exception. However, if you create it, in the file pane and then delete it (whether you wrote to it or not), then the next time you write to it, it will be created again.

I would have expected that output files would have been created in the file pane automatically (after all they aren't really created in the visible file system). However, I could live with it if you had to explicitly create it. It seems very inconsistent to me, though, that once it has been created and deleted then it no longer has to be created.

[KimBruce]

I'm happy to meet sometime in the near future. I'll most likely be gone much of the first week of January, but should be around aside from that. The second half of January is likely to be fairly crazy with school starting combined with bringing in lots of job candidates and my having to teach an overload this term as we had to fire a totally irresponsible visitor.

[kjx]

we're more or less on holiday in January. I'll be teaching come March, but should be able to carve out some time here. If Amy makes it to school next year, things free up for me

[apblack]

This issue is for minigrace, not the Grace language as such, I think. But I don't know of a way to move this discussion to the minigrace issue tracker.

Most of the issues that @KimBruce raises are bugs, but one (newlines on standard output) is an implementation restriction that has to do with the way that text is presented in the Web IDE. It might be fixable by someone who knows more about the IDE and html than I do.

The reason that next and hasNext are there is to make the Stream interface compatible with the Iterator interface. The reason that the other methods are there is to make the minigrace compiler work. Probably the right solution is to decide what interface we really want, and then to modify the compiler to use it (and, in the interim, to create a compilerIO module to keep the compiler running).

We also need a plan for the ongoing maintenance of minigrace. Using minigrace was supposed to be temporary. What do we want to plan for the longer term? I could spend my entire sabbatical fixing minigrace, but it's a bit hard d to justify that as the best use of my time.

[kjx]

Using minigrace was supposed to be temporary.

indeed.

I could spend my entire sabbatical fixing minigrace, but it's a bit hard d to justify that as the best use of my time.

indeed again.

What do we want to plan for the longer term?

ay, there's the rub!

[KimBruce]

Is there any chance of another implementation that will cover the language (and dialects) as developed so far? My sense is we've been eager to have another implementation, but none seemed to be imminent.

[apblack]

I've committed a propose revised interface to the IO module on a branch. See the latest version. Please crap^H^H^Homment on it now, while I'm still implementing it ;-)

[kjx]

quick thoughts on Andrew's interface

• should system & spawn & Process be in io? or elsewhere?
• I guess we can't wait to rethink the interator/enumerator/stream interfaces at this point the comment for "size" at least gives me pause.
• how much of this do we actually need for programs we're likely to write? seek?
• does it matter that you cannot read the rear/write pointer? (whatever that's called) cursor? could have "cursor" read it, and "cursor:=(_)" set it
• is there a request on string to trim a final newline (if there is one)?

[KimBruce]

The io operations seem fine. I assume with the current implementation of minigrace, all paths will reference the file system in the left panel (as opposed to what is stored in the “real” file system/hard drive).

For FileStream,

Clarify that nextLine moves past the newline at the end of a line, but does not return it in the result.

For close, shouldn’t further reads also raise an exception? (and you should specify the exception raised so it could be caught.)

For seek and related, state that n is measured in characters?

In theory it would be nice to be able to read and write objects to a file, but I suspect that is more work than it is worth for minigrace.

Process related operations (spawn) seem like they belong in their own library as they have nothing to do with io. I’m guessing that there are no plans to implement these in minigrace at this point — let me know if I’m wrong as I might want to use them if available.

All this reminds me, do we have a technique for iterating through characters (strings of length 1)? I have programs where I’ve wanted to iterate through “a” to “z”, for example. We have ord: String -> Number, but nothing going the other way AFIK.

Kim

On Jan 10, 2018, at 3:59 PM, Andrew Black notifications@github.com wrote:

I've committed a propose revised interface to the IO module on a branch. Sett it here https://github.com/gracelang/language/blob/48c85696e4dde0705ca202c585f10240dd27d03e/website/GraceModules/io.md. Please crap^H^H^Homment on it now, while I'm still implementing it ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gracelang/language/issues/142#issuecomment-356778471, or mute the thread https://github.com/notifications/unsubscribe-auth/ABuh-p6xJZvLcOwsiGtRUVewzhxEjw8gks5tJU7KgaJpZM4RJY_3.

[apblack]

Process should clearly be its own module — I'm not clear why Michael put it in io at all. The compiler is the only program to use it, AFAIK. One more thing for me to do ... make a new module for process. The directory and file time operations should probably come out too, and be moved to a filesystem module.

Binary (object) io was implemented by a student of mine so that he could create Java .class files, but unfortunately, only for the C backend, not for JS. If someone thinks it urgent, they are welcome to implement it. Perhaps this module should be renamed "textIo"?

And yes, reading or writing from a closed file should raise an exception. I can do that for file io, but not for standard input and output, since the compiler won't work if closing the output really does. I attempted the other clarifications — you should feel free to edit the file too.

[apblack]

I believe that I have addressed all of these issues, with the exception of removing the process stuff and creating a separate module for it. The documentation has been updated too.