>: No. keys() expects something that starts with a %, not
>: something that starts with a &.
>Wow. Now that, that, is lame. You're saying that keys() expects it's first
>argument to begin with a %? Why should it care what it's argumen begins with?
You're just now figuring this out? Really?
>So the internals stay almost the same, but before resorting to die,
>you attempt a cast, if it works you warn that's inefficient under strict,
>and of course in the docs. If I occasionally want to be inefficient, I should
>have the license to do so. But I really don't think it'll be that less
>ef
>But I do agree it would be nice if there were a way to simultaneously
>construct and dereference an anonymous array or list, perhaps something
>like
> @( 1, 2, 3 )
> %( foo => 1, bar => 2 )
>which would be equivalent to
> @{[ 1, 2, 3 ]}
> %{{ foo => 1, bar => 2 }}
>bu
>Other than the issue of semantics (array is not list), I still have not
>seen:
>a) why this is the Wrong Thing
Why what is the wrong thing? Why treating an immutable list
as a mutable array is wrong? Because you can't change the length
of a list -- it doesn't have an AV to update. If you wan
I assure you that the number of people who get compile-time caught
for writing keys or each $x[$i][$j] or pop or push $x[$i][$j] is
*very* large. This is by far the most prevalent error that happens
with data structures in apprentice and perhaps even journeymen perl
programmers. Having the compi
> my %hash = &func();
> print "$_\n" foreach keys %hash;
>To work just like this:
> print "$_\n" foreach keys &func();
>In my, 'pretending to just learn' mode, I don't understand. Perl will assign
>the LIST to the hash in example one, but in example two, it croaks.
A LIST is not a HASH. L
>As a user, I should be able to expect this:
I've decided I don't believe you, because despite having taught a
zillion people Perl, I have never *once* seen the misexpectation
and subsequent error that you're spending so much time complaining
about.
--tom
>There is no documentation that states:
>``keys() just doesn't work on lists and/or arrays, you must use this syntax to
>force that to work:
> @array = keys %{{@array}};
>''
>Or something like that.
keys is documented to take a hash. Likewise, push an array.
This all seems completely obvious
>It doesn't help that Camel II's glossary defines "array" as "A named list
>of values, each of which has a unique key to identify it. In a normal
>array, the key is numeric... In a hash...the key is a string." and seems to
>go to a lot of effort to deprecate "array" in favor of "list" (array
>2) The ability to dump out a variable and all its attached state into
>something that can be loaded in later somewhere else.
To hope to do this completely and correctly is courageous.
my @funx = ();
for my $name (qw/violet purple cream/) {
push @funx, sub {
print "I
>The "www" in e.g., "www.netscape.com" is pronounced, IMO, in
>the same way as other useless, should-be-obvious punctuation.
>It's silent.
Seems like something you should take up with RFC 819, or maybe with
RFC 881, considering that they and their ramifying successors all
seem to be in flagrant
>While I don't know that I'd argue in favor of this feature request, your
>argument against misses the mark here. It's saying, essentially, that the
>difference between "P" and "p" is the same as the difference between -1 and
>1. That, as they say, turns out not to be the case.
>The upper and
>In my consideration, a
>case-insensitive equality check is a rather common operation in Perl
>programs so it deserves its own operator.
That doesn't folllow. We already have a trivial and very obvious
way of doing it that doesn't require that any one learn anything
new that they don't already
>However, consider this in a different light for a moment:
> $a = "MyClass";
> *a = MyClass->generate; # ask for ref back
> $a->blah;
> *a->blah; # use our ref
>Whether or not having to care about your refs is good or bad depends on
>which way you look at it. In one cas
>I'm coming into this a bit late, so forgive me if this is impossible or
>already dismissed, but what about
> print < Attention, dropsied weasel, we are
> launching our team of legal beagles
> straight for your scrofulous crotch.
>
>Unfortunately the quoting on the terminator following << decides the type
>of interpolation; we're missing a way of indicating how to recognize the
>terminator other than an exact match. If we say that we want varia
>I've RFCed making m mandatory on matches, which would remove some
>of the current tokenizing confusion. I'm open to others.
Doesn't seem to be worth it -- there's so much history of
the mass convenience in Perl of being able to write
if (/foo/) { }
or
print if /foo/ && /bar/
>Is it accurate to say that the list of things that would have to be
>addressed is table 3-3 on p. 97 of Camel III (unlabelled table on p. 84 of
>Camel II)?
Well, mostly. (Note that for readline(FH) also is <*.c) for
glob('*.c')). I suppose we could forbid pick-your-own-quotes.
But remember
I've thought about it, and I believe that if were are going to require
that the function be named every time, that is, via:
m//
that you should then just dispense with the slashes and make it a
proper function call:
m()
But then you'll find that "m" is a lame name for a functi
[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?
DB<1> @c = (1..3)
DB<2> @a = @b && @c
DB<3> x @a
0 0
DB<4> x @b
empty array
It's hard to argue
>Split Scalars and Objects/References into Two Types
I do not see how taking something simple and elegant
and making it complicated does anybody any good.
And yes, I did read all of it.
You pretend that a reference is not a "true" scalar.
That's certainly not valid. It obviously is.
You als
>Case ignoring eq and cmp operators
>=head2 Problems with current ways to do it
>Perl currently knows basically two methods for checking of equality of
>strings case-insensitively:
> uc($a) eq uc($b)
> $a =~ /^$b$/i
>and for comparing them one:
> uc($a) cmp uc($b)
>The probably worst about t
>On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
>>It only removes whitespace,
>>and it measures whitespace with tabs=8.
>My editor is set to tabs=4.
So don't do that. :set sw=4 ts=8. I am confident that were Dante
were writing now, he'd reserve a special pit of Hell for those who
>Bart Lateur wrote:
>>
>> Next you'll propose that
>>
>> print <> blah
>> EOL; print "OK!\n";
>>
>> should work too, and print "OK!\n" as well.
>Why not?! This seems like a good thing. ;, #, or \n are all valid
>end-of-lines for here string delimiters. Sounds easy enough
>> Next you'll propose that
>>
>> print <> 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 o
>Well, as I mentioned in another recent parallel thread, if C 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'd like to see every number bundled with a "precision" attribute.
That's not what I call a high-level language feature. People don't
want to think about that, nor about machine-level precision issues.
See REXX.
In fact, I'd rather to see a painless and transparent int->float->bignum
autocon
>Tom Christiansen wrote:
>> >Well, as I mentioned in another recent parallel thread, if C is to
>> >be properly functionalized,
>>
>> Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
>> expressible as functions.This isn't t
>went through the archives about RFC22 "builtin switch statement".
>didn't see any mention of this, thought I'd throw it in there to see
>how it was recieved.
>I was thinking that the switch statement could possibly be expanded
>to also behave as an operator and not just a control statement.
>i.
>>> > * 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! :-)
>=hea
>Tom Christiansen wrote:
>>
>> >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
>>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..
> Na
>How about ALLOWING bareword everything-else? Start having
>filehandles work the way everyone expects them to at first,
>passing as arguments and so forth, without any special treatment?
One could do that, too. Or allow scoped declarations of
unadorned identifiers: this might be the road out o
>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
>
>>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 (be
>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 h
>=head2 Hash Context
>When the result is assigned to a hash, the list returned could be the names
>of the unsuccessfully modified files and their corresponding C<$!> errors.
Um, but we don't have hash context. :-(
--tom
>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
>David L. Nicol wrote:
>>
>>
>> How about ALLOWING bareword everything-else? Start having
>> filehandles work the way everyone expects them to at first,
>> passing as arguments and so forth, without any special treatment?
>How about barewords are always interpreted as function names (by defaul
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
>funct
>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
>I'll second that motion. We already have lots of ways of removing the
>last character of a string if that's what we really need.
But they're slow and hard to read.
--tom
>%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 reasonabl
>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
>I presume that line disciplines will be object-oriented and inherit from
>some base class; therefore a bare chomp will use the line terminator from
>that base class and for the others, you could do something like
>$fh->chomp($line) to do chomping specific to a particular filehandle. Make
>se
>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 c
>> 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 hide
Which kind of "difference"?
>Next, what subset of the set-theory should be implemented. Obviously you
>refer to the basic and / or / xor, but in real practice, the other operators
>can be very useful. Chaining operators (especially with array-based-sets)
>can be a performance nightmare.
Unless you use bitwise operators on
>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 & tra
>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 $/ =
>I'm not arguing in favor of the tr/// hack specifically, but
>gosh, wouldn't it be nice if there were a thwack() builtin that
>stripped leading and trailing spaces?
No. People should learn intrinsic mechanisms with which they can
construct infinitely many beautiful and powerful effects. This
>The most serious obstacle to easy interaction is the impossibility of
>typing multiple line commands to a Perl debugger (see below).
% man perldebug
...
Multiline commands
If you want to enter a multi-line command, such as
a subroutine definition with
> > 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 C 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 measu
>Let's fall back to what we have already:
> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
Read my last letter--the one nobody commented on. What do y
>Bart Lateur wrote:
>>On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>>No. People should learn intrinsic mechanisms with which they can
>>>construct infinitely many beautiful and powerful effects. This empowers
>>>them. Making them le
>I don't care about keys when I'm working with sets, and I don't want to
>have to deal with them.
>Then, if when implementing these new functions in perl6 you choose to
>use an invisible hash table, ok, I don't care, but when writing my perl
>script I don't want to deal with hash tables for arrays
>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 rec
Also: have you looked at what's on CPAN for handling sets?
Here's a casual search result:
Math::Expr::MatchSet Set::Scalar
Math::Expr::VarSet Set::Scalar::Base
ObjStore::SetSet::Scalar::Null
ObjStore::SetEmulation Set::Scalar::Real
Set
> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
What the devil is "array context"? You mean the thing that push expects
for its first argument? Just w
>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 ) : () } keys
>but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
>> keys %HASH = LIST;
>> is really
>> @HASH{ LIST } = ();
>Sure. Would you have any great objection to adding the alternative syntax?
Nope.
--tom
>But, Do you really think that all these ingenuities, to not use another
>term, are really natural and easy to understand to novice programmers ?
Until you start thinking of terms of hashes, you aren't thinking
in Perl. It serves no good to delay this epiphany. Also, remember
that being a "novi
>To be consistent, "scalar list" should return the number of elements.
Says who? $x = ("foo", "bar") produces "bar", not 2.
It's all a big looney tune. "scalar list" makes negative sense.
If you want a count function, write one, but don't pretend that
"scalar list" is such a thing, nor that "s
Bart, until you've read my long message, you're wasting my time.
Please read it.
--tom
The thing is that so far, Perl has survived on extremely simple
variable types:
SCALAR: singular generic values
ARRAY: ordered lists of SCALARs
HASH: unordered association of SCALARs
Sure, you have special-purpose accessors like the "%" operator or
s/// or pop or exists or even v
>I read your message and agree. Not that I liked the idea that much even
>before considering the ramifications. But do you agree that even
>seasoned perlers have trouble anticipating how a list/array is going to
>be converted to a scalar?
A list or array? No, I don't agree. How to predict what
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
>> If you write
>>
>> $burp = LISTIFY( grep {EXPR} @data );
>>
>> What's in the burp?
>By this argument, then why aren't these different?
It depends on whether you think the alpha or beta are
what you want. It's highly unclear why you aren't just
using straight scalar context t
>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 "u
>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 pr
>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 u
>many systems allow for a global/local startup file for various
>reasons. i see a potential use of this in perl but i don't see the
>specific use yet. build it they will use it.
But Perl is not an interactive shell! Can you imagine if a C
compiler allowed arbitrary amounts of text to be pre-inc
>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 an
>>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 dev
>Well, it only does this if it's not something like 'split', then!
Yes, it does "do it" with split. split is defined to do what it
does, how it does it. *This* is the kind of senseless harping that
annoys me, Nathan.
> So it's not 100% consistent.
Wrong: It's 100% consistent with the docume
>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 ve
> > 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 C with a generic C function
>C takes a list of strings that describe aspects of the
>
>For the first part, tchrist posted a nice list of non-overridable
>builtins; running my eye down it, it looks like the gross offenders
>here are:
> glob, print, printf
>I don't know whether this is purely an implementation issue (and so
>lies solely in the domain of perl6-internals) or wh
>Simpify syntax of C by deleting C 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",
};
--tom
I've always liked Perl's demo mode:
perl -demo
:-)
--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 real
>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
> 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 modul
>I see barewords as being whatever the programmer wants them to be,
>as long as he makes it clear what he expects the word to be before using
>it.
I've been known to use:
sub opt(*); # imal quoting! :-)
So I could say if opt(a) sans quoting. But that
breaks for the pseudofuncs like m or s.
>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
>Tom Christiansen wrote:
>>
>> The straightforward way to do that is quite simply:
>>
>> open(FH, "|foocmd thisfoo thatfoo|")
>>
>> or for shell avoidance:
>>
>> open(FH, "|-|", "foocmd", "thisfoo&
>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, "|-")
>Today around 4:30pm, Tom Christiansen hammered out this masterpiece:
>: print <According to current implementation, that has to look like:
> print <<" FOO" =~ /^\s+(.*\n)/gm;
>Unless, of course, you want `xx oo' to be indented
>I thought this problem would've been neatly solved by my proposed:
>print <<<"FOO" =~ s/^ {8}//;
>Attention criminal slacker, we have yet
>to receive payment for our legal services.
>Love and kisses
>FOO
The result of substituting the leading 8 bla
101 - 200 of 332 matches
Mail list logo
