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: flip flop 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
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 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 away. What's wrong with putting a
command name at the start of a command, anyway? Note that the
readline operator is not normally subject to this same problem
as its operand is a handle, not a long string.
I would consider this to be bad style:
qq{
...
}; # yuck!
This is what I'd consider good style:
my @output =
map { $_-[0] }
sort { $a-[1] cmp $b-[1] }
map { [$_, expensive_func($_)] } # print original lines
;
(Modified from http://www.perlmonks.org/index.pl?node_id=9108)
The main point of this statement is the Schwartzian Transform, but it
also prints the original lines en passant.
Also, it makes it icky to quote Perl code in mail messages;
see above. :-(
Agreed. Good style would avoid this problem. The example in the
synopsis of this RFC should be:
my $output = "Print this line.\n";
Jon
--
Knowledge is that which remains when what is
learned is forgotten. - Mr. King
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 @%
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 @%
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: Cperl -we '$a[1,1] = 0')
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 @%
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 @%
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 Ckey and Cvalue built-ins (or the extended Ckeys and Cvalues) 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 Ckey $array[2] do? Or Ckeys @array? Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC 51 (v2) Angle brackets should accept filenames a
Chaim Frenkel wrote:
What does
$foo = "filename";# 1
$bar = "another";
$gaz = "filename; # 2
^ add " here
Does #2 get the second line or the first?
$gaz contains the second line. Otherwise this:
while ('filename'){print;};
won't work. This gets a little hairy, I admit.
Can the contain a function?
Of course. Stick any old list there.
Your example seems to indicate that
it can. But if it is hard for me to parse visually, I'm not sure
how easy it would be for the parser.
This is an implemenation detail. On the other hand, I was hoping that
it would be easy for a human parser. Perhaps it only takes some getting
used to. Like the first time I saw something like:
for ($foo){
/pattern/ next;
print join ' ', /pattern_with_groups/;
};
To my eye angle brackets signify input.
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) = FH =~ /pattern/; # or print FH =~ /pattern/; print $found; #or just print FH; print FH; #or, for example @things = split /delimiter/, FH; @things = split /delimiter/, FH; 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? FH =~ 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: 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: 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
