gracelang / minigrace

Self-hosting compiler for the Grace programming language
39 stars 22 forks source link

IO module interface #254

Open apblack opened 6 years ago

apblack commented 6 years ago

The interface of the io module is not particularly coherent. It needs a design.

This issue has been discussed on the language issue tracker (issue 142).

The root cause is that the current IO module is trying to do two different things: make minigrace work at the command line, and provide access to virtual files stored in browser tabs.

apblack commented 6 years ago

@Kim wrote here:

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.

I am not seeing this issue. This program creates the browser FS file "testFileIssue#142.txt" as expected.

import "io" as io

def strm = io.open("testFileIssue#142.txt", "w")
strm.write "Here is some text\n"
strm.write "Here is some more\n"
strm.close

Can you give me a program that illustrates the issue?

KimBruce commented 6 years ago

Sorry, my mistake. I forgot to close the file. When it hasn't been closed, it doesn't bother to push anything to the output. Should we close this or do you want to leave it open for the general issue of rethinking the interface?

apblack commented 6 years ago

Let's discuss the interface here.

I think that you are right: getline is the wrong name. I like nextLine, by analogy with next. I think that eof can be deprecated in favour of hasNext. I'm working on the problem of suppressing newlines on output, which is not simple (because it involves HTML).

KimBruce commented 6 years ago

nextLine and hasNext sound reasonable. Of course novices haven't seen explicit iterators, though they've used them implicitly. It would be good to have next and nextLine behave the same when attempting to read beyond the end of file (e.g., raise the same exception).

By the way, the documentation for getline is misleading. getline reads in everything up to and including the next newline character, but that newline character is not part of the returned string.

apblack commented 5 years ago

Perhaps a file stream should be an iterator of characters? And, if the user wants an iterator of lines, they should use a decorator LinesFromCharacters to create a lines iterator?

kjx commented 5 years ago

Ahh, still need I get my head around iterators vs collections vs streams. This is probably something pretty basic though: I think java now has just Files.lines(“name”) to do that; we should not be significantly more complex.

Import “files” as files files.lines(“my file.txt”)

Sent from my iPhone

On 24/11/2018, at 18:22, Andrew Black notifications@github.com wrote:

Perhaps a file stream should be an iterator of characters? And, if the user wants an iterator of lines, they should use a decorator LinesFromCharacters to create a lines iterator?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.