Re: RFC: Filehandle type-defining punctuation
Peter Scott wrote: > Filehandles should use C<*> as a type prefix if typeglobs are eliminated. I missed previous discussion of this (if there was any), but it's an idea I've already thought about. It has my vote, fwiw. -- John Porter
Re: RFC: Filehandle type-defining punctuation
>Hearing no outright derision in response to my trial balloon, here it is as >an RFC: >=head1 TITLE >Filehandles should use C<*> as a type prefix if typeglobs are eliminated. Nope. A filehandle is a singular whatzitz. It thus mandatory takes the singular prefix; to wit, $. What's next? Integer and float and complex and string and char and bits prefixes? --tom
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote: > =head1 TITLE > > Filehandles should use C<*> as a type prefix if typeglobs are eliminated. I could go for this, given the `if typeglobs are eliminated' caveat.
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Tom Christiansen, > >Hearing no outright derision in response to my trial balloon, here it is as > >an RFC: > > >=head1 TITLE > > >Filehandles should use C<*> as a type prefix if typeglobs are eliminated. > > Nope. A filehandle is a singular whatzitz. It thus mandatory takes > the singular prefix; to wit, $. What's next? Integer and float and > complex and string and char and bits prefixes? (Weighing in with the traditional "but Tom" message) But Tom, filehandles are different gadgets. They have been in perl up to this point and they are conceptually. I've appreciated and agreed with your linking the punctuation before a variable to parts of speech, but if the you decide that $ is the single singular whatzitz, then what is the plural whatzitz? We have two kinds because they're talking about two different gadgets. Letting * be another kind of singular whatzitz is a reasonable thing. Think of it as singular and plural nouns and verbs if that helps :-) (and yes, I know that analogy doesn't fit very well, so save your fingers on that one :-). Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == When Newton saw an apple fall, he found In that slight startle from his contemplation -- 'T is said (for I'll not answer above ground For any sage's creed or calculation) -- A mode of proving that the earth turn'd round In a most natural whirl, called "gravitation;" And this is the sole mortal who could grapple, Since Adam, with a fall or with an apple. -- Byron == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
Ted Ashton wrote: > Thus it was written in the epistle of Tom Christiansen, > > Nope. A filehandle is a singular whatzitz. It thus mandatory takes > > the singular prefix; to wit, $. What's next? Integer and float and > > complex and string and char and bits prefixes? > > (Weighing in with the traditional "but Tom" message) > > But Tom, filehandles are different gadgets. Filehandles singular, atomic gadgets. Singular, atomic gadgets are called scalars in Perl. > They have been in perl up to this > point and they are conceptually. This is a historical accident. > I've appreciated and agreed with your linking > the punctuation before a variable to parts of speech, but if the you decide > that $ is the single singular whatzitz, then what is the plural whatzitz? Arrays (and hashes) Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Jon Ericson, > Ted Ashton wrote: > > Thus it was written in the epistle of Tom Christiansen, > > > Nope. A filehandle is a singular whatzitz. It thus mandatory takes > > > the singular prefix; to wit, $. What's next? Integer and float and > > > complex and string and char and bits prefixes? > > > > (Weighing in with the traditional "but Tom" message) > > > > But Tom, filehandles are different gadgets. > > Filehandles singular, atomic gadgets. > Singular, atomic gadgets are called scalars in Perl. > > > They have been in perl up to this > > point and they are conceptually. > > This is a historical accident. > > > I've appreciated and agreed with your linking > > the punctuation before a variable to parts of speech, but if the you decide > > that $ is the single singular whatzitz, then what is the plural whatzitz? > > Arrays (and hashes) But that, precisely, was my point: Arrays *and* hashes. If there is more than one plural whatzitz, then why can't there be more than one singular whatzitz? (and don't say, "because plural *means* more than one" :-). If having a filehandle character would make the code clearer, then let's do it. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == To throw in a fair game at Hazards only three-spots, when something great is at stake, or some business is the hazard, is a natural occurrence and deserves to be so deemed; and even when they come up the same way for a second time if the throw be repeated. If the third and fourth plays are the same, surely there is occasion for suspicion on the part of a prudent man. -- Cardano, Girolamo (1501 - 1576) == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
>But that, precisely, was my point: Arrays *and* hashes. If there is more than >one plural whatzitz, then why can't there be more than one singular whatzitz? >(and don't say, "because plural *means* more than one" :-). If having a >filehandle character would make the code clearer, then let's do it. No: lists are the plural whatzitzes, containing zero or more singular whatzitzes. They are ordered. Arrays hold lists. Hashes, on the otherhand, are *unordered* pluralities containing zero or more look-up-able dualities. --tom
Re: RFC: Filehandle type-defining punctuation
>> No: lists are the plural whatzitzes, containing zero or more singular >> whatzitzes. They are ordered. Arrays hold lists. >I tend to agree with Tom's argument here. open() is kind of funny >anyways. Why couldn't it work like this, similar to FileHandle: > $fh = open $filename; > print $fh "some stuff"; > close $fh; It does, actually: open my $fh, $filename; print $fh "some stuff"; close $fh; Cool, eh? :-) --tom
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 05:31:06PM -0400, Ted Ashton wrote: > But that, precisely, was my point: Arrays *and* hashes. Scalars, hashes, arrays. There's actually more than one type of plural here, gramatically: scalars hashes arrays singulardualplural (Or am I the only one left who did Ancient Greek? :) > (and don't say, "because plural *means* more than one" :-). If having a > filehandle character would make the code clearer, then let's do it. If it would, yes. I'm not convinced that it would. But I do concede that people see filehandles as something conceptually different from an "ordinary" scalar. -- On our campus the UNIX system has proved to be not only an effective software tool, but an agent of technical and social change within the University. - John Lions (U. of NSW)
Re: RFC: Filehandle type-defining punctuation
>Scalars, hashes, arrays. There's actually more than one type of plural here, >gramatically: >scalars hashes arrays >singulardualplural >(Or am I the only one left who did Ancient Greek? :) Nope: pudge and larry, at least. >> (and don't say, "because plural *means* more than one" :-). If having a >> filehandle character would make the code clearer, then let's do it. >If it would, yes. I'm not convinced that it would. But I do concede that >people see filehandles as something conceptually different from an "ordinary" >scalar. What about regexes? $foo = qr/blech/; Should that be /foo instead? :-) Notice how even objects use $, not something else. --tom
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Tom Christiansen, > > What about regexes? > > $foo = qr/blech/; > > Should that be /foo instead? :-) > > Notice how even objects use $, not something else. <*chuckle*> Ok, point conceded. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == The different branches of Arithmetic -- Ambition, Distraction, Uglification, and Derision. -- Carroll, Lewis == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
If the prefix-less form of filehandles was absent from Perl 6, I would be far less enthusiastic about my RFC. I agree; they're a kind of scalar. (Just occurred to me that one could view the % prefix of hashes as denoting a key-value pair by virtue of looking like two o's separated by a divider. Never seen this interpretation before, though.) -- Peter Scott Pacific Systems Design Technologies
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 02:51:20PM -0400, John Porter wrote: > Peter Scott wrote: > > Filehandles should use C<*> as a type prefix if typeglobs are eliminated. > I missed previous discussion of this (if there was any), > but it's an idea I've already thought about. > It has my vote, fwiw. I have to say I prefer the "filehandles are one thing -> we do the work needed to make them work with a $ prefix" idea that (if I understood correctly), tom was proposing. It already almost works with stuff like IO::File, we just need to get rid of the OO part. It changes less than having every existing script that uses typeglobs behave very strangely - even more so than if we just removed typeglobs. I'd also like some 'what are you' introspection I can do on all scalars, on a more formal basis than 'ref'. Either an expansion of the 'ref' functionality to cover filehandles, or a more general system... (said in ignorance of the internals[1], just on the Be-Nice-If logic). [1] of course we don't _have_ internals yet, so that's not a problem.
Re: RFC: Filehandle type-defining punctuation
Peter Scott writes: : If the prefix-less form of filehandles was absent from Perl 6, I would be : far less enthusiastic about my RFC. I agree; they're a kind of scalar. In fact, they're a kind of object. : (Just occurred to me that one could view the % prefix of hashes as denoting : a key-value pair by virtue of looking like two o's separated by a : divider. Never seen this interpretation before, though.) Sorry, beat you to it, barely. Camel III, page 10: (If you look carefully at the % character, you can see the key and the value with a slash between them. It may help to squint.) Actually, that was one of the reasons I picked % in the first place. Larry
Re: RFC: Filehandle type-defining punctuation
>If the prefix-less form of filehandles was absent from Perl 6, I would be >far less enthusiastic about my RFC. I agree; they're a kind of scalar. >(Just occurred to me that one could view the % prefix of hashes as denoting >a key-value pair by virtue of looking like two o's separated by a >divider. Never seen this interpretation before, though.) < Camel: Since the keys to a hash are not automatically implied by their position, you must supply the key as well as the value when populating a hash. You can still assign a list to it like an ordinary array, but each I of items in the list will be interpreted as a key and a value. Since we're dealing with pairs of items, hashes use the funny character C<%> to mark hash names. (If you look carefully at the C<%> character, you can see the key and the value with a slash between them. It may help to squint.) --tom
Re: RFC: Filehandle type-defining punctuation
>I'd also like some 'what are you' introspection I can do on all scalars, on >a more formal basis than 'ref'. Either an expansion of the 'ref' functionality >to cover filehandles, or a more general system... What do you mean, "formal"? ref() has always been a de facto typeof operator, no? open my $fh, "< /etc/motd"; print ref $fh GLOB --tom
Re: RFC: Filehandle type-defining punctuation
At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote: >ref() has always been a de facto typeof operator, no? > > open my $fh, "< /etc/motd"; > print ref $fh >GLOB Can we make that IO in P6...? -- Peter Scott Pacific Systems Design Technologies
Re: RFC: Filehandle type-defining punctuation
Peter Scott writes: : At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote: : >ref() has always been a de facto typeof operator, no? : > : > open my $fh, "< /etc/motd"; : > print ref $fh : >GLOB : : Can we make that IO in P6...? Maybe, but it might be some class derived from an IO object, depending on how we decide to do things. Larry
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 06:28:47PM -0600, Tom Christiansen wrote: > >I'd also like some 'what are you' introspection I can do on all scalars, on > >a more formal basis than 'ref'. Either an expansion of the 'ref' functionality > >to cover filehandles, or a more general system... > What do you mean, "formal"? ref() has always been a de facto typeof > operator, no? > open my $fh, "< /etc/motd"; > print ref $fh > GLOB Doesn't print 'GLOB' for me, but that's because a lot of real-world systems haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause), and I'm moving and don't have access to my development machine, so I don't have access to anything later than 5.004_04. To quote the docs: perldoc -f ref on a 5.004_04 install: --cut-- If the referenced object has been blessed into a package, then that package name is returned instead. You can think of ref() as a typeof() operator. --cut-- Which does tend to support your point... although I'd argue ref is at least tragically misnamed... ref claims to examine my EXPR, return true if it's a reference, and maybe give me some more information about that reference. (perlfunc in 5.004_04). The problem is the idea that the main interesting thing to examine has been references. Filehandles don't intuitively look like references to me. They don't refer to something else within perl I might hypothetically manipulate directly (I speak of how I envision perl6, if it turns out vaguely similiar to how we're discussing). If $foo is to be a filehandle, it has to be a new type of value we can load into a SV. And it feels like it would be making a mockery of something designed to tell me about references (ref), to let it keep the same name and have it tell me about that too. On the one hand, we could let people see what's _really_ in their scalars, if they want, on the third hand, do we really want to think about that? Part of the problem is that I _really_ don't want to have to do OO programming to manipulate filehandles. I dunno, it's 2am, and the screen is drifting a bit, maybe this will give someone ideas.
Re: RFC: Filehandle type-defining punctuation
> No: lists are the plural whatzitzes, containing zero or more singular > whatzitzes. They are ordered. Arrays hold lists. I tend to agree with Tom's argument here. open() is kind of funny anyways. Why couldn't it work like this, similar to FileHandle: $fh = open $filename; print $fh "some stuff"; close $fh; -Nate
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote: > I tend to agree with Tom's argument here. open() is kind of funny > anyways. Why couldn't it work like this, similar to FileHandle: > >$fh = open $filename; Testing for failure. It's a basic tenet that system calls can be tested for success and failure by their returned truth values. I believe we should keep this. system() is the warty exception. -- A bug in the code is worth two in the documentation.
Re: RFC: Filehandle type-defining punctuation
On Thu, 3 Aug 2000, Simon Cozens wrote:
> On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote:
> > I tend to agree with Tom's argument here. open() is kind of funny
> > anyways. Why couldn't it work like this, similar to FileHandle:
> >
> >$fh = open $filename;
>
> Testing for failure. It's a basic tenet that system calls can be
> tested for success and failure by their returned truth values. I
> believe we should keep this.
>
Except that you can test for failure by checking to see if $fh is defined.
This is how IO::File does it
$fh = new IO::File("< $filename");
and it returns undef on failure.
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
Re: RFC: Filehandle type-defining punctuation
At 10:36 AM 8/3/00 +0900, Simon Cozens wrote: >On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote: > > I tend to agree with Tom's argument here. open() is kind of funny > > anyways. Why couldn't it work like this, similar to FileHandle: > > > >$fh = open $filename; > >Testing for failure. It's a basic tenet that system calls can be >tested for success and failure by their returned truth values. I >believe we should keep this. Um, what stops open returning undef on failure (and setting $!), so I could do $fh = open $filename or die "open $filename failed: $!\n"; -- Peter Scott Pacific Systems Design Technologies
Re: RFC: Filehandle type-defining punctuation
>Except that you can test for failure by checking to see if $fh is defined. Let your true be true and your false be false. open($fh, "<", $filename) || die; --tom
Re: RFC: Filehandle type-defining punctuation
>Doesn't print 'GLOB' for me, but that's because a lot of real-world systems ^^ >haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause), If you look at it, you'll notice that "real" is here being used as something of a pejorative, and, as such, can become a negative flash word and so make people tune out of what's being said. Consider: A *real* skateboarder doesn't care about snow in his face. Man, you sure need a *real* girlfriend. Once you get a *real* job, you'll understand these matters. Like, why don't you have a *real* car? It's not as though Lower East Peoria's a *real* city, you know. At a *real* school, that would never fly. The *real* world has more important concerns to occupy its time. Your use of "real" clearly falls into this pattern. Every time someone uses "real" in that way, what they're actually doing is putting somebody else down by disparagement. As soon as you come to see this usage for what it is, it will rankle you forevermore. Just something to be on guard against. One might try to find a less offensive term--unless, of course, you meant to offend. --tom
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 08:00:57PM -0600, Tom Christiansen wrote: > >Doesn't print 'GLOB' for me, but that's because a lot of real-world systems > ^^ > >haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause), > If you look at it, you'll notice that "real" is here being used as > something of a pejorative, and, as such, can become a negative flash > word and so make people tune out of what's being said. It was intended to come out more as "as a matter of current fact, it is inconvenient for me to verify the behaviour of the code you post". Apologies if any offense was caused.
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Tom Christiansen, > >Doesn't print 'GLOB' for me, but that's because a lot of real-world systems > ^^ > >haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause), > > If you look at it, you'll notice that "real" is here being used as > something of a pejorative, and, as such, can become a negative flash > word and so make people tune out of what's being said. > > Consider: > > A *real* skateboarder doesn't care about snow in his face. > Man, you sure need a *real* girlfriend. > Once you get a *real* job, you'll understand these matters. > Like, why don't you have a *real* car? > It's not as though Lower East Peoria's a *real* city, you know. > At a *real* school, that would never fly. > The *real* world has more important concerns to occupy its time. > > Your use of "real" clearly falls into this pattern. > > Every time someone uses "real" in that way, what they're actually > doing is putting somebody else down by disparagement. As soon as > you come to see this usage for what it is, it will rankle you > forevermore. > > Just something to be on guard against. One might try to find a > less offensive term--unless, of course, you meant to offend. Tom, Thanks for the advice. Would "production" have been less likely to offend than "real-world"? Neither offended nor intending offense, Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == "Alice laughed: "There's no use trying," she said; "one can't believe impossible things." "I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast." -- Carroll, Lewis == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
> Thanks for the advice. Would "production" have been less likely to offend >than "real-world"? Perhaps. Or "conservative". Or "cautious". Or "paranoid". :-) --tom
Re: RFC: Filehandle type-defining punctuation
> Um, what stops open returning undef on failure (and setting $!), so I could do > > $fh = open $filename or die "open $filename failed: $!\n"; Exactly. You don't lose anything because open() will still return "true" (a handle) or "false" (undef). -Nate
Re: RFC: Filehandle type-defining punctuation
Tom Christiansen wrote: > > >Except that you can test for failure by checking to see if $fh is defined. > > Let your true be true and your false be false. > > open($fh, "<", $filename) || die; > > --tom Not sure I agree with that. I think one point of confusion / perceived difference between filehandles, open(), and basically every other builtin is that all the others *return* what you want. For ex, you call grep as: (@results) = grep /^$/, @file; It would be pretty strange to call it as: grep @results, /^$/, @file; But that's just what open() does! It says "put the handle variable you want to modify here, and I'll screw with its value if I can open this file". I'd rather it be more consistent, instead saying "give me the file you want to open, and I'll return a handle or undef". This seems more Perl-consistent to me: @results = grep /^$/, @file; ($first) = split ':', $line; $handle = open $filename; $object = new Class; Since we're ripping Perl 6 apart, and one thing I've heard widely mentioned is internal consistency, this seems to me to be worth considering. Not sure if it's RFC-worthy in its own right or not, but I can see many benefits from this approach. Unless I'm missing something, I don't see the benefit of a "strictly true" return code, unless you're doing something like this: die unless (open($fh, "<$filename") == 1); In which case egads! -Nate
Re: RFC: Filehandle type-defining punctuation
>Not sure I agree with that. I think one point of confusion / perceived
>difference between filehandles, open(), and basically every other
>builtin is that all the others *return* what you want.
Think of all the {file,dir}handle syscalls. They don't do that.
They autoviv an object.
--tom
Re: RFC: Filehandle type-defining punctuation
>Not sure I agree with that. I think one point of confusion / perceived >difference between filehandles, open(), and basically every other >builtin is that all the others *return* what you want. tie and bless and chop and chomp also all act upon their argument(s). Just to name a few. bless has the nice side effect of returning it, too, but the rest are probably subject to your confusion issue. --tom
Re: RFC: Filehandle type-defining punctuation
Tom Christiansen writes:
: >Not sure I agree with that. I think one point of confusion / perceived
: >difference between filehandles, open(), and basically every other
: >builtin is that all the others *return* what you want.
:
: Think of all the {file,dir}handle syscalls. They don't do that.
: They autoviv an object.
Yes, but then each of those has to be explained specially. People
*expect* assignment to "autovivify", as it were. But open() et al
are essentially a 3rd syntax for constructors, and that's about one
syntax too many, give or take a few.
Larry
Re: RFC: Filehandle type-defining punctuation
Tom Christiansen wrote:
>
> >Not sure I agree with that. I think one point of confusion / perceived
> >difference between filehandles, open(), and basically every other
> >builtin is that all the others *return* what you want.
>
> tie and bless and chop and chomp also all act upon their argument(s).
> Just to name a few. bless has the nice side effect of returning it,
> too, but the rest are probably subject to your confusion issue.
Point taken, I did actually think of most of these. The difference is
all of these return something still:
$object = tie %hash, $class;
$chopped = chop($var);
$chomped = chomp($var);
$ref = bless {}, $class;
Now, one could argue the following. You could spruce up open() so it
acted more like tie. I could see this adding a lot of functionality:
$object = open($fh, "<$filename") or die;
You could ignore the $object just like with tie (maybe in 90% of your
calls), but if you chose to use it you would have direct access to, say:
$object->autoflush;
$object->untaint;
Thus, you have the "same old open()" for those who like it, but with the
added functionality of generating a FileHandle-esque object.
-Nate
Re: RFC: Filehandle type-defining punctuation
> Yes, but then each of those has to be explained specially. People > *expect* assignment to "autovivify", as it were. But open() et al > are essentially a 3rd syntax for constructors, and that's about one > syntax too many, give or take a few. I agree with this. I think of open() a lot more like a new() than like a chop(), personally. -Nate
Re: RFC: Filehandle type-defining punctuation
On Wed, 2 Aug 2000, Nathan Wiger wrote: > Tom Christiansen wrote: > > > > >Not sure I agree with that. I think one point of confusion / perceived > > >difference between filehandles, open(), and basically every other > > >builtin is that all the others *return* what you want. > > > > tie and bless and chop and chomp also all act upon their argument(s). > > Just to name a few. bless has the nice side effect of returning it, > > too, but the rest are probably subject to your confusion issue. > > Now, one could argue the following. You could spruce up open() so it > acted more like tie. I could see this adding a lot of functionality: > >$object = open($fh, "<$filename") or die; > > You could ignore the $object just like with tie (maybe in 90% of your > calls), but if you chose to use it you would have direct access to, say: > >$object->autoflush; >$object->untaint; > > Thus, you have the "same old open()" for those who like it, but with the > added functionality of generating a FileHandle-esque object. > I think you'll find that the autovivified $fh in the above open() already acts as an object. open my $fh, "autoflush; my $line = $fh->getline; works fine for me on perl5.6.0 so long as IO::Handle has been "use"d. In fact, if IO::Handle is not avialable perl5.6.0 currently complains: Can't locate object method "autoflush" via package "IO::Handle" at ./test.pl line 5. It seems that this issue is definitely worth a quick RFC - something like "proposal to return filehandles from open/opendir rather than supply as arguments". Whether this should be extended to chomp et al is, I believe, another issue since they are modifying the contents of a variable whereas open is overwriting. -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
Re: RFC: Filehandle type-defining punctuation
>Point taken, I did actually think of most of these. The difference is
>all of these return something still:
> $object = tie %hash, $class;
> $chopped = chop($var);
> $chomped = chomp($var);
> $ref = bless {}, $class;
I'd've written that more like
$data_axed = chop($var);
$charcount = chomp($var);
Or something. People really do find those two functions confusing.
Is this something we'd like to address by having versions that don't
take LVALUES?
Then again, I like the symmetry here:
while ($data = chop $string) { }
while ($item = pop @array) { }
But people always think of it as working
$newstring = chomp $oldstring;
where $oldstring is untouched, analogous to nearly all the
other functions, like
$toward_zero = int $floating_number;
--tom
Re: RFC: Filehandle type-defining punctuation
On Thu, Aug 03, 2000 at 06:27:13AM -0600, Tom Christiansen wrote:
> >It seems that this issue is definitely worth a quick RFC - something
> >like "proposal to return filehandles from open/opendir rather than supply
> >as arguments".
>
> What about the pids that come back from begotten processes, as in
>
> open(FILTER, "| cat -v | sort | lpr")
> or
> open(MESELF, "|-")
The suggestion was the open() return a filehandle object, so may
I suggest
$fh = open("| cat -v | sort | lpr") or die ;
$pid = $fh->pid;
Graham.
Re: RFC: Filehandle type-defining punctuation
>The suggestion was the open() return a filehandle object, so may
>I suggest
> $fh = open("| cat -v | sort | lpr") or die ;
> $pid = $fh->pid;
Let's see how that plays out with pipe open:
if ($fh = open("| cat -v | sort | lpr")) {
print $fh "stuff\n";
} else {
die "can't start pipeline: $!";
}
or more simply
$fh = open("| cat -v | sort | lpr") || die;
print $fh "stuff\n";
or even
for $fh (open("| cat -v | sort | lpr")) {
print $fh "stuff\n";
close $fh;
}
Now with fork open:
if ($fh = open("|-")) {
if ($fh->pid) {
print $fh "stuff\n";
}
else {
$data = readline $fh;
exit;
}
} else {
die "can't start pipeline: $!";
}
Except that I hate the tiny case at the bottom, as it requires
deep nesting. Factoring it out reduces the McCabe number.
$fh = open("|-") || die "can't start pipeline: $!";
if ($fh->pid) {
print $fh "stuff\n";
} else {
$data = readline $fh;
}
I think I'd prefer that ->pid return 0 only to the child of a fork,
but undef on a handle that were not the product of a fork, irrespective
of direction.
Some related issues:
1) Did Larry or did he not mention something about dealing with
indirect object more cleanly?
2) What if any reasonable use could be put to a list context
return from open(), or from ->pid()?
3) Isn't it about time to start saving the string argument to open?
$fh = open("< /etc/motd");
print $fh->filename;
print $fh->mode;
print $fh->fileno;
4) This may become interesting for fdopens and dups.
$fh = open("<=STDIN");
$fh = open("<&=STDIN");
Oops, what about
$fh2 = open("<=$fh1")
that fails. Maybe
$fh2 = open("<=", $fh1)
or
$fh2 = open($fh1->mode . "=", $fh1)
or more clearly
$fh2 = $fh1->dup;
--tom
Re: RFC: Filehandle type-defining punctuation
On Thu, Aug 03, 2000 at 07:11:00AM -0600, Tom Christiansen wrote:
> $fh = open("|-") || die "can't start pipeline: $!";
>
> if ($fh->pid) {
> print $fh "stuff\n";
> } else {
> $data = readline $fh;
> }
>
> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.
Seems reasonable.
> Some related issues:
>
> 1) Did Larry or did he not mention something about dealing with
>indirect object more cleanly?
Is that a related question ? please expand.
> 2) What if any reasonable use could be put to a list context
>return from open(), or from ->pid()?
Personally I would not like context to be introduced to open(). As
to ->pid I am not sure what you would return if it was context
sensative.
> 3) Isn't it about time to start saving the string argument to open?
> $fh = open("< /etc/motd");
> print $fh->filename;
> print $fh->mode;
> print $fh->fileno;
seems reasonable. I assume mode would return one of '<' '>' '>>'
and would would have something like $fh->type to return 'pipe','socket','file' etc.
> 4) This may become interesting for fdopens and dups.
>
> $fh = open("<=STDIN");
> $fh = open("<&=STDIN");
>
> Oops, what about
>
> $fh2 = open("<=$fh1")
>
> that fails. Maybe
>
> $fh2 = open("<=", $fh1)
>
> or
>
> $fh2 = open($fh1->mode . "=", $fh1)
>
> or more clearly
>
> $fh2 = $fh1->dup;
I think that would be much better.
Graham.
Re: RFC: Filehandle type-defining punctuation
If the file handle becomes an object, they'd be available via member functions of the object for those that are curious, would they not? And if it is less than an object, a function could be provided to obtain a pid from a handle. Tom Christiansen wrote: > >It seems that this issue is definitely worth a quick RFC - something > >like "proposal to return filehandles from open/opendir rather than supply > >as arguments". > > What about the pids that come back from begotten processes, as in > > open(FILTER, "| cat -v | sort | lpr") > or > open(MESELF, "|-") > > --tom -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC: Filehandle type-defining punctuation
Larry Wall wrote: > > Sorry, beat you to it, barely. Camel III, page 10: > > (If you look carefully at the % character, you can see the key > and the value with a slash between them. It may help to squint.) If I squint one way, I see an "H"; and if I squint another way, I see "a/a"! -- John Porter
Re: RFC: Filehandle type-defining punctuation
> I'd've written that more like
>
> $data_axed = chop($var);
> $charcount = chomp($var);
>
> Or something. People really do find those two functions confusing.
> Is this something we'd like to address by having versions that don't
> take LVALUES?
I don't know. It is true that this is somewhat confusing.
> But people always think of it as working
>
> $newstring = chomp $oldstring;
>
> where $oldstring is untouched, analogous to nearly all the
> other functions, like
Yeah, you're right. Again, it is confusing. However, there are some
benefits to the atomic version(s):
while() {
chomp; # would have to be $_ = chomp
($user, $pass) = split ':';
}
When you use defaults alot, it all seems really well designed. But if
you like to use your own values for $lines, it is more confusing.
I don't know of an easy solution. I don't think we should touch chomp or
chop. Maybe someone should write a module that offers alternate versions
for those that want them?
use NonAtomicChomp qw(chomp);
$newstring = chomp $oldstring;
(No, I don't think this is a good idea :-).
-Nate
Re: RFC: Filehandle type-defining punctuation
> The suggestion was the open() return a filehandle object, so may
> I suggest
>
>$fh = open("| cat -v | sort | lpr") or die ;
>$pid = $fh->pid;
I like. I'll add it.
Version 2's gonna be *huge*...
-Nate
Re: RFC: Filehandle type-defining punctuation
> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.
Great analysis. I think this sounds like an excellent idea.
> Some related issues:
>
> 1) Did Larry or did he not mention something about dealing with
>indirect object more cleanly?
Maybe clarify this just a little. I don't think I was present for this
discussion.
> 2) What if any reasonable use could be put to a list context
>return from open(), or from ->pid()?
This one's still in pre-pre-pre-alpha, but I could forsee stuff like
"type"-specific data, depending on the class. For an HTTP object, maybe
the HTTP Status, Content-Type, Content-Length? I.e., stuff that would be
in objects for those that don't want objects.
Or maybe something else. I like the possibilities but I haven't
attempted to firm anything up.
> 3) Isn't it about time to start saving the string argument to open?
> $fh = open("< /etc/motd");
> print $fh->filename;
> print $fh->mode;
> print $fh->fileno;
Yes, yes, and yes!
> 4) This may become interesting for fdopens and dups.
>
> $fh = open("<=STDIN");
> $fh = open("<&=STDIN");
Yeah, this is going to need a little thought...see my next email...
> or more clearly
>
> $fh2 = $fh1->dup;
Yeah! That's cool.
-Nate
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Nathan Wiger, > I don't know of an easy solution. I don't think we should touch chomp or > chop. Maybe someone should write a module that offers alternate versions > for those that want them? How often does the return value from chomp or chop get used? The confusion would cleared up considerably, I think, if they didn't return a value. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == One of the endlessly alluring aspects of mathematics is that its thorniest paradoxes have a way of blooming into beautiful theories. -- Davis, Philip J. == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
Ted Ashton <[EMAIL PROTECTED]> writes: > How often does the return value from chomp or chop get used? # Remove possible trailing slash. $file .= $possible_slash if ($possible_slash = chop($file)) ne "/"; Of course, TMTOWTDI. -- Johan
Re: RFC: Filehandle type-defining punctuation
>> Some related issues:
>>
>> 1) Did Larry or did he not mention something about dealing with
>>indirect object more cleanly?
>Maybe clarify this just a little. I don't think I was present for this
>discussion.
That's just the indirect object slot ambuiguity annoyance. See the
OO chapter in Camel3 for a treatment:
=head2 Syntactic Snafus with Indirect Objects
One syntax will often be more readable than the other. The
indirect object syntax is less cluttered, but suffers several
forms of syntactic ambiguity. The first is that the R
part of an indirect object invocation is parsed the same as any
other list operator. Thus, the parentheses of:
enchant $sword ($pips + 2) * $cost;
are assumed to surround all the arguments, regardless of what comes
afterward. It would therefore be be equivalent to this:
($sword->enchant($pips + 2)) * $cost;
That's unlikely to do what you want: C is only being
called with C<$pips+2>, and the method's return value is then
multiplied by C<$cost>. As with other list operators, you must
also be careful of the precedence of C<&&> and C<||> versus
C and . For example, this:
name $sword $oldname || "Glamdring"; # can't use "or" here!
becomes the intended:
$sword->name($oldname || "Glamdring");
but this:
speak $mage "friend" && enter();# should've been "and" here!
becomes the dubious:
$mage->speak("friend" && enter());
Which could be fixed by rewriting into one of these equivalent forms:
enter() if $mage->speak("friend");
$mage->speak("friend") && enter();
speak $mage "friend" and enter();
The second syntactic infelicity of the indirect object form is
that its R is limited to a name, an unsubscripted
scalar variable, or block. Attentive readers will
recall that this is precisely the same list of syntactic items
that are allowed after a funny character to indicate a variable
dereference--for example, C<@ary>, C<@$aryref>, or
C<@{$aryref}>. As soon as the parser sees one of
these, it has its R, so it starts looking for its
R. So these invocations:
move $party->{LEADER}; # probably wrong!
move $riders[$i];# probably wrong!
actually parse as these:
$party->move->{LEADER};
$riders->move([$i]);
rather than what you probably wanted:
$party->{LEADER}->move;
$riders[$i]->move;
The parser only looks a little ways ahead to find the invocant
for an indirect object, not even as far as it would look for a
unary operator. This oddity does not arise with the first
notation, so you might wish to stick with the arrow as your
weapon of choice.
Even English has a similar issue here. Think about the command,
"Throw your cat out the window a toy mouse to play with." If
you parse that sentence too quickly, you'll end up throwing the
cat, not the mouse (unless you notice that the cat is already
out the window). Like Perl, English has two different syntaxes
for expressing the agent: "Throw your cat the mouse" and "Throw
the mouse to your cat." Sometimes the longer form is clearer
and more natural, and sometimes the shorter one is. At least
in Perl, you're required to use braces around any complicated
indirect object.
--tom
Re: RFC: Filehandle type-defining punctuation
>How often does the return value from chomp or chop get used? The confusion
>would cleared up considerably, I think, if they didn't return a value.
Seldom, I think--albeit sufficiently often that you might want the
perl526 translator to have any such found be converted to some kind
of lchop/lchomp simply for compatibility.
Come to think of it, non-lvaluing chomp doesn't solve the most common usage
snafuddle:
while (chomp() { }
--tom
Re: RFC: Filehandle type-defining punctuation
Tom Christiansen <[EMAIL PROTECTED]> writes: > >But that, precisely, was my point: Arrays *and* hashes. If there is more than > >one plural whatzitz, then why can't there be more than one singular whatzitz? > >(and don't say, "because plural *means* more than one" :-). If having a > >filehandle character would make the code clearer, then let's do it. > > No: lists are the plural whatzitzes, containing zero or more singular > whatzitzes. They are ordered. Arrays hold lists. > > Hashes, on the otherhand, are *unordered* pluralities containing zero > or more look-up-able dualities. Unless someone's been playing tricks with Tie, in which case all bets are off. -- Piers
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Tom Christiansen,
> >How often does the return value from chomp or chop get used? The confusion
> >would cleared up considerably, I think, if they didn't return a value.
>
> Seldom, I think--albeit sufficiently often that you might want the
> perl526 translator to have any such found be converted to some kind
> of lchop/lchomp simply for compatibility.
>
> Come to think of it, non-lvaluing chomp doesn't solve the most common usage
> snafuddle:
>
> while (chomp() { }
If we've decided that chomp isn't going to return the clippings, would it not
seem prudent to make
while (chomp())
work like
while ()
(with the expected difference, of course). After all, "while ()" is
special-cased already.
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==
Each problem that I solved became a rule which served afterwards to solve
other problems.
-- Descartes, Rene (1596-1650)
==
Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
Tom Christiansen writes: > perl526 Good grief, Tom! How many versions of Perl ahead of us are you?! Nat :-)
Re: RFC: Filehandle type-defining punctuation
On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote: >If we've decided that chomp isn't going to return the clippings, would it not >seem prudent to make > while (chomp()) > >work like > while () You mean, like, the -l command line switch? (see perlrun) chomp() on input, append newlines on print (though $\). -- Bart.
Re: RFC: Filehandle type-defining punctuation
Nathan Wiger <[EMAIL PROTECTED]> writes: >> Um, what stops open returning undef on failure (and setting $!), so I could do >> >> $fh = open $filename or die "open $filename failed: $!\n"; > >Exactly. You don't lose anything because open() will still return "true" >(a handle) or "false" (undef). You loose one little thing - you have a new scalar (the handle) with open $fh,$filename one can re-use an existing thing to which someone else may have a reference. (Not that that is useful very often.) -- Nick Ing-Simmons
Re: RFC: Filehandle type-defining punctuation
On Sat, Aug 05, 2000 at 08:53:58PM +, Nick Ing-Simmons wrote: > You loose one little thing - you have a new scalar (the handle) > > with > > open $fh,$filename > > one can re-use an existing thing to which someone else may have a reference. > (Not that that is useful very often.) Well perhaps that's what $fh = open $fh; does. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Bart Lateur,
> On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote:
>
> >If we've decided that chomp isn't going to return the clippings, would it not
> >seem prudent to make
> > while (chomp())
> >
> >work like
> > while ()
>
> You mean, like, the -l command line switch? (see perlrun)
>
> chomp() on input, append newlines on print (though $\).
Related, I suppose. Currently 'while ()' means 'while ($_ = )'.
I propose making 'while (chomp())' mean
while () {
chomp;
. . .
]
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
==
For a physicist mathematics is not just a tool by means of which phenomena
can be calculated, it is the main source of concepts and principles by means
of which new theories can be created.
-- Dyson, Freeman
==
Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
>It seems that this issue is definitely worth a quick RFC - something >like "proposal to return filehandles from open/opendir rather than supply >as arguments". What about the pids that come back from begotten processes, as in open(FILTER, "| cat -v | sort | lpr") or open(MESELF, "|-") --tom
