listing all files in all sub directories

I am trying to list all files in all sub-directories and have the code below but this is listing the . directories as well as the directories themselves. I just want the full path filenames and not the individual directories out. Here is what I have #!c:/Perl/bin/Perl.exe @ARGV = qw(.) unless @AR

Re: formats and localtime

On Tue, Aug 01, 2000 at 01:17:25PM +1000, Damian Conway wrote: > My (limited) understanding of the aims of Perl 6 were to start again with a > clean slate and fix the things that are broken, or that could be designed > better with hindsight. Backwards compatibily was to be fed to the lions. > >

Removing/fixing $[line noise here] variables

In re the discussion of $^O, etc, etc, I'd like to throw out some ideas on these line noise features and (for lack of a better name) perl control values. IMHO there are two distinct sets of problems here. One is that the existing $[linenoise] vars are horrible names and really need some syntacti

Re: Removing/fixing $[line noise here] variables

On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote: > Put together an RFC for it. (Soon!) This is a language topic, but it will > impact internals a touch, and I'd like to get as many of the "impact > internals" things spec'd out as soon as possible . . . Uh, OK - but how about we wa

Module versioning changes

Despite my throw-it-over the transom comments on global vars, that's not really why I came here (tho I will pitch in on the topic). The perl features that most bites me in the ass is how module versioning and searching works. The easiest way to describe what I want is by examples, so here are se

RFC: type inference

=head1 TITLE type inference =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> Date: 1 Aug 2000 Version: 0 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT Types should be inferred whenever possible, and optional type qualifiers may b

Re: type-checking [Was: What is Perl?]

Tom Christiansen wrote: > > >Several people have suggested strong typing as a feature, and have been shot > >down one by one. However, I think it can be done without forcing it on > >everyone. > > Can it? Are you prepared to make everyone declare the full, formal, and > fancy types for the ret

Re: RFC: type inference

Ken Fox wrote: > > IMHO type inference is the best way to get typing into Perl. > We don't lose any expressiveness or hurt backwards compatibility. > About the only thing we need to make visible are a few additional > pragmas to enable type inference warnings. > > S

Re: Removing/fixing $[line noise here] variables

On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote: > Brust, Corwin wrote: > > I want perl's error (and warning) messages to be specific to each program I > > write. > > Isn't this covered by locales? Completely different beast. I don't claim to fully understand locales, but that's n

RFC: variable usage warnings

Hey, this RFC stuff is fun! =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 0 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE used only once: po

Re: RFC: Filehandle type-defining punctuation

