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: Questions for Survey about Perl

In-Reply-To: Message from Daniel Carrera of "Fri, 31 Dec 2010 20:20:33 +0100." > For amusement, below I include the same program > in FORTRAN II and Fortran 90. That was delightful -- thanks! --tom

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: the file slurping is not working

Larry wrote: » Indeed, that preference is why Perl 6 can (we hope) get away with » autochomping, where Perl 5 can't (as easily). Or more accurately, » we choose not to special-case "while (<>)" as Perl 5 does (because » even Perl 5 has difficulties with files that are accidentally » "autochomped"

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: Revisiting lexicals, part 1

In-Reply-To: Message from Geoffrey Broadwell <[EMAIL PROTECTED]> of "Wed, 24 Sep 2008 16:47:44 PDT." <[EMAIL PROTECTED]> > On Wed, 2008-09-24 at 18:09 -0500, Patrick R. Michaud wrote: >> On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote: >>> 2008/9/24 Patrick R. Michaud <[EMAIL PR

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: Perl 5's "non-greedy" matching can be TOO greedy!

>Nice summary, but I'm not buying what you're selling in the elaboration. Then you lose, because I am not allowed to disagree with you anymore. And everyone else has already written you off. And the answer to "what breaks if mimimal matching is overall but maximal matching is local"--or even, "i

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>Take. It. To. Private. Email. Please. I'm going to do better. I'm taking it to /dev/null. It's not worth my wasting my life over. Nobody agrees with this guy, so it doesn't matter. --tom

Re: Perl 5's "non-greedy" matching can be TOO greedy!

And while I'm at it, consider /(.*)(.*)(.*)/, which we'll call /ABC./ You need to be able to say all of these independently and in conjunction with one another: whether segment A is longest or shortest overall whether segment B is longest or shortest overall whether segment C

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>At worst, this should take no more than double the amount of time that the >single pass did, probably less. Hardly a cause to concern ourselves with >the heat death of the universe. Oh really? We have shown that for the kind of global overall analysis that you are asking for, that in the gener

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>That would be a strange regexp, but I never suggested it. I suggested the >regexp /b.*?d/ and pointed out that I believe "bd" is a more intuitive >match than "d". That was the matching text, not the regexp, sorry >if I didn't make that clear. Fine. What you said is first

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>You can't explain why "d" matches without making reference to the >absolute priority of the leftmost rule. "bd" would still make sense >(locally) without reference to that rule. Nope. Nope, nope, and nope. Th8is /d/ thing, which is completely unrealistic and non-real-world

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>On Fri, 15 Dec 2000, Tom Christiansen wrote: >> >As for special-case rules, I believe that my proposed modification would >> >REMOVE a special-case semantic rule, at the cost of added complexity at the >> >implementation level. >> >> What is this a

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>We may have to "agree to disagree". I shan't be doing that. >I'm understand why people believe in >the current semantics, but I've seen no indication that anyone else >understands why I believe in these alternative semantics, or has tried. >(Disagreeing with my conclusion doesn't preclude und

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>Really? I haven't taken a survey, but I did ask one co-worker for his >first impression of what the regexp (from my example) would match. Not >being an experienced Perl programmer, but being familiar with regular >expressions, he believed he understood the idea of non-greedy matching. >His expe

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>Have you thought it through NOW, on a purely semantic level (in isolation >from implementation issues and historical precedent), I've said it before, and I'll say it again: you keep using the word "semantic", but I do not think you know what that word means. --tom

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>> More generally, it seems to me that you're hung up on the description >> of "*?" as "shortest possible match". That's an ambiguous >Yup, that's a bit confusing. It's really "start matching as soon as >possible, and stop matching as soon as possible". (The usual greedy >one is, of course,

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>Actually, I'm not sure -- it's conceivable that the ending point would ALSO >move inward for a different starting point within the original match. But >the ending point should NEVER be advanced further -- that's where the >"leftmost over nongreedy" rule should apply instead... Please show us yo

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>I want the maximum level of OVERALL consistency for regular expressions as We're there, thank you very much. "Find a match" is the over-riding sentiment, the principle semantic. It is completely consistent with this. You've got greed/nongreed very wrong. >a whole, rather than immutable adhe

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>I meant that I've never seen >a concrete, realistic example where the current behavior is more beneficial >to the programmer than my proposed behavior. Absense of evidence is hardly evidence of absence. `cat /vmunix` =~ /\w+/ I just love guaranteed worst-case behavior. NOT. It is good to

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>As for special-case rules, I believe that my proposed modification would >REMOVE a special-case semantic rule, at the cost of added complexity at the >implementation level. What is this alleged "special-case rule" you are talking about? There is no such thing. None. When you write /pat/, it

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>I made a mistake in phrasing it this way, because it seemed to suggest that >I thought it was an implementation bug that it returns "d" instead >of "bd". I didn't make it clear that I was trying to approach this as >a purely SEMANTIC question, considered in isolation from the impleme

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>No question that's how it's been implemented. But WHY would anyone want >such behavior? When is it beneficial? It is beneficial because this is how it's always been, because it is faster, because it is more expressive, because it is more powerful, because it is more intuitive, and because it i

Re: Perl 5's "non-greedy" matching can be TOO greedy!

>Does anyone disagree with the premise, and believe that "d" is the >CORRECT match for the non-greedy regexp above? Yes. The Camel's regex chapter reads: You might say that eagerness holds priority over greed (or thrift). >For what it's worth, here's a quote from a Perl 5.005_03 "p

Re: RFC 361 (v1) Simplifying split()

>Sean M. Burke wrote: >> >> The current behavior makes trailing empty fields non-existent, and that's a >> bizarre and nonintuitive thing to have be a default; >Only to some people; and besides, it's well documented. Well, Sean is right in that it is very bizarre to many people. I know that whe

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 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,

Re: RFC 308 (v1) Ban Perl hooks into regexes

>I consider recursive regexps very useful: > > $a = qr{ (?> [^()]+ ) | \( (??{ $a }) \) }; Yes, they're "useful", but darned tricky sometimes, and in ways other than simple regex-related stuff. For example, consider what happens if you do my $regex = qr{ (?> [^()]+ ) | \( (??{ $regex })

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

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 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

RFC 198 (v2) Boolean Regexes

This seems very complicated. Did you look at the Ram:6 recipe on expressing AND, OR, and NOT in a regex? For example, to do /FOO/ && /BAR/ you need not write /FOO.*BAR|BAR.*FOO/ -- and in fact, should not, as it doesn't work properly on some pairs! For example, /CAN/ && /ANAL/ can't be written

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 260 (v1) More modules

>So this would break any code which interacts with pod: Pod::Usage, perlman, >perlhelp, etc. NB: perlhelp == perlman with a particular metapage named perlhelp, which knows to search the pod library linewise. >Which I suppose just adds weight to the don't go there, >highly discouraged ultimatum.

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: RFC 265 (v1) Interface polymorphism considered lovely

>We've had prototyping (context coercing) for methods as long as we've >had them for "ordinary" subroutines. Sure -- they just don't work. Method calls are indirect function calls. As such, they are not resolved until run time. Context coercion, however, is set at compile time--if at all. --

Re: RFC 260 (v1) More modules

>I don't think that the documentation should be removed from the core >distribution, BUT I do think that there should be an "easter egg" that >allows people to build a Perl distribution without documentation or >whatever else they choose. There have been times that I've >wanted/needed to build a

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: \z vs \Z vs $

>I gather you're talking about //s making perl ignore the setting of $*. >You're right, I didn't know that. But I doubt if it's that important, >this variable already has been marked as deprecated since Perl5 came >out, about 5 years ago. It's a good candiadte to be removed in Perl6. Agreed. >My

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: 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: 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 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: \z vs \Z vs $

>Tom Christiansen wrote: >> Don't forget /s's other meaning. >Do you enjoy making people ask what you're talking about? Of course not. I enjoy giving people enough pointers to help them learn things for themselves. >What other >meaning did you have in mind, overriding $*? Yes. --tom

Re: \z vs \Z vs $

>That was my second thought. I kinda like it, because //s would have two >effects: > + let . match a newline too (current) > + let /$/ NOT accept a trailing newline (new) Don't forget /s's other meaning. --tom

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: \z vs \Z vs $

>>>>>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >>> Could you explain what the problem is? >TC> /$/ does not only match at the end of the string. >TC> It also matches one character fewer. This makes >TC> code like $pa

Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand

This will make programs highly nonportable. You can't easily know what modules they really need. --tom

Re: RFC 212 (v1) Make length(@array) work

>What I said was: making length(@array) "work" would be catering to >novice people *coming from C*. We shouldn't. Not that much. In Perl, a >string is not an array. I'm pretty sure it's not just the people coming from C who expect this. This all points to the bug^H^H^Hdubious feature which is th

Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand

>Mostly harmless. Right before raising the famous "Can't locate method >..." error, Perl should check to see if C is in effect. If so, >it should read the C config file and ... ***LINEARLY READ A FLAT FILE!!?!?!*** --tom

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

  1   2   3   4   5   >