Re: When do named subs bind to their variables? (Re: Questionable scope of state variables ([perl #113930] Lexical subs))

"Father Chrysostomos via RT" wrote on Sat, 07 Jul 2012 18:54:15 PDT: >Thank you. So the bar sub seems to be closing over the name @a (the >container/variable slot/pad entry/whatever), rather than the actual >array itself. >Since I don't have it installed, could you tell me what this does?

Re: When do named subs bind to their variables? (Re: Questionable scope of state variables ([perl #113930] Lexical subs))

sion. --tom From: Damian Conway To:Tom Christiansen CC:Larry Wall Date: Sun, 08 Jul 2012 07:17:19 +1000 Delivery-Date: Sat, 07 Jul 2012 15:19:09 Subject: Re: my subs and state vars In-Reply-To: <22255.1341691089@chthon>

Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)

Darren Duncan wrote on Wed, 24 Aug 2011 11:18:20 PDT: > Smylers wrote: >> Could we have underscores and hyphens mean the same thing? That is, Perl >> 6 always interprets illo-figut and illo_figut as being the same >> identifier (both for its own identifiers and those minted in programs), >> with

UCA and NFC/NFD issues in pattern matching

I have two points. First, this excerpt from Synopsis 6: The :m (or :ignoremark) modifier scopes exactly like :ignorecase except that it ignores marks (accents and such) instead of case. It is equivalent to taking each grapheme (in both target and pattern), converting both to NFD (

Perl6 regexes and UTS#18

Has anybody specifically looked at how Perl6 regexes might map to the various requirements of UTS#18, Unicode Regular Expressions? http://unicode.org/reports/tr18/ I ask because to my inexperienced eye, quite a few perl6isms are *much* better at this than in perl5 obtain, and so I wondered wh

Re: Unicode Categories

>The 'Is' prefix can be used on any property in 5.12 for which there is >no naming conflict. The only naming conflicts are certain of the block >properties, such as Arabic. IsArabic means the Arabic script. InArabic >means the base Arabic block. Personally, I find Is and In unintuitive, >an

Re: Unicode Categories

Patrick wrote: : > * Almost. E.g. isL would be nice to have as well. : : Those exist also: : : $ ./perl6 : > say 'abCD34' ~~ / / : a : > say 'abCD34' ~~ / / : 3 : > They may exist, but I'm not certain it's a good idea to encourage the Is_XXX approach on *anything* except Script=XXX proper

Re: Unicode Categories

Patrick wrote at 12:15pm CST on Wednesday, 10 November 2010: >> Sorry if this is the wrong forum. I was wondering if there was a way to >> specify unicode >> categoriesin >> a regular expression (and hence a grammar), or if there would be

Re: Perl6 and "accents"

> Why isn't that: > /<+ alpha - [A-Za-z]>+ / If you're asking why it's mentioned in the "Update:" section instead of the pattern in question just being rewritten, I don't know. What got me most was the assumption that subtracting A-Za-z from Alphas yielded "accented characters", as though Alpha

Perl6 and "accents"

Exegesis 5 @ http://dev.perl.org/perl6/doc/design/exe/E05.html reads: # Perl 6 / < - [A-Za-z] >+ / # All alphabetics except A-Z or a-z # (i.e. the accented alphabetics) [Update: Would now need to be <+ - [A..Za..z]> to avoid ambiguity with "Texas quo

Re: Amazing Perl 6

· Quoth Larry: ˸ So let’s not make the mistake of thinking something ˸ longer is always less confusing or more official. ⋮ I already have too much problem with people thinking the ⋮ efficiency of a perl construct is related to its length. So you’re saying the Law of Parsimony has its uses… a̲n̲d

Re: Files, Directories, Resources, Operating Systems

In-Reply-To: Message from Mark Overmeer <[EMAIL PROTECTED]> of "Thu, 27 Nov 2008 08:23:50 +0100." <[EMAIL PROTECTED]> >* Tom Christiansen ([EMAIL PROTECTED]) [081126 23:55]: >> On "Wed, 26 Nov 2008 11:18:01 PST."--or, for backwards compatibility, >

Re: Files, Directories, Resources, Operating Systems

In-Reply-To: Message from Darren Duncan <[EMAIL PROTECTED]> of "Wed, 26 Nov 2008 19:34:09 PST." <[EMAIL PROTECTED]> > Tom Christiansen wrote: >> I believe database folks have been doing the same with character data, but >> I'm not up-to-date on th

Re: Smooth numeric upgrades?

On Mon, 06 Oct 2008 at wee small hour of 02:20:22 EDT you, Michael G Schwern <[EMAIL PROTECTED]>, wrote: > Darren Duncan wrote: >>> [2] "Num" should have an optional limit on the number of >>> decimal places it remembers, like NUMERIC in SQL, but >>> that's a simple truncation. >> I dis

Re: Smooth numeric upgrades?

In-Reply-To: Message from Nicholas Clark <[EMAIL PROTECTED]> of "Sun, 05 Oct 2008 22:13:14 BST." <[EMAIL PROTECTED]> > Studiously ignoring that request to nail down promotion and demotion, I'm > going to jump straight to implementation, and ask: > If one has floating point in the mix [and ho

Re: Smooth numeric upgrades?

In-Reply-To: Message from Michael G Schwern <[EMAIL PROTECTED]> of "Sat, 04 Oct 2008 02:06:18 EDT." <[EMAIL PROTECTED]> > Larry Wall wrote: >> The status of numeric upgrades in Perl 6 is fine. It's rakudo that >> doesn't do so well. :) >> >> As another datapoint: >> >> $ pugs -e 'say 2**40'

Re: Allowing '-' in identifiers: what's the motivation?

>I'm still somewhat ambivalent about this, myself. My previous >experience with hyphens in identifiers is chiefly in languages that >don't generally have algebraic expressions, e.g. LISP, XML, so it will >take some getting used to in Perl. But at least in Perl's case the >subtraction conflict is

Re: Exegesis 7: Fill Justification

>On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote: >: That's a *very* interesting idea. What do people think? >I think anyone who does full justification without proportional >spacing and hyphenation is severely lacking in empathy for the reader. >Ragged right is much easier on the ey

Re: == vs. eq

>The IEEE-float-style infinities are quite sufficient for most purposes >One thing I agree is that writing 1..Inf is a *bit* sloppy since the >range operator n..m normally produces the numbers i for which >n <= i <= m while n..Inf gives n <= i < Inf >but I can live with it I could sure

Re: == vs. eq

>Unless I'm very wrong, there are more whole numbers than natural >numbers. An induction should prove that there are twice as many. We're probably having a language and/or terminology collision. By natural numbers, I mean the positive integers. By whole numbers, I mean the natural numbers plus

Re: == vs. eq

>You can define is very easily: two lists are equal if the ith element of >one list is equal to the ith element of the other list, for all valid >indices i. The problem is that you've slipped subtly from a well-known creature, like 1..10, a finite set of ten distinct integers, to a quite a diff

Re: == vs. eq

>When you write: >(1..Inf) equal (0..Inf) >I'd like Perl to consider that false rather than having a blank look >on its face for a long time. The price of that consideration would be to give the Mathematicians blank looks on *their* faces for a very long time instead. Certainly, they'll b

Re: Barewords and subscripts

>Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it >won't be because of the "no barewords" rule. If there were such a rule, I >presume you'd also apply it to the LHS of =>? There is another way to resolve the ambiguity of foo meaning either "foo" or foo() depending on curre

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

>POD, presumably. Or maybe son-of-POD; it would be nice to have better >support for tables and lists. We did this for the camel. Which, I remind the world, was written in pod. ''tom

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

>The problem with XML is that it is so unforgiving; No, the problem is verbosity. ''tom

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

>XML is intrinsically no more or less difficult to write than HTML. Wrong. >Comparing XML to HTML is pointless, however; they are not the same >thing. Wrong. And you only say that because you will not like the answer. Go back to the posted example and count bytes of data versus bytes of met

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

>- Done right, it could be easier to write and maintain Strongly disagree. >- Why make people learn pod, when everyone's learning XML? Because it is simple. It is supposed to be simple. It is not supposed to do what you want to do. In fact, it is suppose to NOT DO what you want to do. >- Pod

Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

>No-one ever did suggest adding « and » to the list of matched delimiters >that q() etc support, did they? :-) I did. >Does Unicode define bracket pairings for character sets? $ grep ^Prop /usr/local/lib/perl5/5.6.0/unicode/Props.txt does not seem very helpful, but this may not be much of a p

Term::ReadKey inclusion

It is unreasonably complicated to do single-character input in a portable fashion. We should therefore include the Term::ReadKey module in the standard distribution. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the indiv

Re: RFC 325 (v1) POD and comments handling in perl

It really is not feasible to relax the pod requirement that pod diretives begin with an equals to allow them to begin with a pound sign as well, for to do so would expose an untold number of programs to unpredictable effects. I also don't really see any advantage. And yes, I'm sure I'm days be

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

Certainly numbers should never be "zero-padded"! Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please

Re: RFC 171 (v3) my Dog $spot should call a constructor implicitly

You also didn't mention that you would have broken the symmetry between my Dog $spot; our Dog $spot; Or that constructors have no (and should have no) set name in Perl. --tom Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

>So what's left? > >print STDERR "Foo"; > >We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go >through. It is? I certainly hope not. It makes as much sense to do that as to force a dollar sign on subroutines. sub $foo { ... } or sub 'foo' { ... } Heck,

Murdering @ISA considered cruel and unusual

>I strongly agree with the opinion that we should try and get away from >special variables and switches in favor of functions and pragmas. >Witness 'use base' instead of '@ISA', 'use warnings', and so on. Huh? Why??? Perl's use of @ISA is beautiful. It's an example of code reuse, because we do

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

Try thinking of it this way: it's only a bareword if it would make use strict whinge at you. Thus, the constructs you cited are all non-uses of barewords, such as in use Foo or require Foo or Foo => 1, or even $x{Foo}. And I have proposed (nonRFC) that Foo->bar() also be not a bareword. Yes, I

my and local

As we sneak under the wire here, I'm hoping someone has posted an RFC that alters the meaning of my/local. It's very hard to explain as is. my is fine, but local should be changed to something like "temporary" (yes, that is supposed to be annoying to type) or "dynamic". Visit our website at http

Re: RFC 143 (v2) Case ignoring eq and cmp operators

This RFC still has silly language that discounts what has been said before. 1) It calls uc($a) eq uc($b) "ugly", despite their being completely intuitive and legible to even the uninitiated. 2) It then proposes "eq/i" without the least blush, despite how incredibly ugly and non-intu

RFC 307 (v1) PRAYER - what gets said when you C something

Goodness, no, don't call it "PRAYER". The blessing is one of corporate approval, not ecclesiastical deprecationem. Please don't piss people off. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you

Re: RFC 303 (v1) Keep C, but make it work.

Don't change "use less" to "use optimize". We don't need to ruin the cuteness. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribut

Better Security support (was: RFC 290 (v1) Remove -X)

The -wd syntax (writeable directory) is nicer than file($file, "wd"). But anyway, there's hardly anything wrong with -w && -d. Don't understand the complaint. One thing I would really like to see is better security support. Look at the Camel-III's security chapter, File::Temp, and the is_safe s

Re: RFC 290 Remove -X

One doesn't remove useful and intuitive syntax just because Mr Bill never put it into MS-BASIC! I merely passingly suggested that there be a use English style alias for these. They are, however, wholly natural to millions of people, and should not be harrassed. (NB: 10 million Linux weenies al

Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins

On the matter of unpack(C4) and the gethost returns, I certainly agree that all pack/unpack ickiness should be hidden away. It's nutty that gethostbyaddr takes a binary address, yet just try to get that with getnetwhatever. See the Net::hostent manpage, where I confess that you still need to do t

Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulous builtins

> grep -l Class::Struct */*.pm Class/Struct.pm File/stat.pm Net/hostent.pm Net/netent.pm Net/protoent.pm Net/servent.pm Time/gmtime.pm Time/localtime.pm Time/tm.pm User/grent.pm User/pwent.pm Please check those out for precedent and practice. Visit our website at http://www.ubswarburg.com This

Re: RFC 259 (v2) Builtins : Make use of hashref context for garrulousbuiltins

On the matter of gcos or gecos, and passwd or pw_passwd, and all that noise, please consult the User::pwent manpage. There's no reason for all those noisy bits. In fact, there had jolly well better be a VERY good reason not to follow my Class::Struct'd modules' name choices, since they were cho

Re: Perl6Storm: Intent to RFC #0101

You suggested: file($file, 'w'); # is it writeable? That's really insane. The goal was to produce code that's legible. That is hardly better. It's much worse than is_writable or writable or whatnot. Just use -w if that's what you want. --tom Visit our website at http://www.ub

Re: Perl6Storm: Intent to RFC #0101

./sun4-solaris/POSIX.pm:sub isatty { ./sun4-solaris/B/Deparse.pm:sub is_scope { ./sun4-solaris/B/Deparse.pm:sub is_state { ./sun4-solaris/B/Deparse.pm:sub is_miniwhile { # check for one-line loop (`foo() while $y--') ./sun4-solaris/B/Deparse.pm:sub is_scalar { ./sun4-solaris/B/Deparse.pm:sub is_su

Re: RFC 263 (v1) Add null() keyword and fundamental data type

This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the i

perl6storm ideas that are already covered

I do not see how the cited RFCs manage to cover the fact that while () doesn't do a localization, but that for() does, and that this confuses people. --tom, incognito Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the ind

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Now, that's not accurate either. "NUL" is simply a normalized form of "null", >because all the ASCII special characters have three upper-case letter names. >There is no doubt that the ASCII guys meant "null" by this. All other matters aside, kindly consider this simple one: If ever you thought

Re: PERL6STORM - tchrist's brainstorm list for perl6

=item perl6storm #0106 Safe "signals"! (not syssigs,really)

PERL6STORM - tchrist's brainstorm list for perl6

a (the modern not-yet-written version of "use English" module), make something for legible fileops. is_readable(file) is really -r(file) note that these are hard to write now due to -s(FH)/2 style parsing bugs and prototype issues on handles vs paths. =item perl6storm #0102 Make "my sub" work. Make nested subs work. =item perl6storm #0103 Finally implement the less pragma. use less 'memory'; etc. Right now, you can say silly things. use less 'sillyiness'; What about use more? Or is that just no less use less 'magic'; no more 'magic'; =item perl6storm #0104 Look at the deep magic seen in some of the examples in Camel-3's OO and tie chapters and in perltootc. Consider what to canonize into a simpler-to-get-at mechanism, just as plum engendered much in perl5. =item perl6storm #0105 Learn to count in decimal. =back =head1 BUGS None. These are features. =head1 AUTHOR Tom Christiansen

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>How can you convince anyoone if you say you would not use it. For any feature >enhancement to perl, unless there is a strong case for how it makes >the labguage easier and better it is just not going to happen. It's not as though Tim Bunce has been hollering for this, which is a bad sign. --to

Re: RFC 263 (v1) Add null() keyword and fundamental data type

< Russ: >> About the only piece of code of mine that this would affect are places >> where I use ++ on an undef value, and that's not a bad thing to avoid as a >> matter of style anyway (usually I'm just setting a flag and = 1 would work >> just as well; either that, or it's easy enough to explic

Re: Beefier prototypes (was Re: Multiple for loop variables)

> > Could the prototype people please report whether Tim Bunce's issues with > > prototypes have been intentionally/adequately addressed? >I'm not a prototype person (in fact RFC 128 makes it a hanging offence >to use that confusing word in connection with parameter lists! ;-) >Could someone

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Can't we all just play nice? Apparently not. Several of us attempted to explain why this didn't make sense, for many reasons. GL wouldn't hear any of it, stubbornly adhering to this notion despite what was said, often completely ignoring or apparently purposefully misunderstanding the points.

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>> By your "reasoning", we can just add infinitely more things that >> take twice a few pages to explain. >You took that to an illogical extreme conclusion. Clearly you can't add >everything to the language. However, it is clear by the set of currently >submitted RFCs that more people think sug

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>> In Perl, this is the null string:"" >> In Perl, this is the null character: "\0" >> In Perl, this is the null list: () >In RFC 263, this is the null: null >That's a different word for a different concept. No conflict, if you >learn the way the RFC speaks. Wrong. Just plain wrong.

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>No, in that wonderfully consistent Perl documentation, it's "undef" not >is only used to refer to (as you pointed out in another post) > the null string > the null character > the null list >Those use null as an adjective. This RFC proposes an addition to Perl t > the null >This use

Re: RFC 12 (v2) variable usage warnings

Have a nice day. And thanks for all the fish.

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>But I see code in the XML modules that check defined (@array) They're buggy and wrong. --tom

Re: RFC 12 (v3) variable usage warnings

>Tom Christiansen wrote: >> >> >It happens when I don't bother to declare something. My company has >> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is >> >a pain. As is $My::Package::Name::x. >&g

Re: RFC 12 (v2) variable usage warnings

>Tom Christiansen wrote: >> >> >Anything else? Any opinion on whether eval "" should do what it does >> >now, and be invisible for the purposes of this analysis; or if it should >> >be assumed to instead both use and initialize all visible va

Re: RFC 85 (v2) All perl generated errors should have a unique identifier

Ok, so you want message catalogues, and not solely on Perl but anything in the distribution. You should say that. --tom

Re: RFC 12 (v3) variable usage warnings

>It happens when I don't bother to declare something. My company has >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is >a pain. As is $My::Package::Name::x. Far, far easier to fix behavioral problems than to hack Perl. --tom

Re: RFC 12 (v2) variable usage warnings

>Anything else? Any opinion on whether eval "" should do what it does >now, and be invisible for the purposes of this analysis; or if it should >be assumed to instead both use and initialize all visible variables? The >former produces more spurious warnings, the latter misses many errors. You hav

Re: RFC 12 (v3) variable usage warnings

>Which is silly, because you shouldn't have to say '$x = $x = 3' when you >mean '$x = 3'. Just because there's a real reason behind it doesn't make it >any less silly. I'd like to see where this can happen. Sounds like someone forgot to declare something: our $x; $x = 2; --tom

Re: RFC 12 (v2) variable usage warnings

>But that doesn't even matter that much here; I'm saying that if the >compiler can definitely determine that you are using an uninitialized >variable, it should warn. ... >$x is a global. The compiler cannot detect all possible assignments to >or accesses of globals, so it never warns about the

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>> I'm not happy with your use of "coerce". There's no mutation. It simply >> *is* those things. >Fine. So, in particular, it _isn't_ null. Of course it's null. That's why it has length zero. Stop speaking SQL at me. I'm speaking Perl. >> 4) The antiïinitialized value is autovivified to a

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Tom Christiansen wrote: >> > no strict; >> > $a = undef; >> > $b = null; >> >> Perl already has a null string: "". >That's an empty string. In any case, if you really want to call it a >null string, that's fine,

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>> For example, assuming this code: >>$name = undef; >>print "Hello world!" if ($name eq undef); >So don't do that. Use C if you want to ask that question. That's why I want to change the names of these things. The current situation invites errors such as seen previously. Actually,

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>That's not much different than the cost of undef, so I fear it proves >nothing, universally. YOU OVERQUOTEDsen wrote: YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL. YOU OVERQUOTEDonly take a few pages and a few examples, to explain the YOU OVERQUOTED between undef and nu

Re: RFC 85 (v2) All perl generated errors should have a unique identifier

>>>>>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >>> Currently many programs handle error returns by examining the text of >>> the error returned in $@. This makes changes in the text of the error >>> message, an issue

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]: >> > no strict; >> > $a = undef; >> > $b = null; >> Perl already has a null string: "". >Looks more like a string of no length than a null string. Well, it's not. T

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>It only takes a few pages, and a few truth tables to explain NULL. >It should only take a few pages and a few examples, to explain the >difference between undef and null. Ah, so the cost of this is twice a few pages of explanation, plus truth tables and examples? Are you mad? I can think of n

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>$a = null; >$b = ($a == 42); >print defined($b)? "defined" : "not defined"; >would print "not defined", maybe? In a sane world of real (non-oo-sneaky) perl, the "==" operator returns only 1 or "". Both are defined. --tom

Re: RFC 263 (v1) Add null() keyword and fundamental data type

Perl has *one* out-of-band value. It doesn't need more. That doesn't mean that perhaps some rare sorts of programming might not benefit from fancy weirdnesses. That's what modules are for. You don't need to complicate the general language to get what you want. Don't make others pay for your pr

Re: RFC 263 (v1) Add null() keyword and fundamental data type

> no strict; > $a = undef; > $b = null; Perl already has a null string: "". --tom

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Unlike undef, which gets assigned to uninitialized variables, NULL is only >used by choice. So you only need deal with NULL when there is the >possibility that it needs to be handled in some special way, and might exist >as a value in the expression being handled. This can be done without being

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>The semantics for NULL is different, read the SQL standard. Perl has no business contaminating itself with SQL. --tom

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Nathan Wiger wrote: >> >> ...a "use tristate" pragma which obeys blocks >bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped. They *can* be. They needn't be. --tom

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Here's something you and Glenn don't seem to understand: >it doesn't *matter* what the human meaning of undef is. >Call it undefined, uninitialized, unknown, etc. etc. >What matters is that in the perl machine, it's a different >kind of value that a scalar can have, besides string, number, >refer

Re: RFC 12 (v2) variable usage warnings

And what about $$x? Dang, are we back to this incredible confusion about what it is to be defined in Perl.? undef $a; That is now UNINITIALIZED. So is this: $a = undef; You have initialized it to undef. There is no reasonable difference. Solution: Remove all references from th

Re: RFC 263 (v1) Add null() keyword and fundamental data type

>Currently, Perl has the concept of C, which means that a value is >not defined. One thing it lacks, however, is the concept of C, >which means that a value is known to be unknown or not applicable. These >are two separate concepts. No, they aren't. --tom

Re: RFC 85 (v2) All perl generated errors should have a unique identifier

>Currently many programs handle error returns by examining the text of >the error returned in $@. This makes changes in the text of the error >message, an issue for the backwards compatibility police. eval { fn() }; if ($@ == EYOURWHATHURTS) { } sub fn { die "blindlesnot" }

Re: RFC 12 (v2) variable usage warnings

>The warning for the use of an unassigned variable should be "use of >uninitialized variable C<$x>". The problem with that idea, now as before, is that this check happens where Perl is looking at a value, not a variable. Even were it possible to arduously modify Perl to handle explicitly named

Re: RFC 76 (v2) Builtin: reduce

>Ummm...Maybe I'm missing something, but how does reduce() know the >difference between >$sum = reduce ^_+^_, 0, @values; >unshift @values, 0; >$sum = reduce ^_+^_, @values; You know, I really find it much more legible to consistently write these sorts of thing with brac

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

>> $IO::STDERR->print @stuff; >> print $IO::STDERR @stuff; You know, I already resent having to use STDERR instead of stderr. Adding five noisy characters, or seven, is way, way over the top. As for system globals, when one suggested to Larry that these be something on the order of SYS::ARGV

Re: RFC 76 (v2) Builtin: reduce

>Tom suggested: > > Why not just check @numbers? >Hear, hear: > $sum = @numbers ? reduce ^_+^_, @numbers : 0; Although we're back to the pain of what happens when @numbers is really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-) $sum = fn() ? reduce ^_+^_, fn() : 0

Re: RFC 76 (v2) Builtin: reduce

>Following Glenn's lead, I'm in the process of RFC'ing a new null() >keyword and value As though one were not already drowning in a surfeit of subtly dissimilar false values. --tom

Re: RFC 76 (v2) Builtin: reduce

Why not just check @numbers? --tom

Re: RFC 76 (v2) Builtin: reduce

> $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!"; >Note with the || that way, it'll die immediately if @numbers is empty, >even before destroying the universe. Yes, but why are you passing the size of the array in there? --tom

Re: RFC 76 (v2) Builtin: reduce

>> If the original list has no elements, C immediately throws an >> exception. >What do you mean by exception, die ? No other builtin dies like that at >runtime. Well, more can trigger run-time exceptions than people usually notice, but I don't know of one that does so on an empty list. These

Re: RFC 258 (v1) Distinguish packed binary data from printable strings

>Tim Conrow wrote: >> >> Tom Christiansen wrote: >> > Perhaps what you're truly looking for is a generalized tainting mechanism. >> >> Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers? >> RFCs? Examples? Hints? >So

Re: RFC 255 (v2) Fix iteration of nested hashes

>Just to note: in version 2 of the RFC, it's associated with the pad of >the block in which the C appears. > > then what are you going to do? >The short answer is that there is no "manual" reset of iterators. I am concerned about that. sub fn(\%) { my $href = shift; whi

Re: RFC 258 (v1) Distinguish packed binary data from printable strings

Perhaps what you're truly looking for is a generalized tainting mechanism. --tom

Re: RFC 255 (v2) Fix iteration of nested hashes

>This RFC proposes that the internal cursor iterated by the C function >be stored in the pad of the block containing the C, rather than >being stored within the hash being iterated. Then how do you specify which iterator is to be reset when you wish to do that? Currently, you do this by specif

Re: RFC 258 (v1) Distinguish packed binary data from printable strings

>On 19 Sep 2000, Perl6 RFC Librarian wrote: >> Distinguish packed binary data from printable strings >What defines a "printable" string? What if I'm working in an environment >that can "print" bytes that yours can't? Specifically I'm wondering how >this proposal handles Unicode. Perl should f

Re: RFC 259 (v1) Builtins : Make use of hashref context for garrulous builtins

>It's hard to remember the sequence of values that the following >builtins return: >stat/lstat >caller >localtime/gmtime >get* >and though it's easy to look them up, it's a pain to look them up >Every Single Time. >Moreover, code like this is far from self-docume

Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)

>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 didn >'!' bit. So I'm not sure how you'd have written that if you'd have done >specification. Yeah, ok. I still think # Your stuff that you w

Re: $a in @b (RFC 199)

>From: Tom Christiansen [mailto:[EMAIL PROTECTED]] >> From: Jarkko Hietaniemi >> >> >I find this urge to push exceptions everywhere quite sad. >> >> Rather. >> >> Languages that have forgotten or dismissed error returns, turning >> instead

  1   2   3   4   >