support opening a "ram file" as a proper io_device()

[mikpe]

Is your feature request related to a problem? Please describe. I have some code which reads and processes Unicode (it's a lexical analyzer for a programming language). Input may come from a regular file or from a string().

file:read/2 doesn't support reading general Unicode text, so for file data I use io:get_chars/3.

When reading from a string() it would be beneficial to be able to file:open/2 it as a "RAM file" and use that handle with io:get_chars/3. Unfortunately, in this case file:open/2 returns an fd() instead of a general io_device(), which prevents using the io module on it. Currently I work around this by plugging in my own "IoDev" like abstraction which for string() input handles reads and updating input position, but for file data just passes through to the file and io modules.

If RAM files could be opened as proper io_device()s then I would't need this kludge.

Describe the solution you'd like Change file:open(_, [ram | _) to return an io_device(). Requiring an explicit option for that, to avoid tripping up unsuspecting legacy code, would be Ok.

Describe alternatives you've considered Simulating an IoDev-like object as described above works Ok but adds complexity and redundancy. Writing the string() to a temporary file would work but is too ugly.

Additional context n/a

[mikpe]

I suppose I could also implement the I/O protocol myself, for the non-file inputs. (Not having implemented that before it didn't enter my mind as an option.)

[josevalim]

Returning an I/O device would mean wrapping it behind a process while one may not be needed. I wonder if it makes more sense to allow the I/O module to receive "file devices" and define an official specification/behaviour for them?

[mikpe]

I've now reimplemented my "string input" method as a proper IoDev, via a process that implements a subset of the Erlang I/O protocol.

Good points:

• it simplifies the rest of my code, in that it only ever has to deal with IoDev and io:get_chars/3

Bad points:

• there's a lot of boilerplate in the implementation
• it's not obvious, while reading the I/O protocol documentation top-down, what exactly one needs to implement; I ended up implementing a full read-only I/O server only to remove 80% of it

So my wish-list would be:

• rewrite the documentation, make it a more linear read (now one has to jump back and forth) and hands-on what to implement
• move historical notes (Virding's rationale, simpler long ago) to an addendum, and perhaps link to an online copy of Virding's rationale (if one exists, I couldn't find it)
• the example I/O server ought to exist as an Erlang module in the repo and not just hidden as fragments in the xml docs
• perhaps a gen_io could help people with the boilerplate and providing a good structure for implementations