How do you verify that a print succeeded? Currently there's no way to
know. Throwing an exception if a global flag is set would suffice and
wouldn't require constantly pushing exception handlers in case the
program doesn't care enough (e.g. the run it and delete it variety).
Plus using exceptions would probably make platform independence easier
from PIR's standpoint as it won't need to know what the error code
actually means, and the exception object can include a message saying
so. As well, the lines of code can go straight from open to print to
close without throwing in error checking after each opcode. Since that
runs contrary to how most HLL's operate, I don't know how good of an
idea it really is for parrot.
The 'write' opcode does seem redundant, but what if it's changed to
print to a user selected file stream? Just select the file stream with
one opcode, and each write call after that will print to that instead
of stdout. That's the best idea I can come up with to remove
redundancy(without removing the opcode of course), even though I don't
know if it'd be worth all the side effects.
Concerning all the byte/character issues, all the string opcodes except
bytelength work with characters. But the io subsystem currently only
deals with bytes. I know there is the speed issue for things like
reading with dealing with utf8, but something like 'peek' should
probably be able to get the full character. Also, what's supposed to
be the default encoding for all data read in from a stream where a
layer's not added that explicitly states so? Ascii, binary?
I don't think it's really been addressed, at least not recently, but
what about IPv6? By the time perl6 becomes commonplace and used
often(and thus, parrot), IPv6 will be common enough that problems could
occur. Currently it's not speced or stated, aside from a comment in
PIO_sockaddr_in.
One more thing, what about specing directory handling? Nothing is
speced yet for it.
On Mar 3, 2006, at 1:27 PM, Allison Randal wrote:
We're going to try something a little different. With Chip's blessing
I've written a very early draft of the PDD for I/O (not numbered yet).
The attached PDD isn't a completed document with Chip's seal of
approval, it's a seed for discussion.
What I need from you all is comments. What's missing? What's
inaccurate? What's accurate for the current state of Parrot, but is
something you always intended to write out later? What thoughts have
you had on how the I/O subsystem should work? All contributions
cheerfully welcomed, from a single sentence to several pages of text.
Chip won't be making design decisions during the conversation. He may
not even participate much, since part of the point is to split the
work into parallel tasks so we can get more done than is humanly
possible for one person. I'll use the discussion to write up a more
complete PDD (probably with a few alternatives written in), and then
work with Chip to review/revise it.
Thanks,
Allison
<pddXX_io.pod>