On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote: > =head1 TITLE > > Filehandles should use C<*> as a type prefix if typeglobs are eliminated. I could go for this, given the `if typeglobs are eliminated' caveat.

Re: RFC: variable usage warnings

Tom Christiansen wrote: > > >The warning message "use of uninitialized value" should also > >disappear, to be replaced with "use of undefined value", and the > >warning for the purpose described in this RFC should be "use of > >uninitialized variable C<$x>". > > What about if there's only an exp

Re: RFC: variable usage warnings

Updated RFC. --- =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 0.2 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE use

Re: RFC: variable usage warnings

Tom Christiansen wrote: > > >"symbol $main::x used only once" -> "use of uninitialized variable > >$main::x" > >"use of uninitialized value" -> "use of undefined value" > > Perhaps then > > "use of uninitialized value" -> "use of undef as discrete value" > or > "use of uninitialized val

Re: perl 6 requirements

"Randal L. Schwartz" wrote: > > > "Martyn" == Martyn Pearce <[EMAIL PROTECTED]> writes: > > Martyn> Possibly, although I must ask: since everything is up-for-grabs, I ask > Martyn> (without implying any feeling one-way-or-tother): > Martyn> How useful is the , operator in it's C-style statem

Re: Where must you 'no strict'?

Summary: There is no circumstance in which I have had to do `no strict.' Background: I've spent much of the last six months cleaning up bad perl (let's hope none of my co-workers are on this list...). When I'm done with a tool or module, it runs silently under -w and under strict. 100%. I've

Re: BiDirectional Support in Perl6

On Thu, Aug 03, 2000 at 02:31:01PM +0300, Roman M . Parparov wrote: > This is quite unexplored field. I, being an Israeli resident, am forced > to deal once in a while in applications that should output RTL languages, > both as plain text output and hypertext output. By RTL, do you mean the inte

Re: RFC stuff

On Thu, Aug 03, 2000 at 12:51:10PM +1000, [EMAIL PROTECTED] wrote: > Programer Modifiable Warnings and Error Messages > Brust, Corwin" <[EMAIL PROTECTED]> . . . > Removing/fixing $[line noise here] variables > Corwin Brust <[EMAIL PROTECTED]> That second is actually mine. Ba

Re: RFC stuff

On Wed, Aug 02, 2000 at 08:27:19PM -0600, Tom Christiansen wrote: > What you're doing here is recreating USENET. But badly . . . > Is there an open NNTP server running with all these as the perl.* > groups? That would help a lot. Please, please, please. I'm already considering moving these s

Re: BiDirectional Support in Perl6

Steve Simmons wrote: > > By RTL, do you mean the intermediate representation used in the GNU > compiler family? If not, could you provide a pointer to the RTL you're > referring to? Acronyms are overloaded so easily... "Right To Left". This is the first I've se

Re: RFC: Modify open() and opendir() to return handles

On Thu, Aug 03, 2000 at 08:54:35PM +0200, Johan Vromans wrote: > Peter Scott <[EMAIL PROTECTED]> writes: > > If we get a good-looking exception throwing/catching mechanism and > > syntax, this may not matter. >try { > java >} >catch (Exception e) { > think again >} I

Re: Removing/fixing $[line noise here] variables

In writing up the RFC on removing/fixing $[line noise here] variables, I've decided to leave out the following suggestion: On Tue, Aug 01, 2000 at 06:47:41PM -0700, Nathan Wiger wrote: > Alan Burlison wrote: > > > > Steve Simmons wrote: > > > > > I'd pr

Re: try/catch (Was: Re: RFC: Modify open() and opendir() to return handles)

On Fri, Aug 04, 2000 at 09:10:38AM +0200, Johan Vromans wrote: > You missed the point. > > If you need 6+ lines of code for each elementary error check, this is > what is going to happen . . . You're correct, but that's not what I was suggesting. The magic words are `for each elementary error c

Re: Recording what we decided *not* to do, and why

On Fri, Aug 04, 2000 at 12:07:00PM -0400, John Porter wrote: > I don't mind cpp too much; but I'd really like something much > more powerful than cpp. Hmm -- cpp++?? m4. IMHO perl6 should continue the rich tradition of stealing from the best rather than re-inventing an only marginally better w

Re: Recording what we decided *not* to do, and why

On Fri, Aug 04, 2000 at 01:18:36PM -0400, John Porter wrote: > O.k., what I really meant was, When they're both incapable of doing > the sorts of things I want a macro language to do, does it matter > that one is gobs more powerful than the other? I freely admit to knowing very little about macr

Re: Language RFC Summary 4th August 2000

On Fri, Aug 04, 2000 at 03:37:08PM +1000, [EMAIL PROTECTED] wrote: > > 1. put their hands up to write the "up for grabs" RFCs > 2. work towards getting the "requested/promised" and "draft" RFCs up to >the point where they can be submitted to the librarian. > 3. let me know if you think an RFC

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

> Functions like stat() and get*ent() return long lists of mysterious > values. The implementation is assumedly easy: just push some values > out of C structs into the Perl return stack. . . . > Firstly, who can remember which one of the stat() return values was > the atime is or which is the 4t

Re: RFC Archive

What about updating RFCs? Should I increment the version number and send each new revision to perl-rfc? Do I need to be careful about the RFC number when submitting updates? Also, I assumed the intention of the RFCs was to stimulate focused discussion and to keep a record of the decisions made du

Re: Recording what we decided *not* to do, and why

On Thu, Aug 03, 2000 at 11:27:27AM -0600, Nathan Torkington wrote: > Steve Simmons writes: > > . . . IMHO the RFC editor should be responsible for this. > > IMHO someone should write an RFC on why perl6 should NOT have > comments. The RFC editor doesn't have time to fol

RFC17 (v1) comments and responses

This is an omnibus response to those who've commented on RFC17 (v1). The version I'm about to submit to the librarian is now available as html at . General note -- please look over the abstract. Some folks have made really good suggestions to change th

Re: wildcard includes

I'm working on an RFC on module versioning. It'd be done by now, except my boss and family keep expecting me to work and be fatherly. :-) Let me get that banged out, and then lets look at adding wildcards to it.

Re: RFC 71 (v1) Legacy Perl $pkg'var should die

On Tue, Aug 08, 2000 at 10:59:40PM -0400, Dan Sugalski wrote: > On Wed, 9 Aug 2000, Damian Conway wrote: > > >> > If you take this, I won't be able to port the forthcoming Klingon.pm > >> > module to Perl 6!!! > >> > >> And this would be a bad thing how, exactly? :) > > > > I SH

Re: Things to remove

On Tue, Aug 08, 2000 at 06:34:19PM -0500, Mike Pastore wrote: > Perl++ perm -- good old hairy perl, finally under control. Running and ducking, --Steve

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Wed, Aug 09, 2000 at 10:44:03AM -0700, Larry Wall wrote: > : Note that it may not be possible to satisfy conflicting requests. If > : module C and module C demand two different versions of the same > : module C, the compiler should halt and state the module conflicts. > > Pardon me for snipin

Re: RFC 73 (v1) All Perl core functions should return ob

I'm pretty much opposed to this idea. It's pushing OO too far onto perl.

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Wed, Aug 09, 2000 at 05:53:44PM -0400, Ted Ashton wrote: > I'll take that as my cue ;-). Ah, nothing like a man who knows when to pick up his cues. > <*shudder*> This whole business is getting pretty scary . . . [[ discussion of ugly implicatations elided ]] The short answer is that (ass

Re: RFC 78 (v1) Improved Module Versioning And Searching

On Thu, Aug 10, 2000 at 11:01:39AM -0400, Bennett Todd wrote: > Rather than proliferating the number of keywords eaten with all > these *ref varients, this sounds like a useful place for returning > an object with a default stringification of the class: > . . . > Ref RFC 37, RFC 73. I have no p

My opposition to RFC20, and an alternative

Overloading an existing operator such that it changes the performance in prior situation is evil, evil, evil. Yes, I know it can have some wins, and I agree they're big ones. But no win is worth having to debug this (admittedly contrived for the example) situation: if ( ( $ares = A() ) && (

Re: RFC 78 (v1) Improved Module Versioning And Searching

> Perhaps Damian's want() (RFC 21) can be used to allow allow either return > type? Yes indeed. > Assuming that's adopted, of course. Sure looks to me like a good idea; I hope it does.

RFC 78 and shared vs unshared modules/data

On Thu, Aug 10, 2000 at 05:46:14PM -0400, Bennett Todd wrote: > Today there's no difference. If the proposal under discussion were > to pass, and packages' namespaces were to become local to the > namespace where the "use" occurred, then perhaps main::whatever > could be a common, stable, global

Re: RFC 83 (v1) Make constants look like variables

I really like the idea of constants in perl, but think the RFC should go a lot further. C/C++ has solved this problem; we should follow in their footsteps. Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: A constant struct with constant val

Recording what we decided *not* to do, and why

On Thu, Aug 03, 2000 at 11:40:24AM +0900, Simon Cozens wrote: > On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote: > > > That Perl should stay Perl > > Do we need an RFC for this? Seems like this is more of a "guiding > > concept" that should be intergrated into everything. Just my o

Unify the Exception and Error Message RFCs?

On Sun, Aug 13, 2000 at 07:35:06PM -0700, Peter Scott wrote: > At 03:30 PM 8/13/00 -0500, David L. Nicol wrote: > >Whose RFC deals with this? > 63, 70, 80, 88 and 96. There would appear to be a groundswell of interest :-) Well yes, but they represent three authors with (as best I can tell) pr

Re: RFC 83 (v1) Make constants look like variables

On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote: > Please, please, please, PLEASE, let us not replicate the debacle that is > C++'s const modifier! It doesn't feel like a debacle to me, it feels like it put the control in the programmers hands. Yes, the syntax is often unweildy --

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Russ Allbery wrote: > > > All variables should be C<$x>. They should behave appropriately > > according to their object types and methods. > > No thanks. I frequently use variables $foo, @foo, and %foo at the same > time when they contain the same information in different formats. For > exampl

Re: Permanent sublists (was Re: Language WG report, August 16th 2000)

On Wed, Aug 16, 2000 at 02:38:33PM -0400, Uri Guttman wrote: > i see problems with overlapping areas. I/O callbacks fall under both io > and flow IMO. some of the error handling like dying deep in eval and > $SIG{DIE} also fall under error and flow. This is true, and inevitable. But IMHO it'd b

Re: RFC 114 (v1) Perl resource configuration

On Wed, Aug 16, 2000 at 08:03:31PM -, Perl6 RFC Librarian wrote: > Perl should provide a mechanism to have common code autoloaded from a > file. . . . > A C file could be used to set system-wide defaults that > the system administrator would like to promote. For instance, > C could turn on

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Ted Ashton wrote: > > Thus it was written in the epistle of Russ Allbery, > > > > This falls firmly in the category of things that are powerful for > > experienced users of the language but may be somewhat difficult to learn. > > I don't think Perl has being easy to learn as it's primary goal, no

Re: Ideas that need RFCs?

> On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote: > > * Replace C, C, and C with equivalent regularized > > functions that take mulitple arguments instead of using specialized > > syntax. It would be best if the names could be more "complete", like > > match(), translate(

Re: Ideas that need RFCs?

(I'm assuming you intended this for perl6-language) "Myers, Dirk" wrote: > > > I certainly don't want m, > > tr, or s to go away (or /regex/ either.) But the =~ bothers me. How > > about disallowing m{...} and using m{expr}/.../? > > How about this, for the really compact way to do it: > >

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Ted Ashton wrote: > > > But the most direct way to measure how well the > > language slides into people's heads is by seeing how hard it is for them > > to get the hang of it. > > Nope. I've yet to be convinced that "fits in your head" is the same as > "went in easily". Hang

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Karl Glazebrook wrote: > > Ariel Scolnicov wrote: > > > > Karl Glazebrook <[EMAIL PROTECTED]> writes: > > > > [...] > > > > > o Why do I think perl has too much line noise? Because of code like this: > > > > > > @{$x->{$$fred{Blah}}}[1..3] > > > > This is indeed horrible. However, I fail to se

Re: Ideas that need RFCs?

Nathan Wiger wrote: > > We're getting deluged with RFC's and emails. We should start thinking > "will this RFC or idea *add value* to Perl 6?". If not, and it just > makes something work differently, it _might_ not be worth an RFC. I disagree completely. For one thing, there's no such thing as P

Re: Ideas that need RFCs?

Decklin Foster wrote: > > [replying from here since this is the only way I received it] > > > "Myers, Dirk" wrote: > > > > > > $line/pattern/ ; > > > > > /pattern/ ($line) ; > > I don't think these should be changed. Here's how I tend to pronouce > things: > > $x = 'foo'; #

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Damien Neil wrote: > > On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote: > > My proposal would be what I implemented for perl5 a while back (Sarathy > > didn't dislike it, but wasn't convinced enough to put it in): all > > dereferencing can be done wit

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Ted Ashton wrote: > > > all > > dereferencing can be done with ->. > > Is that "can be done with" or "must be done with"? > > Either way, I like the idea. To me it reads more smoothly, and as I seldom > dare to use the double-punctu

Re: RFCs (Re: Ideas that need RFCs?)

Nathan Torkington wrote: > > Steve Fink writes: > > We are NOT here to construct a radically better language. We are here to > > design the underpinnings of one. > > Perhaps. And by "perhaps", I mean "no". > > We're here to say what we&#x

Re: RFC 109 (v1) Less line noise - let's get rid of @%

"Casey R. Tweten" wrote: > > This looks counter intuitive, my brain says to dereference the reference at the > begining, just like you make the reference, in other words, keep it all the > same: > > $hashref->{key}->@ # Deref > $hashref->{key}->$ # Deref > $hashref->{key}->% # Deref > $hashref->

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Nathan Torkington wrote: > > Don't forget that the rationale behind the infix dereferencing is > this: > > @variable_name > @{variable_name} > @$scalar_containing_variable_name @$scalar_containing_value_ref > @{ code evaluating to variable name } @{ code giving value ref } True. Wou

Re: Extended Regexs

Robert Mathews wrote: > > > James Mastros wrote: > > > [/f for fast DFA regexen] > Jeremy Howard wrote: > > The choice of algorithms is a great idea, but why do we need a modifier? > > Isn't it a pretty straightforward set of rules that allow us to decide if a > > DFA matcher will work? It would

Re: RFC 23 (v3) Higher order functions

Damian Conway wrote: > > It was simply attempting to explain why I choose to ignore what are (to > me, at least) trivial implementation issues, well documented in the > compiler literature. I choose to ignore them because I *have* to ignore > them or my brain is going to melt. So perhaps you sho

Re: RFCs (Re: Ideas that need RFCs?)

Jeremy Howard wrote: > > > Steve Fink writes: > > > And both those examples apply to the underpinnings. Ok, maybe I have an > > > unusually broad definition of the word "underpinnings". Think "anything > > > that can't be done with a p

Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%

(thread intentionally broken) Nathan Torkington wrote: > > Steve Fink writes: > > True. Would anyone mourn @$scalar_containing_variable_name if it died? > > I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't > > notice $x

Re: Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%

Thanks! Ok, from a type inferencing perspective... Nathan Torkington wrote: > > Symbolic references are used for dynamic function generation: >foreach my $func (qw(red green blue)) { > *$func = sub { "@_" } >} Probably have to punt on checking user code in a main routine that does

Filtering rules

(Off-topic for this list, but I'm not sure where else to send it) Could we have a discussion somewhere of useful filtering rules for all these perl6 lists? Specifically, I'm looking to steal other people's .procmailrc snippets. I imagine that a lot of people have written their own, and everything

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

Tom Christiansen wrote: > > I happen to strongly appreciate that the invocant in > > $a->blah > > can be of either sort; that is: > > $a = "MyClass"; > $a->blah; > > or > > $a = MyClass->generate(); > $a->blah(); > > In fact, who knows what generate() returned? It could

Re: Do we really need eq?

I'd like to see eq and it's brethen retained, as dammit there are times I want to know (-w) if numbers are turning up when there should be words and vice-versa. However, spinning off of something Randal wrote: > Yes, but what about: > > $a = '3.14'; # from reading a file > $b =

HERE construct

General comment on all the discussion of HERE docs. When HERE docs cause you a problem, don't use 'em. There is little win if any over print << HERE; Dear Sir: You owe me bucks. Pay up. Me. HERE and $msg = 'Dear Sir: You owe

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

On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Case ignoring eq and cmp operators IMHO this problem is better solved by using =~ and its brethren, which already allow you to

Re: Multiple for loop variables

On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote: > Peter Scott wrote: > >Graham Barr once allowed as how he thought it would be neat if you could say > > > > for my($x, $y, $z) (@list) { ... } I too am pushing for this feature, to the point where I'm considering an rfc on the topic

Re: RFC 110 (v3) counting matches

[redirected to perl6-language] Tom Christiansen wrote: > > Note the difference between > > my $var = func(); > > and > > my($var) = func(); > > Those are completely different in that they call func() in scalar > and list contexts. Why? Because of hte presence or absence of (), > of

Re: RFC 175 (v1) Add C keyword to force list context (like C)

> for reality here. That should be written more like: > > 1 while ; $burp = $.; > > or even: > > for ($burp = 0; my $line = ; $burp++) {} I'd go for my $burp = 0; $burp++ while ; > This proposal should be dropped. I read your message and agree. Not that I liked the

Quantum computing

Can't quite run perl yet. http://www.tomshardware.com/cpu/00q3/000901/index.html

Re: $a in @b

Damian Conway wrote: > >> > I would propose that the C operation should short-circuit if the >> > block throws an exception, with the value of the expection determining >> > whether the final invocation of the block should accept the element it >> > was filtering: >> >> Ot

Re: $a in @b

Damian Conway wrote: > >> Both are pretty much the same. Combining them, I'd say that exceptions >> should remain exceptional. > > I'd say short-circuiting a vector operation was exceptional enough. :-) I'd say it's exceptional sometimes, and very ordinary other times, and I'd prefer to

Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence

Nathan Wiger wrote: > > > Foo::Bar->stickysnort() > > Right, knew I forgot something... > > > I wonder whether the "I want to expand arbitrary expressions within > > strings even when there aren't any $ or @ symbols about" people > > just need better familiarity with the alternatives. > > This

Re: $a in @b (RFC 199)

Jarkko Hietaniemi wrote: > > Allow me to repeat: instead of trying to shoehorn (or piledrive) new > semantics onto existing keywords/syntax, let's create something new. > The blocks of grep/map/... are special. They are not quite looping > blocks, they are not quite sub blocks, they are differen

Re: types that fail to suck

Mark-Jason Dominus wrote: > > Maybe I should also mention that last week I had a dream in which I > had a brilliant idea for adding strong compile-time type checking to > Perl, but when I woke up I realized it wasn't going to work. What do you see as the major obstructions? eval "" isn't too ba

Re: Conversion of undef() to string user overridable for easy debugging

> > This reminds me of a related but rather opposite desire I have had > > more than once: a quotish context that would be otherwise like q() but > > with some minimal extra typing I could mark a scalar or an array to be > > expanded as in qq(). > > I have wanted that also, although I don't remem

Re: RFC 226 (v2) Selective interpolation in single quotish context.

Nathan Wiger wrote: > > Andy Dougherty wrote: > > > > How do you turn it off? I want to keep a way to specify stuff without any > > interpolation whatsoever. I see the usefulness of this sort of quoting, > > but I also see the usefulness of being absolutely able to turn all > > interpolation off

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >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 m

Re: RFC 12 (v2) variable usage warnings

Eric Roode wrote: > > Steve Fink wrote: > >I am merely suggesting that the compiler detect, when it can, that > >you're trying to use the value of a variable without ever having > >assigned a value to that variable. And in THAT message, you had better > >know t

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote: > > "VARIABLE used only once: possible typo" should be replaced with > > warnings on uses of uninitialized variables (including lexicals). > > > $x = 3 > > I don't understand, who's to say you didn't

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > 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 differ

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >Same thing. If $x is lexical, it gives a definite warning. If $x is a > >global, it says nothing. You're right; I need to point this out in the > >RFC. > > Careful: > > sub ouch { > my $x; > my $fn = sub { $x++ }; > register($fn); >

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 =

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote: > > > > complains, but > > > > > > > > $x = 3; $x = 3 > > > > > > As it shouldn't; you've mentioned $x twice, which means you probably d

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. > > Far, far easier to fix behavioral problems than to hack Perl. > > --tom Not s

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 variables? The > >former produces more spurious warnings, the

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote: > > > $foobal = 3; > > > if (@ARGV) { > > > $foobar = @ARGV; > > > } > > > > > > print $foobar; > > > > >

Re: RFC 12 (v3) variable usage warnings

Tom Christiansen wrote: > > >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. > >> > >> Far, far easier to fix behavioral

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >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 variables? The > >> >

Re: RFC 12 (v3) variable usage warnings

Eric Roode wrote: > > Steve Fink, via the Perl6 Librarian, wrote: > >=head2 EXAMPLE > > > >1 my ($x, $y, $z, $r); > >2 $z = 1; > >3 f(\$r); > >4 my $logfile = "/tmp/log"; > >5 $x = 1 if cond(); > >6 prin

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > Ok, at this point I'm trying to clear up misunderstandings. I believe you > know where I stand with relation to your RFC. Thanks, you caught several of my mistakes. > > On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote: >

Re: RFC 12 (v2) variable usage warnings

Daniel Chetlin wrote: > > On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote: > > % perl -le '$x = 3; eval "\$x++"' > > (no warning issued) > > [~] $ perl -wle'$x = 3; eval "\$x++"' > Name "main::x" used only once: possible typo at -e line 1. Doh! Thanks.

Re: RFC 12 (v2) variable usage warnings

Dave Storrs wrote: > > On Wed, 20 Sep 2000, Eric Roode wrote: > > > foo(); > > print $x; > > > > Generate a warning, or not? Which one? Remember, foo() may initialize $x. > > My suggest (FWIW) would be that, if there is no execution path > which leads to $x being defined in the

Re: RFC 12 (v2) variable usage warnings

Eric Roode wrote: > > Allow me to throw another log on the fire: > > my $x; > if (something) > { > $x = 1; > } > my $y = $x; > > This would give a compile-time warning under your RFC, warning the > user of a possibly uninitialized $x. Okay. Next: Yes. > my $x;

Re: my and local

Tom Christiansen wrote: > > 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

Re: Acceptable speeds (was Re: TIL redux (was Re: What will thePerl6 code name be?))

Most of the time, perl's performance is a total non-issue for me. When it is, I'm generally doing the same things as Dan (ie, things resembling dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to perl6-meta at one point. Here they are again: - You did ask at one point for

Re: RFC on Coexistance and simulaneous use of multiple module version s?

On Fri, Jan 26, 2001 at 02:08:01PM -0600, Garrett Goebel wrote: > Discussion of RFC 271 and 194 on pre and post handlers for subroutines > reminded me of Larry's desire for Perl 6 to support the coexistence of > different versions of modules. > > Besides http://dev.perl.org/rfc/78.pod, are there

  1   2   >