Daniel Ruoso wrote:
Em Seg, 2009-02-02 às 09:37 -0800, Larry Wall escreveu:
It's also not clear how this should interact with buffering systems
like stdio.  But in any case, speaking directly to the IO stack is
likelier to give consistent results than playing mix-n-match with
various calls on the IO stack that make various assumptions.


The question here is, will Perl 6 IO use stdio.h or re-implement its
features?

My first shot at it would be...

role IO {
   has $.fd;
}

I strongly believe the current S16 needs rewriting from scratch. This approach seems far more more perl6-ish. I tried to draft a new S16, but realised I simply dont have the knowledge (or the time to acquire the knowledge) necessary for even an initial draft. But in trying, these are some of the ideas I had.

a) 'open()' seems to me to be syntatic sugar for something else, such as the creation of a File object. Perhaps in the Setting, 'open()' would be defined to include any necessary OS specific roles (eg, chown, chmod).

b) the :r and :w adverbs on 'open()' are adverbs because they modify the way 'open' as a verb operates.

c) the file tests :r and :w are not adverbs. They are methods on File objects to determine the properties readability and writeability and return Booleans. Things which are different should be named differently. Also, in my (very limited) experience, testing readability and writeability are less frequent in use than opening for read and write, thus for Huffman reasons, they should be longer. May be .readable .writeable?

d) The vast majority of S16 seems to be about functions that are essentially wrappers around unix calls. To be honest, I have never used most of them within a perl program. ( As an aside, may I suggest that this is because the nature of the perl language has changed. When originally developed, it was to fill a need directly related to managing unix systems. There are now better tools for these tasks, so perl6 does not need to address them in the core. The success of perl on the internet was due to the much deeper design values incorporated in perl and that these deeper insights were more adaptable to a different environment. There are now a variety of tools for handling the internet environment. Perl6 - I believe - is now addressing an even wider set of issues - a larger problem space. Leaving unix wrappers in the core specifications will tie it down and perhaps hinder its development. Suppose perl6 becomes the defacto language for an internet browser, IO would not even be related to files or an operating system.)

e) Only the minimum tests (readability and writeability and executability) and minimum adverbs (:w and :r) are mentioned in the other specifications, together with =$filehandle, open, print, and say.

f) radical suggestion:
if the syntax '=$filehandle' lazily takes something from the file handle, then
$filehandle = <output>;
should send something to it.
This means that the syntax
my $filehandle = open(<name>, :r);
needs to become
my $filehandle .= open(<name>, :r);
which, I would suggest, is more in line with calling a .=new() method on an object.

In this way '=' replaces 'say' (or 'print') on a filehandle. Bare 'say' (or 'print') could be retained as syntactic sugar for
$*STDOUT=

We would also have
$filehandle = map { s/ <html_entities> / %html_entities/ } @lines;
as a filtering idiom.

Given the frequent use of 'say' in any program, this is more Huffman efficient for a filehandle.

g) Statbuf is mentioned in S03. It is not really dealt with in S16. It seems to me from the context in S03 that Stafbuf is a sort of 'eager' filehandle, in that the whole file is pulled into memory and then can be operated on. If this is the case, would it not be more appropriate for the eagerness to be defined as an adverb for 'open()' ? eg.
my $filehandle .= open(<name>, :r, :e);
Wouldn't this eliminate the need for Statbuf as a defined object type?

h) Would it not be possible to write the IO specification in such a way as to make everything 'outside' the program a single category of IO? Thus files, http and ftp connections are all streams into containers and the same verb ( 'open()' ) with attendant adverbs (:w, :r) are used to establish them and the same set of tests (.readable, .writeable) used to verify the steams have the required properties at some point in the programe. All directories and urls would all be locations with the same methods to discover container objects (files, archives, databases) in them.

Richard Hainsworth

Reply via email to