The standard library needs to provide adequate possibilities to enable input/output operations.
We compare Fuzion and other languages by looking at the facilities for reading from files, stdin, or sockets. The situation is very similar for writing.
Current State of I/O in Fuzion
io.file.read effect currently provides just
which just reads all of the given file into a byte array.
io.file.stdin currently provides
read, which reads n
codepoints (!) into a string, and
read_line, which reads a line into
a string. A pull request
adds reading of single bytes, multiple bytes and single codepoints.
Since the goal of Fuzion is to unify different concepts, this situation is obviously not ideal.
Comparison with other languages
We compare the situation above to the situation in Go and Rust. Both handle I/O quite similarly.
Go provides two relevant low-level interfaces:
io.Reader provides a single function
Read which can be used to read a given number of bytes, while
io.ByteReader provides a function ReadByte which reads just a single byte.
on GitHub explains the difference of
To get the more useful higher-level operations of reading lines, or codepoints
(they are called "runes" in Go), or just to have buffering, Go provides a wrapper called
bufio.Reader. This works with any
Rust does this similarly, there is a
Read trait which requires a defined
read which also tries to read a given number of bytes. The
trait implements some default methods based on
read, e.g. an iterator for the bytes.
Similarly to Go, if you want to use some useful higher-level methods, you can use a
BufReader, which is similar to the
bufio.Reader. Note that Rust
does not seem to provide a way to read a given number of codepoints. (It is
implemented by a
Conclusion for Fuzion
The way Go and Rust do I/O seems pretty intuitive because developers deal with e.g. network the same way they deal with files or stdin. This is also what we want to do in Fuzion. However, the concepts will need to be adapted to Fuzion's particular features, specifically effects.
It is not clear whether it is necessary to provide codepoint-oriented I/O in the standard library.