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
