On Fri, Mar 03, 2006 at 05:54:43PM -0600, Joshua Isom wrote: > 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
I assumed that the lack of documentation of any return code meant that it would return as Perl 5 does. Bad me. > 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. I get the impression that a lot of people would like to be able to switch Perl 5 to a mode where IO operations that return errors (but usually don't) throw exceptions instead. So rather than needing open $fh, ... or die ...; print $fh, ... or die ...; close $fh or die ...; # Some file systems may not notice that you are over quota until close time you do use fatal 'io'; # making this up open $fh, ...; print $fh, ...; close $fh; and errors are still reported correctly. This approach works even better if the void context open/print/close are in someone else's code that you're using, as you can impose decent error handling on it without needing to rewrite it. (An alternative setting is to run in exception throwing mode when builtins are called in void context, but return error codes when someone is listening for them) This is a HLL way of working, but not one currently easily supported. However, my understanding was that PIR doesn't have Perl 5's concept of context, so some of this isn't going to translate directly. But I think it will be possible to generate much tighter PIR if IO opcodes can be told to throw exceptions. > 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. write in Perl 5 is for formats. I don't really see a need for it and print. > 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 peek can't really guarantee to get more than 1 byte. This restriction sort of comes from C's stdio, which will allow you to ungetc() 1 byte, so you can (sort of) implement peek, in that you fake peek by pushing it back. However, the socket API allows a 1 byte peek from a socket without actually consuming it, so there is precedent at lower level APIs for 1 byte peek rather than a 1 character peek. The perl 5 PerlIO system allows unlimited unread() by pushing back a temporary buffer - this is more "peek" by "ungetc" than peek by really peeking. > be the default encoding for all data read in from a stream where a > layer's not added that explicitly states so? Ascii, binary? EBCDIC? Logically the default default is it's either compile time chosen "ASCII or EBCDIC" or "binary". Nicholas Clark
