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 least (I've never used the latter in > practice, but my little test script seems to work). Not exactly. From perlop: In scalar context, ".." returns a boolean value. The operator is bistable, like a flip-flop, and emulates the line-range (comma) operator of sed, awk, and various editors. Each ".." operator maintains its own boolean state. It is false as long as its left operand is false. Once the left operand is true, the range operator stays true until the right operand is true, AFTER which the range operator becomes false again. It doesn't become false till the next time the range operator is evaluated. It can test the right operand and become false on the same evaluation it became true (as in awk), but it still returns true once. If you don't want it to test the right operand till the next evaluation, as in sed, just use three dots ("...") instead of two. In all other regards, "..." behaves just like ".." does. So it's a bit obscure. :-) Jon
Re: Angle quotes and pointy brackets
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Nov 30, 2004 at 03:03:38PM -0800, Jon Ericson wrote: > : while(<>) {...} > You left out the most important phrase: > > "or whatever we decide is the correctest idiom." I saw that, but I didn't know what to make of it. The Perl 5 idiom is pretty magic and I don't know if it's correcter to make it more or less explicit: for *$ARGV {...} Only I wonder if the magic handle should be called $INPUT or something. > So if, as has been pointed out, @$handle is too much role shear, then we > probably go with something like > > for *$handle {...} > > in which case, if there's no handle, it seems to degrade to > > for * {...} > > which seems amazingly something or other. Lovely? But I'm afraid of extra typing. ;-) It looks like the shell idiom: for f in *; do ...; done Jon
Re: Angle quotes and pointy brackets
Larry Wall <[EMAIL PROTECTED]> writes: > The p5-to-p6 translator will turn any > > while () {...} > > into > > for @$handle {...} Including: while(<>) {...} to for @$ {...} ? Jon
Backticks (was: Angle quotes and pointy brackets)
Matthew Walton <[EMAIL PROTECTED]> writes: > James Mastros wrote: >> Larry Wall wrote: >>> Well, yes, but sometimes the weights change over time, so it doesn't >>> hurt (much) to reevaluate occasionally. But in this case, I think I >>> still prefer to attach the "exotic" characters to the exotic behaviors, >>> and leave the angles with their customary uses. >> ...of which they have plenty already. Backtick has exactly one, and >> not an often-used one at that... I'm fine with axing it. Of course, >> there are a lot more people in the world then just me. > > I'm fine with it too. I use it a fair bit but I think it's important > to have a very clear mark where you're going to an external program Not when you're writing a quick one-liner. Maybe stdout capturing backticks should be disallowed when using strict, but allowed on the command line.[1] Will system return stdout in string context? Jon Footnotes: [1] I wonder if there is a reason for disliking backticks besides it being surprising to C and Java programmers?
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 names. (This is the same reason > I avoid => which not only adds another keystroke beyond , but also has > the dreaded punctuation-key-shift. I'm not arguing this is *better*, > just more convenient for me personally. Or maybe it's just that I prefer > not to hang around too much with shifty characters.) The 'fat-comma' actually saves keystrokes and looks good for creating paired data. From perlop: The => digraph is mostly just a synonym for the comma operator. It's useful for documenting arguments that come in pairs. As of release 5.001, it also forces any word to the left of it to be interpreted as a string. > Having used . for string concats for 10 years, I could adjust to ~ > but good golly is that annoying. Also it does detract from readability > a little. > > $a = "my" . $strings . join(@together) ; > > $a = "my" ~ $strings ~ join(@together) ; Actually using a period to mean "push these things together" rather than "full-stop" always seemed odd to me. I use the concat operator very rarely. I would write the above: $a = "my $strings @together"; (You weren't careful about spaces, but you need to be when using concat. String interpolation is easier to get right the first time. Also I don't think your join is what you want.) If I had to choose between . and ~, I'd take the tilde. I wouldn't mind if it went away altogether, however -- I only use it to simulate function interpolation: $prompt = scalar(getpwuid $>) . "\n\$ "; I'd rather write: $prompt = "&scalar(getpwuid $>)\n\$ "; > I don't mind ~ as the binding operator. It makes me go slower and > think, aha! drive carefully: > > $throttle =~ s/regex ahead/downshift brain/ ; Jon
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 > filename under unix if I'm not mistaken, granted though, this > is about as stupid as naming a script "test" then wondering > why it doesn't do anything when you type "test"...) > > The only way that could work is if programmers could write > handlers for open, so that it could be extended later for > new protocols (see below) Of course all of this has been discussed. (See http://archive.develooper.com/perl6-language-io%40perl.org/, especially RFCs 100 and 14.) Jon
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 realm of heavy AI. As with all strictures, it may be lexically disabled: { no strict 'system'; # I know what I'm doing open STDERR, ">>log/$0"; # if ./log doesn't exist, don't open } # check syscalls again This is the stylistically correct way to ignore the return value of a system call. Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
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(); > $cat->scratch(); > > as to what $dog and $cat are, nor what bark or scratch do. You, as > programmer, need to know elsehow what bark does, and whether it's what > you want. $dog and $cat are objects. $dog can bark and $cat can scratch. The author of the module (Zoo::Animal?) should have documented these methods. > Analogously, for variables of (perl) class "array", you > need to know that "push" is a method, and that > > push var, things; > > does what you know it does. It doesn't help anyone to write "@var". push is _not_ a method. @var is not an object. Perl is not Python with funny variable prefixes. Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
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 > > Thanks! > > > strikes to the very heart of Perl as far as I'm concerned. > > What's wrong with that? There are no rules as to what we are allowed > to discuss. > Well FORTRAN and C are not array languages, and IDL costs N*$1000. Now > there IS Numerical Python if you can put up with indents! > Offensive is a strong word for what is essentially a discussion about > computer lingo syntaces! But this isn't about 'computer lingo syntaces' [sic]. It's about Perl. I think you should consider using Python and a good text editor that takes care of indents for you. There's no more point in discussing this. Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
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 a key which is pointing to an array. How is this: > > it's a list of stuff - but a list of WHAT stuff? The @ is essentially > useless. It's a list of scalars. > >print cars->model; > > > > any clearer? Nicer to look at? Maybe for some. Not for me, I like the > > yep. yep, and easier to teach. See my sig. Try to make knowing easy even at the cost of making learning hard. > > former. Maybe it doesn't let you know exactly what you're getting, but > > you're a lot closer. And this: > > > >print "Welcome back, $fullname, to $website!\n"; > > > > is MUCH better than this: > > > >print "Welcome back " . fullname . " to " . website . "!\n"; > > I agree. That's why I believe in retaining the $. The distinction between > variable and non-variable is still useful. And I think the distinction between a variable and a list of variables is still useful as well. > > Not true!! Only $scalars can hold objects. Now, @arrays and %hashes can > > hold groups of objects, but only $scalars can hold objects. > > "Groups" is a meaningless concept. You have particular objects which store stuff. > Is an image of a distant galaxy singular (one image) or plural (ten zillion pixels). That depends. Do you want to think about a galaxy or a collection of pixels? > My argument, based on my practical experience, is that all the @% are essentially > useless now. Then your practical experience is radically different than mine. > > To summarize, you should read RFC's 49, 73, 28, and the link to TomC's > > email I sent you. These address the real problems, and not the symptoms. > > Yes. And I read TomC's stuff on those lines at least 6 years ago. Which > was why I got annoyed. What does that have to do with anything? What has changed in the last six years that renders these concepts obsolete? > The point remains - why treat hashes and arrays as special prefix types? > It just confuses the language to have to use $ for one kind of collection > and @ for another. Why not let @ be used for other types of collections? > ok we could use @ for everything - but @ implies 1D ness. Why? (Answer: C) Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
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 > > (err... speakers). Why not change @x so that it can represent other > > types of arrays? For instance: > > > > my @x;# standard Perl array > > my @y[2, 3]; # 2x3 matrix (syntax guess) > > my FIFO @z; # FIFO stack (another guess) > > or one could just *use* english plurals... > > my $speaker = 'Jim'; > my $speakers = ('Fred','Bill','Sally','Betty'); > > my $male_speakers = $speakers[0:1]; # If perl supported this style of range - see >RFC coming soon > > # BUT: > > my $image = read_huge_2d_list_of_numbers('file'); > > my $favorite_pixels = $image[10:20,50:100]; > my $best_pixel = $image[11,55]; 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 strikes to the very heart of Perl as far as I'm concerned. Judging from your posts, you use perl largely in conjunction with PDL [1]. As I understand the situation, PDL uses objects (blessed scalar references) to manipulate arrays because the standard perl array is inadequate for the task. Therefore, in your experience '@' is only used for a limited, rarely needed array and '$' for a wide variety of useful arrays. Hence this RFC. It seems to me that you could have picked a different slant on this RFC. Instead of forcing Perl to look like PDL, you could have proposed that perl allow PDL to look like Perl. PDL wouldn't exist if there wasn't something about Perl that people love. Otherwise, they would be working on FORTRAN or C or IDL. If perl can make another group of people happy, so much the better. But you have to realize that this change would make a large number of people miserable. Could you rework this RFC to be a pragma? Or propose making @ work with other types of arrays? Or withdraw it? The current form is offensive to me (and I suspect many other perl programers as well). [1] "PDL (``Perl Data Language'') gives standard Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing." -- <http://pdl.perl.org>) Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
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? Rather > since there are infinitely many kinds of variable let's take the perl6 > opportunity to make things simple and just use C<$x> for everything. 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 (err... speakers). Why not change @x so that it can represent other types of arrays? For instance: my @x;# standard Perl array my @y[2, 3]; # 2x3 matrix (syntax guess) my FIFO @z; # FIFO stack (another guess) In other words, make your life easier rather than everyone else's miserable. "We've got a golden opportunity here to turn Perl into whatever on earth we like. Let's not take it." -- RFC 28 Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC 84 (v1) Replace => (stringifying comma) with =>
Damian Conway wrote: >> > When a pair reference is assigned (in)to an array, it remains a >> > single scalar (referential) value. So: >> > >> > @array = ( a=>1, b=>2, 'c', 3 ); >> > >> > assigns four elements (not six) to @array. > The proposed C and C built-ins (or the extended C and > C) would be used on a pair reference: > > print key $array[0];# or perhaps: print keys $array[0]; ^^^ Makes sense Mismatch ^ ^ > print value $array[0]; # or perhaps: print value $array[0]; ^ 's' But what does C do? Or C? Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC 84 (v1) Replace => (stringifying comma) with =>
Perl6 RFC Librarian wrote: > The first component of a pair would be called its C, and the second, it's > C. It is proposed to either extend the semantics of C and > C to allow them to operate of pair references, or else introduce > two new built-ins -- C and C -- to access the components of a pair. > =head2 Pairs and arrays > > When a pair reference is assigned (in)to an array, it remains a single scalar > (referential) value. So: > > @array = ( a=>1, b=>2, 'c', 3 ); > > assigns four elements (not six) to @array. How do we get keys and values out? print $array{a}; # 1 print $array{c}; # undef? 3? print $array[0]; # 1? a? a=>1? print $array[2]; # c print join ',', keys @array; # a,b? a,b,c? print join ',', values @array; # 1,2,c,3? 1,2,3? Or are hash operations syntax errors on @array? print value $array[0]; # 1 print join ',', map {key} @array; # a,b? a,b,,? Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC: println()
[Reply-To set to [EMAIL PROTECTED]] Ed Mills wrote: > > I actually saw this in the newsgroups and thought it was a neat idea. What > about > >println $textvar; > > instead of > >print "$textvar\n"; > > Ever so much easier to read and write, prints the arg and appends \n. You can currently get this behaviour with print if you set $\ = "\n". I expect perl 6 to look more like perl 5 than Pascal. Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: Treating filehandles like strings
[Reply to perl6-language-io as this is an I/O related.] Michael Mathews wrote: > > Here's a thought. Wouldn't this be cool (see below)? The idea is that in > Perl 6 you should be able to read from a file handle one character or one > line at a time (just like you can in Perl 5) BUT if you just go ahead and > use the filehandle, directly, in a scalar context then perl will read it in > as a string most efficiently, and allow you to perform your rgex, or > whatever without creating a temporary variable just to hold the contents of > that file. This is what the angle brackets do currently, unless I misunderstand you. I don't like the no-operator syntax you propose, because it hides the file operation. I'd rather have a filehandle stringify to the filename instead. > open FH, $filepath; > ($found) = FH =~ /pattern/; > print $found; open FH, $filepath; ($found) = =~ /pattern/; # or print =~ /pattern/; print $found; > #or just > > print FH; print ; > #or, for example > > @things = split /delimiter/, FH; @things = split /delimiter/, ; > And how would s// work, I wonder? Hmmm... something to think about! Anyone > one smarter than me (includes nearly all of you) have a thought on this? =~ s/pattern/replacement/; # dies in current Perl Perhaps this behaviour should be changed for files opened '+<'? Jon __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
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