But Tom, that preserves all the white space both before and after the '!'!
Michael's goal is to eliminate the leading white space, although he didnSNIP
'!' bit. So I'm not sure how you'd have written that if you'd have doneSNIP
specification.
Yeah, ok. I still think
# Your stuff that
* Have to use ugly globref syntax to pass them around reliably.
No, you don't. You can use globs. But only if you don't have
prototypes, like sub opt(*).
* Not first-class objects, so you can't subclass them.
That's not a good argument. I can't subclass a number, either, nor
So why not allow undecorated variables a larger existence?
We already have them. You can use a sub name or a package name
where you mean an "undecorated variable". In fact, you can have
things generate/populate new subs or packages as you like it.
use Funny_Business;
frob Funny
What if it's an anonymous stream?
How do you open an anonymous stream?
Me? This way:
local(*HITHER, *THITHER);
pipe(HITHER, THITHER) ..
or, I suppose,
my($hither, $thither);
pipe($hither, $thither) ..
or even
pipe(my $hither, $thither) ..
Why, how do
This is already allowed. It's called "passing in a bareword".
And barewords are just strings. Are you proposing
that "a bareword should now mean a filehandle", so that
copydata(STDIN, STDOUT);
means something different from
copydata('STDIN', 'STDOUT');
or
Method calls should interpolate in double-quoted strings, and similar
locations.
print "Today's weather will be $weather-temp degrees and sunny.";
Would deparse to:
print 'Today\'s weather will be '.$weather-temp().' degrees and sunny.';
So, the - operator is supposed to get expanded
Nathan Wiger writes:
Brainstorming off the top of my head:
sub length (($|@)) {
}
That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative
context coercions.
The only RFC on prototype extensions we have is Andy Wardley's #57.
I suggest you ask him to add this
Frankly, I thought it was absurd when I first wrote it...
but then I looked at again, and now I'm not so sure I dislike it!
=head1 CHANGES
=over 4
=item * Detailed implementation description
=item * Add a new pragma 'varlock' for controlling the concurrencySNIP
=back 4
I too would like C's one-line if/for/while syntax as a matter of
convenience, but I grudgingly admit that Perl's way more than
makes up in unambiguity what it loses in convenience.
You have them, if you want them.
--tom
I find this urge to push exceptions everywhere quite sad.
Rather.
Languages that have forgotten or dismissed error returns, turning
instead to exceptions for everything in an effort to make the code
"safer", tend in fact to produce code that is tedious and annoying.
Read the new KP: "failing
Several OS's Perl supports prefer case insensitive file systems
(obscure ones, like Windows and MacOS ;).
They're broken. We know that.
On top of that, currently "use Shell" and "use shell" both mean to use
SHELL.PM (or shell.pm, Shell.pm, sHeLl.pM) on case insensitive file
systems.
This is the problem that currently here-doc content must be relative to SNIP
indented code.
2 Preserving sub-indentation.
This is not _currently_ a problem. Perl _currently_ preserves indentatiSNIP
the way, that this problem is a problem. If problem 1 were solved by inSNIP
the HERE
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: 5 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 195
Version: 2
Status: Frozen
As I mailed to Nathan Torkington several days ago (without getting
a reply), many people use chop() a lot and
Speaking of failure-mode, all syscalls should return false on failure, not
ever -1. Right now, wait and waitpid work the other way. They should
go the undef vs "0 but true" route that ioctl, fcntl, and sysread take.
--tom
I can't think any reason why POD tags require "\n" instead of /^\s*$/.
Because then you can set $/ = "" and sail through a source file, of course!
--tom
At what point do you feel a new operator is not justified? Why do
we need grep/map, just use for? Why have =, cmp, just use ?:
So what if the man wants
@foo = @bar union @baz;
@foo = @bar intersetcion @baz;
This is a lot more of a direct map than the twiddling with
I'm not understaning your position.
We don't have very long names for function names. Our functions
scan left to right, although our postfix modifiers alter that
picture. And something like "union" or "intersection", long and
alphabetic, certainly looks like a function name.
My position is
We don't have very long names for function names.
s/function/operator/
I like this idea, although not necessarily for the "spurious warnings"
reason.
--tom
However it still doesn't answer how you are able to:
return $true and next;
return $false and next;
return $true and last;
return $false and last;
return $true and redo;
return $false and redo;
BZZZT
You *aren't* able to do that, silly!
However, if you would please please just stop using
I don't want a set representation. I want set operations. And somehow
for this having to add a use statment and who knows what overhead for
what seems to be a simple operation is a pain.
The overhead is not that it should be a module, but rather,
the sillily/evilly inefficient thing that *you*
But a Hash isn't the correct data structure either. It just has some,
of the correct properties.
Whatever.
Perhaps we should add a Set to the toolkit. Basically a hash with
only the keys, no other baggage.
Define "toolkit".
But you still would argue against the operators/functions? Ignoring
So you wouldn't be in favour of:
my Dog $spot;
print defined($spot) ? 'defined' : 'undefined'; # undefined
print $spot-isa('Dog') ? 'Dog' : 'not dog';# Dog;
then?
Bang goes that RFC...
No, I would argue that undef() be changed to uninitialize().
This is infinitely better for
On Wed, Sep 06, 2000 at 06:39:38PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Retire chop().
Awww, does this mean we won't be seeing chip() and chimp() in Perl 6?
'Pends on whether you modulate them.
--tom
Counterproposal: grep, map, etc. define two implicit magic labels
'ACCEPT' and 'REJECT' that behave in the expected way, so you use
($first_small) = grep { ($_ 2) and last ACCEPT } @list.
Reminds me of "next LINE" in perl -p or perl -n.
--tom
Shoot chop. and chomp. Unless you add unchop and unchomp. Parity issue. Like
a language with YES and no NO.
By that criterion, you have zillions of other things to kill.
Just kill then both.
I don't think this will win us friends.
--tom
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote:
Those are not the semantics of print. It returns true (1) if successfSNIP
false (undef) otherwise. You cannot change that. If I write print "0", it
bloody well shan't be returning false.
Oh, why not? Does anybody actu
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper
I am working on an RFC
to allow boolean logic ( and || and !) to apply a number of patterns to
the same substring to allow easier mining of information out of such
constructs.
What, you don't like: :-)
$pattern = $conjunction eq "AND"
? join('' = map { "(?=.*$_)" }
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
I never did figure out why "last" {w,sh,c}ouldn't be made to do
that very thing.
--tom
IMHO Perl should add a plethora of higher-order functions for arrays and
hashes, and from the chatter here I think a lot of people agree.
Make some modules, release them, and see how much they're used. Then
one can contemplate sucking them into the core based upon the success
of those
Has anyone read RFC #11,112,006,825,558,016?
It's rather difficult to keep up with them all, or read them all
retroactively when you miss a few days. It's also hard to grep
them (HTML is the root of all evil). Is there an rsync server that
will dole out the pods for us as needed?
--tom
Hey, waitaminute. That isn't a list in sub fn in the first place; it's
three expressions separated by scalar commas. Why is there no complaint
about useless use of a constant in void context?
$ perl -Mstrict -wle 'sub f{return(3,5,7)} my $x = f()'
$ perl -Mstrict -wle 'my $x = (3,5,7)'
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
exists (sometimes causes autovivification, which affects Ckeys)
That's not technically accurate--exists never causes autovivification.
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking?
Then please explain why scalar(return (1,2,3)) doesn't do what at first
glance it seems it should.
Because X(Y) != Y(X). You should have written "return scalar" if you
wanted to return a scalar.
And for the life of me I can't see how
$x=(1,2, (3,4,fn,6) )
fn ends up in scalar
package main;
sub fn { return (3, 5, 7) }
tie $x, 'MaiTai';
$x = fn;
$ /tmp/foo
STORE: 7
Why don't I see three STOREs?
Because Perl is too clever to bother. :-)
--tom
If you compare a variable that is undefined with something, perl winges.
Perl never whinges unless you turn on warnings.
An undefined value is not equal to a string, it should do the right thing.
Comparing the undefined value against something else--that is, using
undef as though it were
This still leaves the problem of having to count whitespace and having
to change your regex if you reindent your code. In effect, it causes
whitespace to become significant. Bleh.
It's much better to use the Cookbook method: it stands out better.
Please observe.
--tom
Think of it this way: you're asking that when you write
return WHATEVER;
(for various values of WHATEVER) that *sometimes* it's context
dependent, and sometimes it's not. Right now, it always is,
which is more consistent, predictable, and explainable than the
alternative.
Or maybe you're
I've always liked Perl's demo mode:
perl -demo
:-)
--tom
The whole notion of blessing is non-obvious enough already.
It's the benedictory (con)not(at)ion of blessing, not the bless()ing
itself that so confuses people, I think.
It bless() were instead named something like
mark
stamp
label
brand
retype
denote
notate
Here is my suggestion: What if other functions were able to backtrace
context and determine how many arguments to return just like split can?
I have an RFC on that:
RFC 21: Replace Cwantarray with a generic Cwant function
Cwant takes a list of strings that describe
I already proposed that. Benchmarks show that reading a file with
explicit chomp() is easily 20% slower than reading the same file with
implicit chomp(), through the -l command line switch.
And what, pray tell, do you do about the small matter of wanting
to read some files without implicit
If it were possible to assign to the keys of a hash, we'd be
a lot closer to our ideal:
keys(%intersection) = map { exists $set1{$_} ? ( $_ = 1 ) : () } keysSNIP
but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
Can't you do this with with an environment setting?
Shell people seem to think this a normal notion, but it's caused
horrible security flaws in the past. And I couldn't imagine it of
a C compiler, so I don't know why you would do this one.
--tom
Forcing -w on Makes one-liners annoying.
Makes running existing programs
annoying.
We have PERL5OPT
You forgot the con that we've supposed to be "use
i think an environment var might be a good way. if it is set, it is the
file(s) to preload before running your code.
You've got PERL5OPT.
Heck, I bet you could do a cleverness with .perldb, too. :-)
--tom
but that is the user's to set. PERL_PRELOAD
is there for the user to unset.
allows the admin to globally
set (in the system shell rc file) the rc files that perl will load.
And what sorts of things might the admin care to globally set?
--tom
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
i think an environment var might be a good way. if it is set, it is the
file(s) to preload before running your code.
TC You've got PERL5OPT.
but that is
it can be used for system specific @INC paths without
recompiling perl
That's what PERL5LIB is for.
enforcing strict/-w/-T on all scripts, etc.
How are you going to enable -T from this file you're going to eval?
How are you going to enable strict in an unrelated lexical scope?
Why are you
Let me shift gears and instead ask whether anyone thinks this:
$y = ($first, $second) = grep /$pat/, @data;
Returning "5" has any value? If you're going to do this, it seems like
you'd want the number that were really returned (since scalar grep
will give you the total number found
I entreat you to explain to me *anything* that you'd want to tweak
with this that you already can't do right now.
When I need to move Perl files from a default location to a new one. For
example messing with @INC (and its like). THis could be used for example on
a machine that has both
What I am thinking of is a file that, if present and sane (i.e. read-only
root), would be involked by the interpreter just before the users script was
parsed. Looking at your example of things in the config file, well some of
those are the things I would like to be able to get at in the new
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return value?
$x = TERM OP do { BLOCK } OP TERM;
Actually, these are all pretty similar in
Tom Christiansen writes:
However, I really don't want to see 'return' become a kind of 'last'
for do{}. How would I return from a subroutine from within a do loop?
You already can't do that (as it were) from within an eval.
Yes, but 'eval' has the semantics "run this code but don'
Perl supplies an operator for line input - angle brackets. This is no
analogous operator for output. I propose "inverse angle brackets":
"Print this line.\n";
Perl already *has* a print operator: "print". :-)
The problem with what you have there is that it hides the act of
output within
You don't want do have a postfix { ... } if condition. It's evil
I don't see how this is any worse than a postfix while()
Look closer: do { ... } while does not require the reader to
scan down to find out the condition *BEFORE* the loop is
entered. With an if, it does.
Because it hides
Which kind of "difference"?
tr///l # Translate only _l_eading characters matching.
tr///t # Translate only _t_railing characters matching.
With "Only leading" I mean translate from start/end until you find a
character not matching. Then you can do nifty things such as:
tr/\w//dlt # Trim all leading trailing
How would you do:
# Writer insists on blank line between paragraphs, first line indented.
# Publisher insists on one paragraph/line, first word ALL CAPS.
Step 1: Fire the lame publisher. I'm serious. It's amazing
what people tolerate. Some things aren't worth the pane.
{
local $/ = "";
This is the kind of thing that keeps Perl instructors in business...
And Perl out of businesses :-(
More than anything I think the inability to write Csub list DWIMishly
argues that we need it built-in. But we also need a *very* careful design
of the semantics.
I'd like to see from this
Uri Guttman wrote:
TC ($this = $that) =~ s/foo/bar/;
TC for (@these = @those) { s/foo/bar/ }
TC You can't really do those in one step without it.
RFC 164 v2 has a new syntax that lets you do the above or, if you want:
$this = s/foo/bar/, $that;
@these = s/foo/bar/,
My worry is that it seems like this would return
an empty list on success, so:
@foo = chmod 755, "bar", "baz", "quux"
or die "Whoops, died on success!";
This seems to me to go contrary to the way perl tends to work... are
there any other functions (beside system) that
Doesn't dropping the requirement for a terminating ';' make life
harder for the parser?
It doesn't seem like that's a criterion people have been applying
to any of this. Unfortunately.
--tom
Doesn't that tend to lead us in the direction of pack madness where we
end up with yet another 'sub language' within perl. We've already got
pack specifiers and regexen and the 'old' prototyping stuff. I'm not
arguing *against* these things you understand, I'm just vaguely
worried.
As you have
On the other hand, I hardly ever use $_ in main-stream programming. I
always perform:
for my $var ( .. ) { .. }
Certainly I seldom *mention* $_, but I sure use it a lot, as in
for (@array) { s/foo/bar/ }
It's not something I'd like made Law, but I do advise my beginning
students that
You don't want do have a postfix { ... } if condition. It's evil to
have
do {
asd;
asdf;
asdf;
asf;
asdf;
asdf;
sad;
fasdfa;
sdf;
asdf;
asdf;
asf;
asdf;
asd;
as;
Peter Scott wrote:
No-one AFAICT has yet brought up formats, and what would happen to them if
bareword filehandles go the way of the dodo.
Here's some thoughts I've been tooling with. If we take advantage of the
indirect object syntax, we can actually make format into a member
function:
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I'm not sure I find either of
%hash in scalar context should return what scalar(keys(%hash))
currently does.
But %hash-BUCKET_USE() should return what's currently there.
And a simple boolean (read: don't care) use shouldn't waste time
looking for keys, really, but should be internally optimized to do
the current reasonable
I was against the idea of hash context, but I'd love it if:
foreach ($k,$v) (%hash) {
...
}
I'd like for Perl to emit a warning if people try
for (%hash)
or its aliases. That is, if a foreach loops sole content is
a %{...} at compile time, grinch.
--tom
the reason that they're duplicatable with other features, while I want
to drop chop because its main purpose has now been replaced with the
far superior chomp.
Except that chomp() relies upon the ueberglobal $/ variable,
irrespective of the source of the data being chomped.
--tom
Tom Christiansen writes:
But %hash-BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used
I would actualy like to see chop expanded to allow a variable number of
characters to be removed and a sister function to cut the head off. Yes I
know you can do this with substr but sometimes when you want the performance
and need to cut up a string into fields. Lets say the new function is
Still think Cmerge and Cemerge are cuter. :-)
Except that that pair looks like "munge" and "emunge" (and probably
sounds like them too in certain accents :-), which are actually
synonyms of each other. :-(
--tom
That empty list to force the proper context irks me. How about a
modifier to the RE that forces it (this would solve the "counting matches"
problem too).
$string =~ m{
(\d\d) - (\d\d) - (\d\d)
(?{ push @dates, makedate($1,$2,$3) })
}gxl;
$count =
If we want to use uppercase, make these unique as well. That gives us
many more combinations, and is not necessarily confusing:
m//f - fast match
m//F - first match
m//i - case-insentitive
m//I - ignore whitespace
And so on. This seems like
tr///e is the same as s///g:
tr/$foo/$bar/e == s/$foo/$bar/g
I suggest you read up on tr///, sir. You are completely wrong.
--tom
p.s. Has anybody already suggested that we ought to have a nicer
solution to execute perl code inside a string, replacing "${\(...)}" and
"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
mailing list.
The first one doesn't work, and never did. You want
@{[]} and
($foo = $bar) =~ s/x/y/; will never make much sense to me.
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
chomp($line = STDIN);
($foo = $bar) += 10;
($foo += 3) *= 2;
func($diddle_me = $protect_me);
$n =
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
And don't forget:
for (@new = @old) { s/foo/bar/ }
--tom
$x and $y are in the same scope. This is good, but also bad. For one
thing, you can hang yourself real easily if you come from a C background
and expect this to keep stuff private:
$x = 10;
sub square {
($x) = @_;
$x *= $x;
}
$ans = square($x);
print "$x squared is
Tom Christiansen wrote:
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
Ah, the old "If you want Tcl, you know where to
* Using an array of "words" as an alternate list as part of a regex
/match any of (${\join'|',@list}) here/
NT $" = "|"; /@list/ # snicker
Certainly I've written
if (do { local $" = "|"; $var =~ /@any/}) { blah() }
before.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
still use stdin and stdout! :-)
=head1
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
Aha! You fell for one of my pet pieves. You tried to return a lexical in
the same expression were it was declared. That doesn't work. It's not
the same variable. Running it with warnings enabled says:
Grr..
Name
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed by reference.
I keep thinking of a * or a ... to
Basically, it "fixes" the indirect notation by making all of these Do
The Right Thing:
$r = new CGI (@args); # CGI-new(@args)
$r = new(CGI, @args); # CGI-new(@args)
$r = new(CGI @args); # CGI-new(@args)
It's all in the details (I'm sure you see the edge cases already, but
they're
Simpify syntax of Cdo BLOCK by deleting Cdo before the
block and C; after it.
You can't do that. They do different things.
$n = do {
my $sum = 0;
for $i (@array) { $sum += $i }
$sum;
};
versus
$rec = {
FOO = 1.4,
BAR = "red",
};
Have you ever wanted to count the number of matches of a patten? s///g
returns the number of matches it finds. m//g just returns 1 for matching.
Counts can be made using s//$/g but this is wastefull, or by putting some
counting loop round a m//g. But this all seams rather messy.
It's
Simple solution.
If you want to require formats such as m/.../ (which I actually think is a
good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6
enhancement of strictness.
That's like having "use strict" enable mandatory perlstyle compliance
checks, and rejecting the
Next you'll propose that
print EOL;
blah
EOL; print "OK!\n";
should work too, and print "OK!\n" as well.
Yes why not, though it might be bad style.
Because it gains you nothing, and loses much.
--tom
Object-oriented features were added to Perl with version 5, and in many
ways still appear somewhat "tacked on", with perhaps undue respect
for the Old Ways of Perl 4.
[NB: This is not a serious missive.]
Hey, that Perl uses packages for classes, subroutines for methods, and
references for
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
--tom
[I know this is not your quote, but your quotee's quote]
There is obviously no need to modify the behavior of the C operator.
Is one wholly certain of this?
DB1 @c = (1..3)
DB2 @a = @b @c
DB3 x @a
0 0
DB4 x @b
empty array
It's hard to argue that @a now
Right you are. I'm still living in the 20th century :-)
So are all of us -- just give it a few months, though. :-)
--tom
those early perl3 scripts by lwall floating around in /etc were poorly
written. i am glad they are finally out of the distribution.
Those weren't the scripts I was thinking about, and it is *NOT*
ipso facto true that something which uses $ or $` is poorly
written.
--tom
All in all, though, you're right that neither set of features is particularly
well-known/used outside of p5p followers. At least from what I've seen.
Virtually every person I've worked with since 5.6 came out has been surprised
and amazed at the REx eval stuff.
The completely reworked regex
You maybe want to at least SEE ALSO reference the pair of docs by
me and by Tim Bunce about the current state of prototypes.
--tom
101 - 200 of 273 matches
Mail list logo
