On Mon, May 02, 2005 at 10:25:08PM +0300, Gaal Yahas wrote:
: Here's a basic proposal for the open and pipe builtins. It was discussed
: on #perl6 today and seemed okay to the people there. I'd like to hear
: your comments, since the internals side of much of this is ready and is
: looking for an interface.
:      module Prelude-0.0.1;
:      class IO;
:      has Handle $:read_h;
:      has Handle $:write_h;
:      has Handle $:err_h;
:      has Process $:process_h;
:      multi sub open (
:               Str ?$filename = $?CALLER::_,
:               Str ?$mode = '<',
:               Str ?$encoding = 'auto') returns IO;
:      multi sub pipe (
:               Str ?$command  = $?CALLER::_,
:               Str ?$encoding = 'auto',
:               +?to, +?from, +?skip_shell) returns IO;

I think I'd rather see something like:

     multi sub open (
                Str +$mode = 'r',
                Str +$encoding = 'auto',
                Str [EMAIL PROTECTED]) returns IO;
     multi sub openuri (
                Str +$mode = 'r',
                Str +$encoding = 'auto',
                Str [EMAIL PROTECTED]) returns IO;
     multi sub openpipe (
                Str +$mode = 'r',
                Str +$encoding = 'auto',
                Str [EMAIL PROTECTED]) returns IO;

     multi sub openshell (
                Str +$mode = 'r',
                Str +$encoding = 'auto',
                Str [EMAIL PROTECTED]) returns IO;

I don't think the command should default to $_, and I'd rather have pipes
use a list for input of the args.  If we make open consistent with
that then we can open a list of files without having to clobber @ARGS.

: Notes / questions:
: Perl5-style open ">file" is no more.[1] An earlier discussion about
: open here brought up URI open, but I think there was no final word,
: and it looks to me that the basic open should always mean file open,
: unless explicity modified. E.g., open could be used as a facade for pipe,
:      open 'ls', '|-';             # or even
:      open 'ls', :pipe => 'from'
: This pipe as it is can automatically do open2/3 if both :from and :to
: are given. I don't know if this is a good thing.

I think that's just

    openpipe 'ls';

By the way, P5's pipe() should probably be renamed to syspipe() or some
such to avoid confusion.

: Is it sane to have handle members when half of the time most of them
: are undef? (E.g. in ro open)

Fine by me.  I'm not fond of the deep class hierarchies some languages
put onto handles.  On the other hand, with roles we might be able
to compose a shallow hierarchy, and that would be okay.

: One suggestion for the 'auto' encoding was to honor a BOM if it is
: present but default to ASCII otherwise. Or should we UTF-8 otherwise?

If it's a choice between those two, definitely UTF-8, but I think we
can be smarter than that.  We can pretty easily autodetect text in
UTF-16 even without a BOM, as long as we don't also have to autodetect
some legacy character set.  I'd love to render BOMs obsolete, at
least on input.  ("Be lenient on what you accept, and strict on what
you produce.")

: Or what's in the environment...?

More useful on output than input, I think, though it could be helpful
in telling the autodetector to look for a particular legacy character
set in addition to the UTFs.

I have another thought on that, which is that you often want a particular
output file to have the same format as some other input file.  So maybe
we could have some kind of openfilter() that specifies both an input
and output file on the same (bidirectional) handle, with the assumption
that the output file will keep the format of the input file.

: And what about IO layers? :)

Yum.  :-)

: What else belongs here? dirhandles, sockets? How are they specced?

Maybe something consistent like:

     multi sub opendir (
                Str +$mode = 'r',
                Str +$encoding = 'auto',
                Str [EMAIL PROTECTED]) returns IO;

     multi sub opensocket (
                Str +$mode = 'rw',
                Str +$encoding = 'auto',
                Str [EMAIL PROTECTED]) returns IO;

: I was looking for a happy medium between overdwim and underlying library
: primitives level.

We should probably reserve io() for the overdwim and sysopen() for the
underdwim, and then not sweat the middle so much.  :-)

: [1] Should this be "Perl(..5) style"?

I think that'd be "Perl-{1..5} style", as it currently stands, and
assuming you want to use the "use" syntax.  Also, we haven't specced
a unary .. yet.  It only saves one character, and I think it's clearer
to force people to say 0..5 or 1..5 (or even "a".."z").


Reply via email to