Re: RFC 33 (v2) Eliminate bareword filehandles.
At 12:50 PM 9/6/00 -0500, David L. Nicol wrote:
I see barewords as being whatever the programmer wants them to be,
as long as he makes it clear what he expects the word to be before using
it.
So, Copen becomes a legacy constructor and the perl6 version of it would
be something like
my filehandle fh; fh-new("/tmp/appendablelog");
Ugh... How about...
my filehandle fh;
fh-open("/tmp/appendablelog");
or (using indirect object notation)
my filehandle fh;
open fh ("/tmp/appendablelog");
or even
open my filehandle fh ("/tmp/appendablelog");
with or without fh being syntactically singular, fh will from here to the
end of the enclosing block be seen as a filehandle if that makes sense in
context.
What advantage does this give over:
open my filehandle $fh ("/tmp/appendablelog");
besides the saving on one key stroke?
If it doesn't make sense, meanings from other contexts will be attempted
before
autovivification or error.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words
Re: RFC 33 (v2) Eliminate bareword filehandles.
Buddha Buck wrote:
my filehandle fh; fh-new("/tmp/appendablelog");
Ugh... How about...
my filehandle fh;
fh-open("/tmp/appendablelog");
Has anyone read RFC 14?
$FILE = open "/etc/motd";
@doc = $FILE;
$WEB = open http "http://www.yahoo.com";
@html = $WEB;
The next version (hopefully out this week) will clarify this syntax
further.
-Nate
Re: RFC 33 (v2) Eliminate bareword filehandles.
Has anyone read RFC #11,112,006,825,558,016? It's rather difficult to keep up with them all, or read them all retroactively when you miss a few days. It's also hard to grep them (HTML is the root of all evil). Is there an rsync server that will dole out the pods for us as needed? --tom
Re: RFC 33 (v2) Eliminate bareword filehandles.
Tom Christiansen wrote: The straightforward way to do that is quite simply: open(FH, "|foocmd thisfoo thatfoo|") or for shell avoidance: open(FH, "|-|", "foocmd", "thisfoo", "thatfoo")) Does this work now Or are you just suggesting this be added to Perl 6? Quoth Camel-3, p. 752: When starting a command with open, you must choose either input or output: "cmd|" for reading or "|cmd" for writing. You many not use open to start a command that pipes both in and out, as (currently) illegal notation, "|cmd|", might appear to indicate.
Re: RFC 33 (v2) Eliminate bareword filehandles.
At 01:52 PM 9/6/00 -0600, Tom Christiansen wrote: Has anyone read RFC #11,112,006,825,558,016? It's rather difficult to keep up with them all, or read them all retroactively when you miss a few days. It's also hard to grep them (HTML is the root of all evil). No HTML here: $ telnet dev.perl.org 80 Trying 209.85.3.25... Connected to tmtowtdi.perl.org. Escape character is '^]'. HEAD /rfc/1.pod HTTP/1.0 Host: dev.perl.org HTTP/1.1 200 OK Date: Wed, 06 Sep 2000 21:09:56 GMT Server: Apache/1.3.9-dev (Unix) Last-Modified: Wed, 23 Aug 2000 04:42:38 GMT ETag: "1251b5-2608-39a3563e" Accept-Ranges: bytes Content-Length: 9736 Connection: close Content-Type: text/plain I think it's time for a thread subject change. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 33 (v2) Eliminate bareword filehandles.
Tom Christiansen [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Eliminate bareword filehandles. "Eliminate" is such a strong word. You're saying that we can't use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people still use stdin and stdout! :-) They can be predefined constant functions returning the appropriate filehandle object. Eliminating arbitrary bareword filehandles may or may not be a good thing. -- Piers
Re: RFC 33 (v2) Eliminate bareword filehandles.
On Wed, Aug 30, 2000 at 02:47:46AM +0200, Bart Lateur wrote:
On Tue, 29 Aug 2000 18:17:46 -0600, Tom Christiansen wrote:
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
Aha! You fell for one of my pet pieves. You tried to return a lexical in
the same expression were it was declared. That doesn't work. It's not
the same variable.
Perl is starting to feel more like C in this instance :-(
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 33 (v2) Eliminate bareword filehandles.
David L. Nicol wrote: How about ALLOWING bareword everything-else? Start having filehandles work the way everyone expects them to at first, passing as arguments and so forth, without any special treatment? How about barewords are always interpreted as function names (by default); and the traditional barewords (STDOUT, etc.) are defined as functions which return filehandles (like a thunk, eh?). -- John Porter We're building the house of the future together.
Re: RFC 33 (v2) Eliminate bareword filehandles.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
still use stdin and stdout! :-)
=head1 ABSTRACT
Now that scalars (objects) can be used for filehandles, the bareword form
should be eliminated.
If true, doesn't that argument hold true for functions, too? If
all non-method functions were stored in only in variables, I guarantee
you that it would be rather harder to call a non-method function
as though it were a method.
=head1 DESCRIPTION
The venerable bareword form of the filehandle leads to code that is
unnecessarily abstruse given that they can now be stored in
scalars. Bareword filehandles are not lexical, and require the use of
typeglobs and Clocal to pass them to subroutines, concepts unnecessarily
advanced for such a beginner-type operation.
It does?
sub p {
my $fh = shift;
print $fh "got it\n";
}
p(STDOUT);
Of course, that's a bit dicey because STDOUT is omniglobal. You
could pass it as
p(*FH);
instead, and the function's definition doesn't change. What I tell
people is that if they want, they can just pretend, even though
it's not quite true, that * is the type symbol for a filehandle
at least when it comes to passing it or storing in somewhere.
This works out quite well.
Of course, with prototypes, even this is unneeded:
sub p(*) {
my $fh = shift;
print $fh "got it\n";
}
p(FH);
Filehandles really aren't that spooky anymore.
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
A simple unsubscripted scalar can virtually always be used to hold
a potentially package-qualified subroutine name, filehandle name,
a directory handle name, or a format handle name, and that scalar
used in lieu of those names (if unqualified, they're usually
package-relative, of course). These are called "indirect function calls"
or "indirect filehandles", etc. You can even do it with a method name, to
invoke an indirected method call (well, if you use the arrow syntax).
Indirections seem kind of nice.
--tom
Re: RFC 33 (v2) Eliminate bareword filehandles.
At 06:17 PM 8/29/00 -0600, Tom Christiansen wrote:
Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore?
There are some people I would like to stop using output filehandles, yes :-)
Heck, some people
still use stdin and stdout! :-)
The RFC is absent a necessary discussion of what to do with the global
filehandles. Some people have already suggested renaming them; RFC 30
takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
issue of $ARGV which already has a meaning :-( If we can solve that one
then I'd just make all those filehandles scalars. Backwards compatability
hit but worth it in simplification IMHO. I recall an earlier discussion
about the $ prefix meaning a singular whatzit... as a filehandle clearly is...
Any ideas on what to do with the existing $ARGV if it became the
filehandle? Can it be one of those magical things that knows when it's
being used as a filehandle and Do The Right Thing?
=head1 ABSTRACT
Now that scalars (objects) can be used for filehandles, the bareword form
should be eliminated.
If true, doesn't that argument hold true for functions, too?
That wasn't the entirety of my argument :-) It's not a sufficient reason
per se.
If
all non-method functions were stored in only in variables, I guarantee
you that it would be rather harder to call a non-method function
as though it were a method.
=head1 DESCRIPTION
The venerable bareword form of the filehandle leads to code that is
unnecessarily abstruse given that they can now be stored in
scalars. Bareword filehandles are not lexical, and require the use of
typeglobs and Clocal to pass them to subroutines, concepts unnecessarily
advanced for such a beginner-type operation.
It does?
sub p {
my $fh = shift;
print $fh "got it\n";
}
p(STDOUT);
Of course, that's a bit dicey because STDOUT is omniglobal. You
could pass it as
p(*FH);
instead, and the function's definition doesn't change. What I tell
people is that if they want, they can just pretend, even though
it's not quite true, that * is the type symbol for a filehandle
at least when it comes to passing it or storing in somewhere.
This works out quite well.
This is true; but won't it make even more sense, and less pretense, just to
pass filehandles around in scalars?
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 33 (v2) Eliminate bareword filehandles.
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
Aha! You fell for one of my pet pieves. You tried to return a lexical in
the same expression were it was declared. That doesn't work. It's not
the same variable. Running it with warnings enabled says:
Grr..
Name "main::fh" used only once: possible typo at test.pl line 3.
I feel that this ought to have worked, i.e. that the scope of the
lexical kicked in in the middle of the expression, at the transition
over the shortcut operator "".
Except that then you can't say
local $x = $x;
or
my $x = $x;
--tom
ARGV vs $ARGV (was Re: RFC 33 (v2) Eliminate bareword filehandles.)
Peter Scott wrote:
Some people have already suggested renaming them; RFC 30
takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
issue of $ARGV which already has a meaning :-( If we can solve that one
then I'd just make all those filehandles scalars.
I've been thinking about this all night, and then it dawned on me that
this isn't actually a problem at all. According to RFC 14, all
fileobjects will have a -filename attribute, and moreover this
-filename attribute will also be -STRING, meaning that a fileobject
will morph into the filename it was opened on when in a string context.
This means that $ARGV will be both the filehandle *and* the name of the
file, depending on context:
while ($ARGV) {# used as fileobject
next if ($ARGV eq $lastfile) # -STRING, both are filenames
print "Now reading $ARGV";# $ARGV-STRING, filename
dostuff($_);
$lastfile = $ARGV;# copies object, but that's ok
#$lastfile = "$ARGV"; # speed-concerned folks could do
this
}
A glimpse of how polymorphic objects can be used practically,
methinks...
I don't think this needs an RFC of its own (just counted, I'm up to 23
RFCs and 2 sublists, so a little overworked :), but if everyone is in
agreement, I'll add it to the bottom of RFC 30 as a "By the way...".
-Nate
P.S. Further discussion should really be on -io, so if you reply please
change the sublist. Thanks.
RFC 33 (v2) Eliminate bareword filehandles.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Eliminate bareword filehandles. =head1 VERSION Maintainer: Peter Scott [EMAIL PROTECTED] Date: 4 Aug 2000 Last Modified: 29 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Status: Frozen Number: 33 =head1 ABSTRACT Now that scalars (objects) can be used for filehandles, the bareword form should be eliminated. =head1 DESCRIPTION The venerable bareword form of the filehandle leads to code that is unnecessarily abstruse given that they can now be stored in scalars. Bareword filehandles are not lexical, and require the use of typeglobs and Clocal to pass them to subroutines, concepts unnecessarily advanced for such a beginner-type operation. =head1 IMPLEMENTATION Easy, hopefully. =head1 REFERENCES Lperlvar/"Typeglobs and Filehandles"
