On Mar 3, 2006, at 20:27, 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.
Some remarks re the pdd and discussion so far.
o "write" ... [Is this redundant?]
"write" isn't needed. It is there, as some time ago, "print" was't able
to write strings with "\0"s inside.
o "readline" ... Lines are truncated at 64K.
This limitation is history already.
* opcode vs function / method
open P0, "data.txt", ">"
print P0, "sample data\n"
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes are reserved words in Parrot
b) opcodes aren't overridable, that is you can't provide your own
'print' opcode for e.g. debugging
c) all such IO opcodes have to verify that the given PMC is actually a
ParrotIO PMC.
E.g.
new P0, .Undef # or .Integer, ...
print P0, "foo"
I'm in favor of using methods for almost all IO functionality:
P0.'print'("sample data\n")
Combined with ...
* [ return code vs exception ]
... we can also check, if this was a void call or not (Parrot *does
have* the concept of a result context):
$I0 = pio.'print'("sample data\n") # return sucess (>=0) or
failure (<0)
pio.'print'("sample data\n") # throw exception on failure
* C<sockaddr> returns a string representing a socket address
[Nicholas] "I don't think that this is appropriate. It's IPv4
specific."
A more general SocketAddr PMC seems to be needed here.
* [ seek, tell ] and 64bit values
We want sooner or later extended Parrot register types. One of these
would be a C<Int64>) Parrot register. We currently have:
op tell(out INT, in PMC)
op tell(out INT, out INT, in PMC)
Depending on the arch (32 vs 64 bits) one of these opcodes is
suboptimal. With a new "L" (Long) register type the functionality could
be handled transparently:
$L0 = pio.'tell'()
The register allocator would map 'L0' either to a pair (I0, I1) on 32
bit arch or just to 'I0' on 64 bit arch.
Actually the type mapping bits in pdd03 got extended to cope with such
register types.
* [Nicholas] "Should the IO system provide symbolic lookup on AF_*
and PF_* constants.
IIRC at least one of these groups is OS dependant"
Any such constants that aren't the same on all architectures have to be
delt with at runtime, i.e. these constants can't be integers, because
integer constants are compiled into the bytecode in the flavor of the
compiling machine. That is: instead of
.include "xF_foo.pasm" # constants are resolved at compile time
we'd need something like:
load_bytecode "xF_foo.pasm" # postpone to runtime
We don't have a proper syntax for such (not so-) constants yet, but it
could just be:
pio = socket(".AF_UNIX", ...)
leo
