Re: Perl 6 Summary for 2004-12-20 through 2005-01-03

Austin Hastings <[EMAIL PROTECTED]> writes: > s/conses/consensus/g ? I assumed it was a Lisp reference. ;-) Jon

Re: xx Inf

Luke Palmer <[EMAIL PROTECTED]> writes: > Juerd writes: >> What happens to the flip flop operator? Will .. in scalar context >> remain the same? What comes in place of ...? (An adverb?) > Anyway, to answer what I _do_ know, isn't .. exactly the same as ... in > Perl 5? That was my impression, at

Re: s/./~/g

Fred Heutte <[EMAIL PROTECTED]> writes: > A vote against the proposed switches, for an unbearably lazy (ok, > "selfish") reason. Having to use the shift key with any non-alphanumeric > keypress always feels like a lot of extra work. This is why I have long > avoided underscores in variable name

Re: Larry's Apocalypse 1

"Greg Boug" <[EMAIL PROTECTED]> writes: > So open has to parse the string for a URL and magically use > a http protocol? Not sure I like that idea... Granted, from a > programmatical point of view that looks neater... But what > about the case where you have a file called "http:" (a legal > fi

Re: RFC 30 (v4) STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars

"David L. Nicol" wrote: > Nathan Wiger wrote: > >3. There's no way to have them interpolated in strings into > > something potentially useful. > > The string value of a file handle. Hmm. Is it's internal file > descriptor number? Umm... that's the numeric value of a file handle, ri

Re: "Standardization" of Perl IO functions

Nathan Wiger wrote: > This is an idea I've been chewing on for some time. RFC 14 proposes a > new syntax to open(): > >$FH = open dir "/usr/local/bin" or die "Badness: $!"; > > which is far different from the current open(). This is actually a more > flexible and consistent syntax, with a co

Re: RFC 39 (v3) Perl should have a print operator

Tom Christiansen wrote: > Again, I can't *ever* remember wanting a function that did this. Rare things > shouldn't have hard-to-figure-out names. Why do you want it? Debugging or > something? Have you tried tie? I've found myself wanting this operator several times since I wrote the RFC - mos

Re: RFC 39 (v3) Perl should have a print operator

Bart Lateur wrote: > Also, > > print @items; > > should then return join($,, @items).$\ I would want it to return @items: @sorted = sort print @items; I'd prefer a different name (tee?) and keep print as it is. Jon -- Knowledge is that which remains when what is learned is forgott

Re: RFC 39 Perl should have a print operator

Ken Rich wrote: > How about quotes? A quoted lhs expression could mean print. A quoted lhs > expression preceded by a file handle could mean print to filehandle. Have you seen ? > Tom Christiansen's complaint seems irrelevant to me because a print > statement i

Re: RFC 39 (v3) Perl should have a print operator

Bart Lateur wrote: > For input, the handle is marked as a source: > > $data = ; > > In order to be symmetrical, your ousput handle should look and act like > a sink: > > >STDOUT< = $data; > > There. Now it's symmetrical. = $data; is symmetrical. I am considering thi

Re: RFC 39 (v3) Perl should have a print operator

Tom Christiansen wrote: > Perl already *has* a print operator: "print". :-) I think what I really want is a tee operator. > The problem with what you have there is that it hides the act of > output within an arbitrarily long circumfix operator whose terminating > portion is potentially very far

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}

Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors

Perl6 RFC Librarian wrote: > =head2 Cheating Is Still Possible > > Not ignoring the return value is of course no guarantee of doing > anything useful with the return value: > > $so_what++ unless defined fork(); > > But detecting whether 'something useful' is done is squarely in > the re

Re: RFC 39 (v2) Perl should have a print operator

Jonathan Scott Duff wrote: > On Thu, Aug 17, 2000 at 03:30:09PM -0700, Jon Ericson wrote: > > Nathan Wiger wrote: > > >3. Can you support here documents with this syntax? > > > > I haven't thought about this yet, but you can always use print. > >

Re: RFC 129 (v1) Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN

Perl6 RFC Librarian wrote: > The new C<$DEFIN> accomplishes a similar thing, but with > input. Currently, the special <> filehandle acts on one of > two things, either C<@ARGV> or (if C<@ARGV> is > empty). This is not strictly true. <> is shorthand for . ARGV is the special filehandle that ope

Re: RFC 129 (v1) Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN

Perl6 RFC Librarian wrote: > With C<$DEFERR>, all error functions are set to act on it > instead of C<$STDERR> by default. So, the Perl 6 version > of the above is replaced by a single, simple line of code > at the top of your main program: > >$DEFERR = $ERRORLOG unless $have_a_tty; open S

Re: RFC 39 (v2) Perl should have a print operator

Nathan Wiger wrote: > > > >"Print this line.\n"<; > > Some questions: > >1. How do you specify alternate filehandles to output to? > select() doesn't count for the purposes of this question. It's a shortcut, not a replacement. Rumors of select's death are greatly exaggerated. >

Re: RFC 39 (v2) Perl should have a print operator

Nathan Wiger wrote: > We should consider if this *adds value* to Perl 6. If not, we should > start trimming down some RFC's and retracting them. If this RFC presents > a significant win, we should keep it. If not (I personally don't see > one), we should retract it. > > I'm not claiming to be aut

Re: RFC 109 (v1) Less line noise - let's get rid of @%

John Porter wrote: > Mike Pastore wrote: > Highlander variables acknowledge the fact that all variable types (scalar, > array, hash) are simply objects. Objects of different classes, sure; but > still just objects. Not in Perl. > You get no visual help in cases like > > $dog->bark();

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Karl Glazebrook wrote: > Jon Ericson wrote: > > I've spent almost a day trying to come up with a polite response to this > > suggestion. I have started this mail 3 or 4 times but deleted what I > > wrote because it was too sarcastic, angry or dismissive. This RFC >

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Karl Glazebrook wrote: > Nathan Wiger wrote: > > Yeah, and isn't it cool that Perl gives you easy access to using and > > understanding such complex data structures: > > > >print @{ $cars->{$model} }; > > > > That "junk" makes it easy to see that you're derefencing a hashref that > > contains

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Karl Glazebrook wrote: > > Jon Ericson wrote: > > But @ and % provide important context clues (if not to perl than > > certainly for programmers). We could also eliminate the plural case in > > English, but this would be endlessly confusing for native speaker > &g

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Perl6 RFC Librarian wrote: [snip reconstructionist history and newer-is-better fallacy] > I argue in this Brave New World the distinction between C<$x>, C<@x> and > C<%x> are no longer useful and should be abolished. We might want > to use all kinds of array objects, why should @x be special? Ra