RFC 186 (v1) Standard support for opening i/o handles on scalars and
arrays-of-scalars Reply-To: [EMAIL PROTECTED] This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Standard support for opening i/o handles on scalars and arrays-of-scalars =head1 VERSION Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]> Date: 23 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 186 Status: Developing =head1 ABSTRACT It's extremely useful to be able to open an i/o handle on common in-core data structures, such as scalars or arrays-of-lines. The CPAN modules IO::Scalar, IO::ScalarArray, and IO::Lines currently provide some of this functionality, but their pure-Perl implementation (chosen for portability) is not as fast or memory-efficient as a native implementation could be. Additionally, since they are not part of the standard Perl distribution, many developers are either unaware of their existence or unwilling to obtain and install them. This RFC proposes that support for "in-core i/o" be folded into the Perl distribution as a standard extension module, making use of native C code for speed. =head1 DESCRIPTION =head1 IMPLEMENTATION As described in the ABSTRACT above. The following I/O handle classes are proposed as minimally necessary; they are taken from existing Perl5 CPAN modules with the same names: =over 4 =item IO::Scalar An I/O handle which can be opened on a scalar (string) variable. We simply treat the bytes of the scalar as a "virtual file". =item IO::ScalarArray An I/O handle which can be opened on an array of scalar (string) variables. Here, the "virtual file" is defined as the concatenation of the scalars in the array. One very common way to obtain such a data structure is to slurp a file into an array. =back If Perl6 follows Java's example of distinguishing "bytes" from "characters", then it should be understood that the proposed I/O handles manipulate I, not characters. That is, the Java equivalents are classes like C. Character-based I/O should be handled by some additional conversion mechanism which is wrapped around byte-based I/O; this mechanism should be applicable to I I/O stream. A look at the Java implementation of byte-oriented "input/output streams" versus character-oriented "readers and writers" is worthwhile for this. =head1 REFERENCES IO::Scalar (CPAN) IO::ScalarArray (CPAN)
Re: RFC 34 (v3) Angle brackets should not be used for file globbing
Tom Christiansen wrote:
>
> >Is some technical reason that this can't be done in perl 5? I hate
> >having to add another pair of braces just to reassure perl that I didn't
> >forget a comma:
>
> >print {$fh{$name}} "data\n";
>
> Indirect objects are very limited in what they can be.
Currently, but my impression based on discussions was this was going to
be "fixed" in Perl 6. I'd love this:
dostuff @stuff;
To be able to automatically figure out I meant:
$stuff[0]->dostuff(@stuff[1..$#stuff]);
Hence RFC 174.
Before anyone brings up problems, there are precendence rules, etc,
covered in the RFC. Please read it and check out the thread starting
here:
http://www.mail-archive.com/perl6-language-subs%40perl.org/msg00188.html
Before rehashing everything.
-Nate
Re: RFC 34 (v3) Angle brackets should not be used for file globbing
>Is some technical reason that this can't be done in perl 5? I hate
>having to add another pair of braces just to reassure perl that I didn't
>forget a comma:
>print {$fh{$name}} "data\n";
Indirect objects are very limited in what they can be.
--tom
Re: RFC 34 (v3) Angle brackets should not be used for file globbing
Tom Christiansen wrote:
> >=item Complex filehandle references
>
> >my %filesystem;
> >my $filename = '/etc/shells';
> >open $filesystem{$filename}, $filename
> >or die "can't open $filename: $!";
> >print <$filesystem{$filename}>;
> >__END__
>
> >GLOB{0xa042284}
>
> This goes hand-in-glove with the issue that you
> can't write:
>
> print $fh{$name} "data\n";
>
> It's necessary but not sufficient to solve only the I part of this
> I/O difficulty.
Is some technical reason that this can't be done in perl 5? I hate
having to add another pair of braces just to reassure perl that I didn't
forget a comma:
print {$fh{$name}} "data\n";
Jon
--
Knowledge is that which remains when what is
learned is forgotten. - Mr. King
Re: RFC 180 (v1) Object Class hooks into C
Hildo Biersma wrote: > > > =head1 ABSTRACT > > > > There needs to be a way for an object class to define C format > > specifiers for use in formatting objects into strings with C and > > C. > > I find myself agreeing with your sentiment, but the approach in this RFC > is not sufficiently general. Why only provide hooks for printf, not for > formats and output disciplines? > > I think a better approach would be that the to-string operator for > objects should get an optional 'width' parameter. In normal cases > (stringification, interpolation), that argument would not be set. In > printf and formats, but maybe also by specific file disciplines (e.g. > the 72-character-wide output file), the width parameter would be set and > indicate how wide the object may print its data. Thanks you, I had forgot about formats. Note that more then just width information is needed in the general case (and I should add more examples to the RFC to show this). Take the set of printf specifiers that would be needed for the Math::BigFloat package. You would want to define %f, %e and %g at least with all the decimal point placement, padding and sign stuff. Even formats allow for 'basic print using' picture like fields (which I believe get turned into printf specifiers internally) that have more information then just width. In addition I intended that arbitrary object classes could define unique to the class printf specifiers that contain anything the writer wants to define between the % and the final letter. I will write a second version of the RFC over the weekend to address these issues. -- Mark Biggar [EMAIL PROTECTED]
Re: RFC 181 (v1) Formats out of core / New format syntax
Johan Vromans wrote: > > Good work! Thanks. :-) > Is there any reason left to maintain formats as something internally > special? Well, as you note in your implementation suggestions, it would be nice if Perl compiled the format the first time around. Along with the implicit constructors suggested in RFC 171, this means that my format $FILE_FORMAT = could create an instance of a 'format' object - $FILE_FORMAT - then use the string assigned to it as a format to compile. It could then recompile the format on reassignment. Personally, I think it's clearer than qf(), more consistent with other types (int, etc), and also looks more like Perl 5. > How about providing the format string as an additional argument to > write? > > write $fh, $format_string; That's a neat idea, I like it. > Alternatively, if a real internal format type, proposed name: Format :-), > would be desirable, yet anoter quoting operator could be useful: I think this is definitely what I was aiming for. Though I think qf() is a cool idea, I also worry we're going to then need qi() (int objects), qb() (bigint objects), and so on. But I'm not against it. Current discussions on -objects talk about making everything an object, in which case a 'format' object make a lot of sense. That's where I lifted the syntax in the RFC from, actually. > > [2] We might consider making a special case in the Perl parser so that > > This is exactly what we must try to avoid as much as possible. TPOP > are too many special cases already. I agree. -Nate
Re: RFC 181 (v1) Formats out of core / New format syntax
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > Formats out of core / New format syntax Good work! This RFC opens the possibility to normalize (e.g. make the syntax no longer something exceptional) the formats. >my format $FILE_FORMAT = q( > @<: @ > $name, $ssn > ); Is there any reason left to maintain formats as something internally special? We could use ordinary strings: my $file_format = q( @<: @ $name, $ssn ); > However, I don't particularly like extra steps, personally. How about providing the format string as an additional argument to write? write $fh, $format_string; This makes it also easy to use several different formats on the same file handle. > =head1 IMPLEMENTATION What about efficiency? Perl could compile the format (much like it is done now) upon first use, and cache the result. As long as the format string does not change the cached result can be used. Alternatively, if a real internal format type, proposed name: Format :-), would be desirable, yet anoter quoting operator could be useful: my $file_format = qf( @<: @ $name, $ssn ); Now, $file_format would be a Format object (compare this with qr//, that produces a Regex object). > [2] We might consider making a special case in the Perl parser so that This is exactly what we must try to avoid as much as possible. There are too many special cases already. With the above changes to the RFC, formats become nicely integrated conforming language objects. -- Johan
Re: RFC 180 (v1) Object Class hooks into C
> =head1 ABSTRACT > > There needs to be a way for an object class to define C format > specifiers for use in formatting objects into strings with C and > C. I find myself agreeing with your sentiment, but the approach in this RFC is not sufficiently general. Why only provide hooks for printf, not for formats and output disciplines? I think a better approach would be that the to-string operator for objects should get an optional 'width' parameter. In normal cases (stringification, interpolation), that argument would not be set. In printf and formats, but maybe also by specific file disciplines (e.g. the 72-character-wide output file), the width parameter would be set and indicate how wide the object may print its data. Hildo
Re: RFC 181 (v1) Formats out of core / New format syntax
On 31 Aug 2000, Perl6 RFC Librarian wrote: >my format $FILE_FORMAT = > @<: @ > $name, $ssn > . > > Then this is even less different and scary. Get rid of that C and > it's Perl 5. s/that C/that C and the dollar sign/; Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]>
