Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
At 04:53 PM 10/1/00 -0400, Dan Sugalski wrote:
>At 11:33 AM 10/1/00 -0700, Peter Scott wrote:
>>But, setting aside my visceral reaction to changing array bases, you have
>>precisely the same problem here that has scuppered my intent to file an
>>RFC for hashes with fixed keys; how do you apply the attribute to
>>anonymous, let alone autovivified, arrays? If I say
>>
>> my @a :base(1);
>>
>>then what of $a[1][1]? How to specify that the second level array also
>>has a base of 1? Without it looking really ugly?
>
>Well, it'd be reasonable for autovivified arrays and hashes to inherit the
>properties of their parent, so if you had:
>
> my int @foo;
>
>and accessed $foo[1][2], that new autovivified array would be of type int.
Well, okay. This works better in the case of arrays, where it is much more
likely that the programmer wants homogeneity, than in hashes. Consider a
typical multicolumn database-type hash like:
%state = (
AK => {
NAME=> 'Alaska',
CAPITAL => 'Juneau'
},
AL => {
NAME=> 'Alabama',
CAPITAL => 'Montgomery'
},
AZ => {
NAME=> 'Arizona',
CAPITAL => 'Phoenix'
}, ...
Clearly each level does not want the same restriction on its keys.
But the fact that my pet whim isn't supported by this proposal shouldn't
detract from the advantages in other situations.
>As for anonymous hashes and arrays, there's no reason outside of
>appearance that you coudn't tack on attributes after the closing
>array/hash constructor:
>
> my $foo = [] : int;
Looks good. What are the chances of the internals supporting user-defined
attributes? What would the API look like?
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
At 01:38 PM 10/5/00 -0400, Dan Sugalski wrote: >On Thu, 5 Oct 2000, John Porter wrote: > > > Peter Scott wrote: > > > the idea is to be an extension of Larry's creative thinking > > > process. Neither of us is deciding what goes into Perl 6, and > neither is > > > the community - I hope. Larry is. > > > > Uh, then why did Larry say "perl 5 was my rewrite, perl 6 is the > > community's rewrite"? Clearly he does not think of himself as the > > community. He has said it: this is *our* rewrite. > >Perl 6 is going to be the community's rewrite. His design to start, but >the community's rewrite. 'rewrite' is not the same as 'design', fortunately. I fervently hope that the language design will be the product only of ideas Larry either came up with or agreed with; if we get into some voting scenario, that spells doom. May I point out that COBOL was designed by a committee. See http://dev.perl.org/rfc/meta/larry-1.txt and http://dev.perl.org/rfc/meta/larry-3.txt for some reassurance in this regard though. -- Peter Scott Pacific Systems Design Technologies
Re: What will the Perl6 code name be?
At 09:54 PM 10/23/00 +0100, Simon Cozens wrote: >On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote: > > The one thing that just occurred to me is that we're going to need to > > support multiple interpreter targets simultaneously. Having the back-end > > emit C source isn't going to get those BEGIN blocks very far. :( > >Don't forget that those BEGIN blocks are *supposed* to be instructions >to the compiler. Er, but a lot of people seem to use them for other things :-) > > Runtime string eval, do, and require are a serious pain in the butt. > > They're the one set of things that'll force a real interpreter into a > program. > >*nodnod*. This is really tricky; if there's no eval in the program, we can >make all sorts of interesting optimizations: forego the whole SV process, and >just use ints and char*s and whatever. If there's an eval, you've got to throw >everything back into Perl-space, embed an interpreter, and all that jazz. What about introducing a pragma which either (a) promises not to use such things, or (b) throws an exception if the program does use such constructs, and say "if you want your programs to be compilable (or compile to something a heck of a lot lighter), say 'use strict "compilation"' or whatever"? -- Peter Scott Pacific Systems Design Technologies
Re: What will the Perl6 code name be?
At 01:10 PM 10/24/00 +0200, Philip Newton wrote: >On 23 Oct 2000, at 15:40, Peter Scott wrote: > > What about introducing a pragma which either (a) promises not to use such > > things, or (b) throws an exception if the program does use such > constructs, > > and say "if you want your programs to be compilable (or compile to > > something a heck of a lot lighter), say 'use strict "compilation"' or > > whatever"? > >Hm, but such code (for non-trivial programs) will re-invent the wheel a >whole lot, won't it? Since "use" includes a "require". (On the other >hand, it's a require in a BEGIN block, so that may not be a problem >after all.) Well, the idea was that people developing a script they intended to be compiled one day would have feedback on whether or not it could be done (or done with an overhead) whenever they tried executing it, rather than only finding out when they tried compiling it, which could be somewhat less frequently. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
At 12:01 PM 10/3/00 -0400, John Porter wrote: >How would you down-convert a complex math formula to ascii from, say, xhtml? > >You know, I'm thinking TeX would make a great extension language for pod. >Simple, powerful, text-based, with translators to lots of other formats, >and good tool support (e.g. emacs modes). Arrgh, you're giving me WEB flashbacks... I nearly went blind trying to read that stuff... As I said earlier, why don't we just define a syntax for *anything* to be used as an extension language, and let the, er, market decide? -- Peter Scott Pacific Systems Design Technologies
Expressions and binding operator
perlop: >Binary ``=~'' binds a scalar expression to a pattern match. [...] The >right argument is a search pattern, substitution, or transliteration. [...] > >If the right argument is an expression rather than a search pattern, >substitution, or >transliteration, it is interpreted as a search pattern at run time. Should this second paragraph still be true for Perl 6? I have at times wanted to do something of the form perl -lwe '$x = "x"; $y = "y"; $y =~ ($x eq "x" ? s/y/z/ : s/y/a/); print $y' but I have not wanted to make the right argument an expression to be interpreted as a search pattern (since I have qr//). -- Peter Scott Pacific Systems Design Technologies
Re: Expressions and binding operator
At 11:39 PM 12/20/00 +, Nicholas Clark wrote: >On Wed, Dec 20, 2000 at 03:36:48PM -0800, Peter Scott wrote: > > Should this second paragraph still be true for Perl 6? I have at times > > wanted to do something of the form > > > > perl -lwe '$x = "x"; $y = "y"; $y =~ ($x eq "x" ? s/y/z/ : s/y/a/); > print $y' > > > > but I have not wanted to make the right argument an expression to be > > interpreted as a search pattern (since I have qr//). > >I presume that you don't find > >perl -lwe '$x = "x"; $y = "y"; $x eq "x" ? $y =~ s/y/z/ : $y =~ s/y/a/; >print $y' > >does what you need because you actually want to do something a lot more >complex than simple "$y =~" in your expression. >Or do I guess wrong? Oh, that certainly works, and I wouldn't have any complaint on grounds of brevity alone unless I wanted an lvalue expression like ($x ? $y : $z) instead of $y. But since this is a Perl 6 list, I'm making an inquiry on syntactical convenience grounds. What I wanted to write *feels* Perlish. -- Peter Scott Pacific Systems Design Technologies
Re: [Fwd: Re: [FWP] sorting text in human-order]
At 04:34 PM 12/28/00 -0500, John Porter wrote: >I seem to recall someone suggested on perl6-language a while back* >(or was it perl6-internals?) that perl ought also to support efficient >sorting of large volumes of data by using disk, the way unix sort does. >Pluggable algorithms would make this possible too. >Although, I suppose you'd actually like to make it possible for perl >intrinsics to use disk buffers whenever necessary, globally. > >(*If the mail archives were searchable, I'd give an actual reference.) http://www.mail-archive.com/perl6-language@perl.org/index.html http://www.mail-archive.com/perl6-internals@perl.org/index.html Although I cannot find an article referring to what you mention. It does sound familiar though. -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
At 07:12 PM 2/1/01 -0600, David L. Nicol wrote: >I recalled hearing about a language (was it java?) where >you set the return value of a function (was it VB?) by >assigning to the name of the function within the function body, >so the last line would be > > fname=rval; > >or fname could be used instead of rval all through it. Ah, an homage to Pascal :-) -- Peter Scott Pacific Systems Design Technologies
Re: a name for the currently executing sub
At 06:35 PM 2/5/01 -0600, David L. Nicol wrote:
>--- warning --- bad idea follows ---
You're not kidding.
>Are we willing to let user-code use codereftagstrings abckwards yet?
>
>perl -le '$a = \(1..4); $tagstring="$a"; print @{$tagstring}'
>
>We would eliminate all strings matching /^[A-Z]\(0x[0-9a-f]+\)\z/ from
>use as variable names. I don't think that would break all that much but
>the 5->6 converter could identify ref->stringify and mung it slightly,
>maybe add a \0 at the end or something.
>
>We would gain C style casting capability, with all the evil that brings
>with it, including the ability to bittwiddle perl structures from
>within perl, which is a feature migrating C programmers miss.
This migrated C programmer misses it like intestinal flu.
Can you come up with one remotely useful example?
--
Peter Scott
Pacific Systems Design Technologies
Re: Really auto autoloaded modules
At 08:44 AM 2/6/01 +, Simon Cozens wrote: >On Mon, Feb 05, 2001 at 11:04:06PM -0500, Dan Sugalski wrote: > > Granted, if this was all done with trusted servers it would be really neat, > > but... > >TANSTAATS. Not even with the appropriate amount of PKI/X.509 hand-waving? -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
At 09:59 AM 2/7/01 -0500, John Porter wrote:
>Tony Olekshy wrote:
> >
> > I think "always" should be part of an explicit statement, such
> > as "try", not some implied property of block structure introduced
> > by a dangling clause (inside or outside).
>
>Why? For that matter, why must "try" itself be explicit?
>It says, "I'm probly gonna put some exception catchers on this block,
>so if I do, choke fatally if I haven't put the magic word up here."
>This strikes me as exceedingly un-Perlish, though of course quite
>natural in B&D languages like C++ and Java.
I want the 'try' there for my sake, not Perl's; I don't care whether some
other languages couldn't parse the block without the word, but for me, it
helps alert me that the following block is subject to non-local control
flow rules.
I'd rather have the 'try' there for the same reason I want to see the 'do'
in "do { ... } while ..." (well, leaving aside the fact that it would be
unparseable without it). But I certainly understand your preference.
--
Peter Scott
Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
At 05:07 PM 2/7/01 -0500, John Porter wrote: >Peter Scott wrote: > > Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine > that > > the following block is going to be subject to exception handlers which > will > > immediately follow as siblings of the block. > >O.k. That makes sense if some blocks can be try blocks (by adding the >approprate decoration) and some aren't. >But I don't see the advantage of it if any and every block is >implicitly a try block. Me neither. I don't want that. -- Peter Scott Pacific Systems Design Technologies
Re: assign to magic name-of-function variable instead of "return"
At 02:17 PM 2/7/01 -0500, John Porter wrote:
>Peter Scott wrote:
> >
> > I want the 'try' there for my sake, not Perl's; ... it
> > helps alert me that the following block is subject to non-local control
> > flow rules.
>
>Huh? Down that road lies the Java madness.
>
> eval {
> foo();
> };
>
> sub foo {
> bar();
> }
>
> sub bar {
> die $barney;
> }
>
>All three of these blocks are "subject to non-local control flow rules",
>including the body of foo.
Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
the following block is going to be subject to exception handlers which will
immediately follow as siblings of the block. Somewhat as I would look at
an if...elsif...else construct, it helps me put the block in context as I'm
reading it and also look ahead fo those handlers. I prefer this to
discovering a handler as I'm reading and then looking for the enclosing
block, or coming across an undecorated block and scanning to see if this is
because it has embedded handlers or is to create a closure, or to use a
redo, or...
--
Peter Scott
Pacific Systems Design Technologies
Re: Auto-install (was autoloaded...)
At 05:00 PM 2/8/01 -0200, Branden wrote: >I wrote: > > I think zip is the way to go! Is there any > > platform/license or any other restricting issues we should care about zip? > > Is it ported to all platforms Perl currently runs on? Is there a Perl >module > > for handling zips? > >Aren't we re-inventing the wheel here? It strikes me now that ActiveState's >ActivePerl comes with PPM, or `Perl Package Manager'. AFAIK, it's only for >downloading from ActiveState's site, and it only handles installing of >individual modules (althought it checks dependencies and fetches needed >modules as well, but it doesn't solve the problem for scripts/programs). > >Anyone of ActiveState there? Can't we adapt PPM so that it handles what's >needed? Or is it too different from what we want? Does it use zip or >tar/gzip or other? Eh? I thought PPM was simply "perl -MCPAN -e install" for Windows users, pointed to a set of modules which have XS content that they'd had to fiddle with to port to Win32. -- Peter Scott Pacific Systems Design Technologies
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 01:16 PM 2/13/01 -0500, James Mastros wrote: >On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote: >Certainly AUTOLOAD gets > > called if DESTROY is called but not defined ... just > > like any other method. >The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to >do refcounting (or somthing like it) for DESTROY to get called at the right >time if the class (or any superclass) has an AUTOLOAD, which is expensive. > >Perhaps you could declare, but not define, DESTROY to have AUTOLOAD called >for DESTROY, and have DESTROY called as soon as the last ref goes out of >scope. (IE have a sub DESTROY; line.) This may be a naive question, but what is the benefit - aside from consistency, and we don't need to rehash the litany on that - to AUTOLOAD getting called for DESTROY? I've never actually seen any code that makes use of it. I have grown somewhat tired of writing, and teaching, "return if $AUTOLOAD =~ /:DESTROY$/", however. -- Peter Scott Pacific Systems Design Technologies
Re: End-of-scope actions: Background.
At 03:27 PM 2/13/01 +, Nicholas Clark wrote: >I fear I'm not adding anything apart from noise to this debate. >(partly from not having thought through the issues completely, partly by >not reading the full archives for the list from last year) > >On Mon, Feb 12, 2001 at 01:58:35PM -0700, Tony Olekshy wrote: > > Or as Larry said in his ALS talk, "a completely object-oriented > > exception handling, with a simple string-like interface for those > > who do not want the power of the full OO system." See the notes > > at http://www.avrasoft.com/perl6/rfc88.htm#CONVERSION for more > > information on how this works. > > my $f = open $file or die "can't open $file"; > >is troublesome. It doesn't report *why* the file can't be opened. > >[snip] >errno is not flexible. *flexible* exceptions are needed >[snip] >I think that it would be nice in 5.8 to (optionally on some pragma?) make >print, close and a few others in void context croak. > >It would actually make writing perl scripts easier. You'd know when your >disk became full (or you went over quota), albeit in with a messy error. >OK, script crashing with an uncaught exception isn't nice, but it's nicer >than silently losing data IMHO. I think you'll find this addressed already in RFCs 70, 80, and 151. At least, that was my intention. http://dev.perl.org/rfc/70.html http://dev.perl.org/rfc/80.html http://dev.perl.org/rfc/151.html -- Peter Scott Pacific Systems Design Technologies
Re: End-of-scope actions: Background.
At 10:35 AM 2/13/01 -0800, I wrote: >I think you'll find this addressed already in RFCs 70, 80, and 151. At >least, that was my intention. Urp, poorly worded. Should be, "my intention in the two RFCs out of these three that I wrote." Don't want to appear to be trying to claim credit for RFC 70 here. >http://dev.perl.org/rfc/70.html >http://dev.perl.org/rfc/80.html >http://dev.perl.org/rfc/151.html -- Peter Scott Pacific Systems Design Technologies
Re: Garbage collection (was Re: JWZ on s/Java/Perl/)
At 06:35 PM 2/13/01 +, Nicholas Clark wrote:
> > This may be a naive question, but what is the benefit - aside from
> > consistency, and we don't need to rehash the litany on that - to AUTOLOAD
> > getting called for DESTROY? I've never actually seen any code that makes
> > use of it. I have grown somewhat tired of writing, and teaching, "return
> > if $AUTOLOAD =~ /:DESTROY$/", however.
>
>Doesn't
>
> sub DESTROY {}
>
>have the same effect but with less typing?
Sure (with debatable comments about maintainability since the declaration
is decoupled from the reason - sub AUTOLOAD - for it being there), but the
point still stands.
--
Peter Scott
Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 01:15 PM 2/15/01 -0500, John Porter wrote: > > my $a, $b, $c;# only $a is lexically scoped > >RTFM. Quite. But on a tangent, I see no good reason why this shouldn't be given the same interpretation as "my ($a, $b, $c)" on the grounds that functions taking list arguments that omit their parentheses swallow up the following list. And if the retort is, "my isn't a function," then I would like to know what it really is and why it's listed in perlfunc along with other things that aren't functions. If that's not enough controversy I can also ask about things which are labelled as both functions and operators :-) -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 11:49 AM 2/15/01 -0800, Randal L. Schwartz wrote:
> >>>>> "Peter" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>Peter> Quite. But on a tangent, I see no good reason why this shouldn't be
>Peter> given the same interpretation as "my ($a, $b, $c)" on the grounds that
>Peter> functions taking list arguments that omit their parentheses swallow up
>Peter> the following list.
>
>*some* functions. localtime doesn't.
Er, that's why I said functions taking list arguments. localtime takes a
scalar argument:
$ perl -le 'print prototype("CORE::localtime")'
;$
But if we consider my to be a function (something of a stretch since it has
compile-time actions), then it must take a list argument otherwise my ($a,
$b, $c) would be illegal.
> my is a unary function, prototyped
>vaguely as (\$) or (\@) or (\%).
More like ((\$)|(\@)|(\%))+, for want of a better notation...
--
Peter Scott
Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 12:43 PM 2/15/01 -0800, Edward Peschko wrote: >On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote: > > On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: > > > well, I was thinking about this - there really should be an extra > switch that > > > makes this possible, rather than typing 'no strict; no warn;' ie: > > > > > > #!/usr/local/bin/perl -q # for quick and dirty. > > > > We already have a switch that means "quick and dirty", it's called > > "-e" > >Beautiful. then just co-opt it. Right now when I say: > >#!/usr/local/bin/perl -e > >in a file i get > >Can't emulate -e on #! line at a.p. > >Either that, or add '-q' as a file version for '-e'. > >And in any case, make '-e' have the additional connotation that implies >'no strict', and 'no warn'. no 'warnings' > Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., http:[EMAIL PROTECTED]/msg00025.html Better get the asbestos underwear ready. -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 01:03 PM 2/15/01 -0800, Edward Peschko wrote: > > http:[EMAIL PROTECTED]/msg00025.html > >Well, I agree with pretty much everything you said, except I like '-q' better >than '-z' for aesthetic reasons. > >So... what was the rationale against it? Best read the archives... I am the wrong person to ask for a statement of the opposing viewpoint... -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 09:01 PM 2/15/01 +0100, [EMAIL PROTECTED] wrote: >On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote: > > However, that still doesn't get rid of the gotchas - personally I think > that: > > > > my $a, $b, $c; > > > > should be an error, a warning, or DWIM. Especially: > >Personally, I don't think so. > > GetOptions (foo => \my $foo, > bar => \my $bar); > >and > > tie my $shoe => $tring; > >are just way too practical to suddenly require more hoops. I don't want to DWIM this. Would it be so bad to have to type GetOptions (foo => \my ($foo), bar => \my $bar); tie my ($shoe) => $tring; if we made 'my' consistent with all other functions that take lists (yes-I-know-it's-not-a-function)? -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
At 09:56 AM 2/16/2001 -0500, John Porter wrote: > > As for the -q thing, I think it is far *less* of a burden to add "use > > strict" and "use warnings" when you're writing a big piece of code. When > > you're writing 5 lines, every extra character counts. When you're > > writing 500 or 5000 lines, 2 lines of "use" statements are nothing. > >I disagree. We're talking about the added burder of -q in > perl -qe 'print "Just Another Perl Hacker,"' We're not even talking about that. All the -q/-z proponents have said that it should be implied by -e, so one-liners would have unchanged syntax. And people who want their longer scripts to run blissfully free of the ravages of error checking can put -q on the #! line. Whereas the rest of us currently have to remember to put use strict in every blasted .pm. >vs. adding > use strict; > use warnings; >near the top of -- not just one, but probably several or dozens of files. It was only relatively recently that I realized that the one at the beginning of the main program was insufficient :-(
Re: Warnings, strict, and CPAN
es. And if they *never* find out how to disable the messages, then at least they'll generate better code with strictness turned on, and won't end up driving people insane in clpm pasting "run your code under -w and you'll see why it failed" in replies. >I like strict, you like strict, lots of other people really, really >don't like it. Large-scale Perl programmers want strict on, >small-scale like to have it off. I'm not going to repeat the reasons >here, dig through the perl6-language-strict archives for them. Both >have valid arguments, both represent large chunks of the community. > >We have a case where the two sides win conditions are conflicting. >Keeping strict off has one major advantage, it won't break any >existing code. Turning it on by default will break probably the >majority of code out there. That would be Bad. Maybe. It might also improve the majority of code out there to the point where Perl's reputation is improved. In this area, it could stand it, IMHO. > We don't want >everyone to have to run their entire code-base through p526. The net >result will be people running 5.6 in 2010. > >That's what is boils down to. If 1/10 of the stuff mooted for P6 gets in there, it'll be sufficiently different from P5 that this will be a minor change. > > 2) the fact that I'm NOT trying to hide '-q' from users, but > advertising > > its existence upto the point where it comes along with every > single > > perl command that has errors for the beginning two iterations of > > perl. > >Yes, people will find it and they will use it. Thus defeating the >point of having warnings and strict default. With the difference that this time they'll know they're doing it, rather than not knowing they're not enabling reporting. >If you try to enforce discipline without understanding they will >simply work around it. I don't see this; unless perl6 is turned to spit out "Run again with -q to remove this message" after every error, I don't think there's likely to be a large underground movement of newbies papering "Run all your Perl programs with -q" notices on lampposts. Point being, by the time they've expended the effort to find out about -q, they should have a bit more of a clue as to why it's not the default. Plus perlrun can say next to -q, "IF YOU RUN WITH THIS FLAG NO-ONE WILL GIVE YOU ANY HELP, LUSER." > And don't dismiss 1 as trivial. I personally have spent hours > > tracking down simple bugs that I otherwise would have found within > > SECONDS with 'use strict'. > >So turn on strict!! First thing, before you start debugging. Perl >does not supply the discipline, that way Java^WMadness lies. Now now, there's tons of discipline that isn't supplied even with strict. And discipline that is supplied without it. strict/-w do not constitute Java madness or you wouldn't be using Perl. > > > Instead of Yet Again arguing back and forth on this, go write me some > > > code auditing tools. > > > > hey, but this fight is worth fighting. > >No, its really not. You're just charging back and forth over the same >old No Man's Land. No matter what the decision, one side or the other >will be cheesed off and no real net gain will be had. > >Good programmers will still be good programmers and bad programmers >will still be bad, no matter how many switches you flip or pragmas you >make them use. True, but I'm not claiming that changing the default will accomplish this, only that it will accomplish what I already described. Look, the docs already say that the fact that -w is not the default is a bug. What should we do, change the docs? Or leave it in there for P6 and build a new language with an admitted bug in it from the beginning? >No language will solve this. No Silver Bullet. Yes, but not the point. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 10:13 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote: >On Fri, Feb 16, 2001 at 06:22:45PM -0800, Edward Peschko wrote: > > I *want* a global switch. I want the ability to never have to forget to > type > > 'use warnings' in a package and track it down for hour upon hour. Or 'use > > strict'. I do not agree with this argument of Edward's. >Now, if warnings & strict are default... > >1. You use -q. Not good, but its quiet. >2. You say C and you only get your own problems. >3. You use -w and you STILL only get your own problems! > >Why? Because everyone's got a "warning policy" (ie. C). But wouldn't -W still do what it does now? >The net effect is you can no longer see potential problems inside 3rd >party software and there's no way to turn warnings back on that code >except through editing the source. Result? More time spent trying to >figure out what the hell is wrong. > >Your warning policy encourages sweeping problems, not just under the >carpet, but into the ocean! Just a sec. If someone shipped a module with 'no warnings', then either they had a good reason for doing so, and we should respect it and not be bothered by it, or they don't know what they're doing and we shouldn't be using their code. More likely the latter. Right now, if I wanted to impose strictness on third-party modules, I'd have to edit the source to insert the 'use strict' that no-one seems to bother putting in a .pm. Hmph. Maybe I should be doing that, it might help. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 09:36 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote: >On Fri, Feb 16, 2001 at 06:08:20PM -0800, Peter Scott wrote: > > But if you want P6 to be so backwards > > compatible that the largest issues are smaller than "@", an awful lot of > > good stuff ain't gonna make it in, it seems to me. 'Sides, we already got > > some clues that P6 won't have to be that backwards compatible with P5. > >Perl 6 is going to break things, fine. But break them for a better >reason than saving a few keystrokes, please. S'not about saving keystrokes, as many times as I do type the same things in every file; it's about giving newbies the right introduction to the language and providing appropriate feedback at the appropriate level of individual development. > > I repeatedly tell people, "If you're handed a program that doesn't have > > -w/use strict in it, hand it back and say, Please insert -w/use strict, > and > > give it back to me when you've eliminated all the resulting messages," > and > > many of those people have thanked me for that instruction. So far, > > no-one's said it was a bad idea. > >That's fine if people know why. Some people don't. Some people know >why and decide otherwise. Complicate it by the fact that its no >longer a human rejecting your perfectly valid code, but a computer. >People will resent it. strict/warnings are not that picky; the odds that the code is more wrong than right are very good if they complain. "But it produces the right answer" is not a defence. You know that; why else would you develop with them? Anyone who resents the feedback is in the wrong business. >You also have to take into account the legions of sysadmins who use >Perl as more powerful shell scripting. Do not equate not using strict >and warnings with "newbie". Okay, but these people are not going to be put out by sticking -q on the #! line. > > I don't get this. If someone's developing code right now with "use > > warnings", and they want to ship with warnings disabled, they gotta edit > > the code anyway. > >They're not using the warnings pragma, they're mostly using -w when >its run and tested. Alternatively, you can set PERL5OPT='-w' on your >development machines (though I haven't heard of this in wide >practice). Eh? I still don't get it. You're saying that instead of typing 'foo', these people are typing 'perl -w foo' every time, to save themselves from putting -w on the #! line? That's insane. >Code style is a very, very emotional and personal issue. Adding any >default enforcement is going to piss off lots and lots of people. Just like the lack of it has already pissed off lots of people :-) >Just look at how much discussion this topic has generated all over the >lists! What's the net gain? Some vague ideas about making people >more aware of warnings and saving a few keystrokes. I don't find the ideas vague... and they could save clpm from descending into a cesspool of iniquity. Oops, too late... >Instead, let's concentrate on some more tangible areas of need. Perl >is almost completely lacking in code metric tools. We have no >statistical analysis tools, our coverage library is barely there and >our two profiling tools are anemic and underdocumented. Our lint >checker is an early alpha. CPAN has no security checks, no author >signatures, little auditing. Vast sections of perl's core libraries >and source code are not covered by tests, etc... All agreed, and orthogonal. So you concede the point, eh? :-) -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
Redirected to -strict to save the sanity of thousands of people who don't care.
At 03:48 PM 2/16/01 -0800, Edward Peschko wrote:
> > Its a fine rationale, but I'm very, very loathe to implicitly split
> > Perl into two seperate languages based on what the filename is.
>
>Why? Its not the filename, its how its used -
>
> require("A"); # library - strict, warnings on
> use A;# library - strict, warnings on
> do "A"# library - strict, warnings on but who cares, do is
> # hardly ever used.
>
> eval("\$a = '1'");# code - strict off
>
>The functionality for adding 'strict' and 'warnings' would be added onto use
>and require.
This is, what's the word I'm looking for... nuts. We split code into
modules for purposes of reuse, not because it's somehow more worthy of
error checking. I don't want to have to remember this invisible
action-at-a-vast-distance rule to figure out why code in different places
behaves differently wrt pragmas.
--
Peter Scott
Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
#x27;t want to require anyone to have to >automate the editing of Perl code. I don't get this. If someone's developing code right now with "use warnings", and they want to ship with warnings disabled, they gotta edit the code anyway. How is commenting out "use warnings" at release time different from inserting "no warnings" at release time? And if they're developing the code all the way through without warnings (in which case they don't deserve to have customers), then they'll just put "no warnings" or -q in there from the start and there's no release editing required. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 11:00 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote: > > strict/warnings are not that picky; the odds that the code is more wrong > > than right are very good if they complain. "But it produces the right > > answer" is not a defence. You know that; why else would you develop with > > them? Anyone who resents the feedback is in the wrong business. > >No, they're not in the wrong business, they're just learning. "But it >produces the right answer" may not be a valid defense, but it is a >common one and you and I aren't going to be around to tell them it >isn't. Forcing extra stricness on a new programmer only works if >there's a mentor around to help them through the process and explain >things. Help me out here. You're saying: User: perl -e 'print 1/$x' Perl: Illegal division by zero at -e line 1 User: Okay, run-time error, no problemo, I can handle that. User: perl -we 'print 1/$x' Perl: Name "main::x" used only once: possible typo at -e line 1. Use of uninitialized value in division (/) at -e line 1. User: Okay, that's it, if you're going to whine like that I'm switching to Ruby. > > >You also have to take into account the legions of sysadmins who use > > >Perl as more powerful shell scripting. Do not equate not using strict > > >and warnings with "newbie". > > > > Okay, but these people are not going to be put out by sticking -q on > the #! > > line. > >We're talking about the folks who call things 'ls' instead of 'dir' >because its one less character to type, right? Oh well, then we should call the new executable 'p' instead of 'perl'. I checked... it's not taken... > > >Code style is a very, very emotional and personal issue. Adding any > > >default enforcement is going to piss off lots and lots of people. > > > > Just like the lack of it has already pissed off lots of people :-) > >Yes, but like it or not, they have over 10 years of precedent behind >them. We're used to this situation, the screaming has already been >done, the scabs are healed over. Let's not pick at them. I've always picked at 'em... in any case, the mandate for Perl 6 design was to consider everything fair game, within user-defined reason. We may well eliminate bareword filehandles in Perl 6, just 'cos they no longer make sense; seems we might as well go for everything we want to fix. If we don't create a better language when we have the chance, someone outside of Perl will do it and name it after a snake or something... -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 11:00 PM 2/16/01 -0500, [EMAIL PROTECTED] wrote:
>On Fri, Feb 16, 2001 at 06:52:22PM -0800, Peter Scott wrote:
> > S'not about saving keystrokes, as many times as I do type the same things
> > in every file; it's about giving newbies the right introduction to the
> > language and providing appropriate feedback at the appropriate level of
> > individual development.
>
>You're making it sound like -w is a personal tutor!
I could go for this...
perl -we '$h{$_} = 1 for @a'
It looks like you don't understand hash slices. Would you like a brief
explanation of how they work?
> nodammit
That sounded to me like "yes". Examples of hash slices:...
And if they're running PerlTk, it pops up a little paper clip saying all
this stuff.
--
Peter Scott
Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 02:37 AM 2/17/01 -0500, [EMAIL PROTECTED] wrote: >On Fri, Feb 16, 2001 at 09:03:54PM -0800, Edward Peschko wrote: > > Right now, I do a search on the standard distribution, and I see > > 'use warnings::register' in 13 out of 270 modules. Make 'use warnings' the > > default, and you'd bet that there would be a big push to make the standard > > distribution clean. > >No, there will probably be a big push to shut it off, based on >historical reactions to this sort of thing. Maybe I'm missing something; I'm sure the philosophy is for the standard distribution to be -w clean, so shouldn't everything be equally okay with use warnings? > > THAT DOES NOT WORK. First of all, your syntax is off - the > > '-Mw..-Ms..' one will ignore the '-Mstrict' part and generate an > > error because -M can only take one argument. But more importantly, > > THIS IS NOT UNIVERSAL AND CANNOT WORK IN A UNIVERSAL SCOPE. > >Hmm, its damned silly that you can't give two modules on the command >line. ??? $ perl -Mwarnings -Mstrict -le 'print keys %INC' Exporter.pmCarp.pmstrict.pmwarnings.pm -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 02:47 AM 2/17/01 -0500, [EMAIL PROTECTED] wrote: > > >Yes, but like it or not, they have over 10 years of precedent behind > > >them. We're used to this situation, the screaming has already been > > >done, the scabs are healed over. Let's not pick at them. > > > > I've always picked at 'em... in any case, the mandate for Perl 6 design > was > > to consider everything fair game, within user-defined reason. > >Yes, but its questionable which one is "better". Given a fresh start >writing a new language, I'd definately say warnings by default. I'd >also say arrays should start at one, not zero. But we've got a large >and diverse community to deal with. > >This is very much a 6.0 of one, 12.0/2.0 of another type of situation. Okay, I think we should agree to disagree at this point and back away from the keyboards... I've made my best arguments and I hate reruns. By now everyone knows what we both think and they're probably sick of it to boot. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 02:49 PM 2/17/01 -0500, [EMAIL PROTECTED] wrote: >PERL5OPT='-Mwarnings -Mstrict' perl -wle 'print keys %INC' >unkown warnings category '-Mstrict' at -e line 0 >BEGIN failed--compilation aborted. > >It seems to be parsing that as: C. IMHO this >is a bug. Yes, MJD pointed it out last November in http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-11/msg01107.html. Simon Cozens submitted a patch which failed the test; I think I found the problem with it and just submitted a revised patch to p5p. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN
At 02:49 PM 2/17/01 -0500, [EMAIL PROTECTED] wrote: >On Sat, Feb 17, 2001 at 11:09:29AM -0800, Peter Scott wrote: > > >No, there will probably be a big push to shut it off, based on > > >historical reactions to this sort of thing. > > > > Maybe I'm missing something; I'm sure the philosophy is for the standard > > distribution to be -w clean, so shouldn't everything be equally okay with > > use warnings? > >Try it and see! I'm serious. It'll be an interesting experiment. I started trying it and hit something really weird... or maybe I've just been working too many days in a row. Why this difference depending on whether I reference a module with an absolute path or a relative one? [peter@tweety ~]$ /usr/bin/perl -wc /usr/lib/perl5/5.6.0/Shell.pm /usr/lib/perl5/5.6.0/Shell.pm syntax OK [peter@tweety ~]$ cd /usr/lib/perl5/5.6.0/ [peter@tweety 5.6.0]$ /usr/bin/perl -wc /usr/lib/perl5/5.6.0/Shell.pm /usr/lib/perl5/5.6.0/Shell.pm syntax OK [peter@tweety 5.6.0]$ /usr/bin/perl -wc Shell.pm Name "Shell::capture_stderr" used only once: possible typo at Shell.pm line 3. Shell.pm syntax OK [peter@tweety 5.6.0]$ cd .. [peter@tweety perl5]$ /usr/bin/perl -wc 5.6.0/Shell.pm Name "Shell::capture_stderr" used only once: possible typo at 5.6.0/Shell.pm line 3. 5.6.0/Shell.pm syntax OK Nothing up my sleeve: [peter@tweety perl5]$ env | grep -i perl PWD=/usr/lib/perl5 [peter@tweety perl5]$ Color me baffled. And it's not just that module, there are many that exhibit this behavior, so it's something to do with perl -cw. -- Peter Scott Pacific Systems Design Technologies
Re: The binding of "my" (Re: Closures and default lexical-scope
At 12:12 PM 2/18/2001 +0100, Bart Lateur wrote: >On 17 Feb 2001 20:53:51 -0800, Russ Allbery wrote: > > >Could > >people please take the advocacy traffic elsewhere where it isn't noise? > >Advocacy is noise everywhere. Not on [EMAIL PROTECTED] (http://lists.perl.org/showlist.cgi?name=advocacy)
Re: Warnings, strict, and CPAN
At 02:18 PM 2/18/01 -0800, Edward Peschko wrote: >On Sun, Feb 18, 2001 at 07:30:50PM -, Paul Marquess wrote: > > From perllexwarn: > > > > -W > > > > If the -W flag is used on the command line, it will enable > > all warnings throughout the program regardless of whether warnings > > were disabled locally using no warnings or $^W =0. This includes all > > files that get included via use, require or do. Think of it as the > > Perl equivalent of the ``lint'' command. > >hmm. No mention in the camel. Then you're looking in the wrong Camel. It's on page 502 in the first printing of the third edition. -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 05:27 PM 2/19/01 +, Piers Cawley wrote: >Peter Scott <[EMAIL PROTECTED]> writes: > > I don't want to DWIM this. Would it be so bad to have to type > > > > GetOptions (foo => \my ($foo), > > bar => \my $bar); > >If you're really all for maintainability, then surely you mean: > >GetOptions (foo => \my ($foo), >bar => \my ($bar)); > >otherwise some dumb hacker (eg. You, two weeks later) could come to >add annother pair of args by sticking C<, baz => \my $baz> into the >args list... Yup, yup. > > tie my ($shoe) => $tring; > > > > if we made 'my' consistent with all other functions that take lists > > (yes-I-know-it's-not-a-function)? > >Do you not *care* how ugly you're making something that was once >compact, expressive and elegant? Of course I care. I just weighed the advantage (consistency, intuitiveness in the case of my $a, $b, $c which is far more common than either of the above) against the disadvantage and decided it was worth it, on balance. Subscribers to different value systems may have different results. >And if it's not a function then WTF >do you want to make it look like one, potentially sowing more >confusion. I'd be happy to retract my position if someone would take the thing out of perlfunc then. I'd really also like to see a more definitive description than "language construct" at the same time. -- Peter Scott Pacific Systems Design Technologies
Re: State of PDD 0
At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote: >At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote: >>Bryan C. Warnock writes: >> > Ask, all, are we reusing perl6-rfc as the submittal address, or will there >> > be a new one (perl-pdd)? >> >>I'm in favour of renaming to reflect the new use of the list. Dan? > >I've been thinking since I sent my last mail on this that we might >actually want to leave the two (PDD & RFC) separate. Keep on with the RFCs >for 'external' things,... I suggest that we clearly delineate the RFCs which were pre-deadline from the ones that are post-deadline. The advantage to having the original deadline was that it motivated many of us to get off our butts and fish or cut bait. If we're going to continue this process now, I move that: New RFCs be numbered starting from 1000 (easiest way to denote the difference); Old RFCs are frozen, and that means frozen. I have no idea how far Larry's got on digesting them and I really don't want to try and interfere with something that could be making its way down his small intestine. People should be free to write new RFCs that contradict older ones, or head off on some tangent, but please let's not keep refining the old ones, enough is enough. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Are we still having this discussion? :-) At 07:23 PM 2/21/01 -0500, [EMAIL PROTECTED] wrote: >Its true alot languages would consider many of Perl's warnings to be >errors, that's not really analgous to what we're talking about here. > >Run-time errors aren't quite in the same spirit as run-time warnings. >A run-time error is something the language defines as being explicitly >bad or a mistake (even if it can be caught as an exception). Run-time >warnings are just the language saying, "excuse me, there might be a >problem here". An error is, "NO, YOU'RE WRONG!!" > >Errors and exceptions must be dealt with, else your program won't run. >Warnings... they can be ignored. I do not think there is hard dividing line between warnings and errors. "Unable to establish network connection - saving file to local disk" means the program is still running afterwards. The more fault-tolerant your program is, the more your errors look like warnings. Is that message an error or a warning? > Warnings are often stylistic in >nature, errors are not. An error is often a very concrete indication >that something is wrong, a warning is not (if it was, it should be >promoted to an error). > >With that in mind, do we have any analogies? > >I can think of some GUI analogies. Macster (the Macintosh Napster >client)* requires that you confirm every download you cancel. >Windows, by default, requires that you confirm everything you drop >into the trash (or whatever they call it this week). Most software >installers require that you click [Accept] after reading the >agreement. Some even require that you scroll down to the bottom >before letting you accept. > >The result? People either shut them off or mindlessly click [Ok]. >Nobody** sits there and things "gee, do I really want to throw this >out?" Nobody reads software licenses. Or government warnings on cigarettes. >Its not that there's anything wrong with these ideas, but its the >continual bombardment which dulls the senses against them. If the >user has internalized the need for them (say, they once deleted a file >which cost them their job) then it might be helpful. > >Similarly, a wet-behind-the-ears programmer will not give Perl's >warnings much credence if their program runs fine despite of them. >They will be ignored until such time as they internallized, through >error or teaching. I suppose I'm in an exceptional class then, 'cos whatever language I'm using, any warning at any time causes me to stop what I'm doing, and fix the cause. Even if that means selectively ignoring the warning through a pragma. I've been doing this since I used Saber C (actually before that, too): fix the cause, or put an ignore directive in. Never mind how picky it seems. I am somewhat frightened by the prospect of anyone programming with a mindset that warnings are okay, and even more by the philosophy that we should cater more to them than more careful people. What if the warnings were: 1/100 chance of destroying your files at this point... you win! 1/100 chance of producing incorrect output at this point... you win! 1/100 chance of losing user data at this point... you win! ... What if the warnings boiled down to that anyway? -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
At 09:36 AM 2/22/2001 +, David Grove wrote:
>This is what's scaring me about all this talk about
>exceptions... it can break this mold and make Perl into a "complainer
>language" belching up uncaught (don't care) exceptions forcing try/except
>blocks around every piece of IO or DB handling. The style
>
>try {
> open(FOO, "./foo");
>}
>catch FileOpenException $e {
> die "Drat:" .$e->Message. "\n";
>}
>
>is horrifying to me over the normal
>
>open(FOO, "./foo") or die "Drat:$!\n";
Now steady on. No-one is proposing getting rid of the normal way of doing
it. We're just talking about beefing up another WTDI. There are situations
in programs that have dozens or hundreds of lines of code which benefit
from the exception model just as much as your example.
Re: Turn 'em on! (was Re: Warnings, strict, and CPAN)
At 03:56 AM 3/1/01 -0500, Michael G Schwern wrote:
>A friend of mine was talking about how old WWII era analog fire
>computers, mechanical devices which calculated how much powder and at
>what angle a ship's main guns must be fired at. They had a special
>switch, "Battle Mode". In this mode, the computer would never stop.
>It would ignore all errors and just keep cranking out numbers. It might
>give wrong answers, it might melt down, but it would never stop. In
>the middle of a fight, you don't want your fire computer to crash.
>
>Asserts use this sort of philosophy, which is why they have an NDEBUG
>flag which allows you to shut them off program-wide.
>
>PERL_BATTLE_MODE environment variable anyone? ;)
$SIG{__DIE__} = sub { die $ENV{PERL_BATTLE_MODE} ? <<"FNORD" : shift};
Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux
(egcs- on $^O
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
SyntaxError: invalid syntax
FNORD
--
Peter Scott
Pacific Systems Design Technologies
Re: Distributive -> and indirect slices
At 03:18 PM 3/19/01 +, Simon Cozens wrote:
>That's not really nuts. Really nuts would be suggesting that all operators
>should distribute:
>
> @a = ($foo, $bar) . $baz # @a = map { $_.$baz } ($foo, $baz)
>
>Mmmm. I could get to like that.
Seen http://dev.perl.org/rfc/82.pod?
--
Peter Scott
Pacific Systems Design Technologies
Re: Schwartzian Transform
At 10:50 AM 3/26/2001 -0500, Uri Guttman wrote:
> > "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
>
> SC> Why can't Perl automagically do a Schwartzian when it sees a
> SC> comparison with complicated operators or functions on each side of
> SC> it? That is, @s = sort { f($a) <=> f($b) } @t would Do The Right
> SC> Thing.
>
>because that would require the PSI::ESP module which isn't working
>yet. how would perl intuit exactly the relationship between the records
>and the keys extraction and comparison?
I'm kinda puzzled by the focus on Schwartzian when I thought the GRT was
demonstrated to be better. Anyway, all we need is a syntax for specifying
an extraction function and whether the comparison is string or numeric. If
the parser can be persuaded to accept an array ref instead of a block, how
about
sort [ '<=>' => \&f ] @t
doing The Right Thing? I guess you could also pragmatize it if you wanted
a particular transform:
use sort qw(schwartzian);
Someone could probably turn this into "use the schwartz".
Re: Larry's Apocalypse 1
At 11:46 PM 4/4/01 -0700, Nathan Torkington wrote: >Not a comment at all on it? Was I accidentally unsubscribed to >perl6-language? > >*tap* *tap* is this thing on? Some of us got to reading Damian's design for Perl 5+i which was announced at the same time and are suffering from blown minds after learning how fast he wrote the thing. Oh, and who put him up to that, eh? -- Peter Scott Pacific Systems Design Technologies
Re: Apocalypse 1 from Larry
Okay, you want comments, I got yer comments... I am, naturally, most interested in this part: >[24]RFC 16: Keep default Perl free of constraints such as warnings and >strict. (Keep the groans to a dull roar, please.) > To me, one of the overriding issues is whether it's possible to >translate Perl 5 code into Perl 6 code. One particular place of >concern is in the many one-liners embedded in shell scripts here and >there. There's no really good way to translate those invocations, so >requiring a new command line switch to set ``no strict'' is not going >to fly. I thought we'd made the point that we didn't expect stricture for -e. Perhaps this speaks to shell scripts that do perl <A closely related question is how Perl is going to recognize when it >has accidentally been fed Perl 5 code rather than Perl 6 code. It >would be rather bad to suddenly give working code a brand new set of >semantics. The answer, I believe, is that it has to be impossible by >definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 >must assume it is being fed Perl 5 code until it knows otherwise. And >that implies that we must have some declaration that unambiguously >declares the code to be Perl 6. Okay, but if you can tell that you're parsing Perl 6 rather than Perl 5, why not leave the default strictness the way it is for Perl 5 programs, and turn it on for Perl 6 programs? New language, new expectations, chance to make new rules. I keep coming back to the POD that says that the fact that -w is not the default is a bug. > Now with one fell swoop, much of the problem of programming in the >large can be dealt with simply by making modules and classes default >to strict, with warnings. But note that the default in the main >program (and in one liners) is Perl 5, which is non-strict by >definition. We still have to figure out how Perl 6 main programs >should distinguish themselves from Perl 5 (with a ``use 6.0'' maybe?), >and whether Perl 6 main programs should default to strict or not (I >think not), but you can already see that a course instructor could >threaten to flunk anyone who doesn't put ``module Main'' at the front of >each program, and never actually tell their pupils that they want that >because it turns on strictures and warnings. Sorry? It wouldn't just turn on strictures and warnings, it would change the interpretation from Perl 5 to Perl 6... and there appear to be enough clues about Perl 6 to deduce that one would know whether one was writing Perl 5 or Perl 6. And "module Main" would be a no-op except for the side effect... so might as well say "use 6.0" instead since it makes the intent clearer. I love the stuff about policy files. > I also happen to agree with this RFC because it's my philosophical >position that morality works best when chosen, not when mandated. >Nevertheless, there are times when morality should be strongly >suggested, and I think modules and classes are a good place for that. This goes to the point. I could argue that I don't see strictures as 'morality', and I think that's just an accidental consequence of the name; suppose it had been called 'use salvation' instead? But there's no way to win a values debate. -- Peter Scott Pacific Systems Design Technologies
Re: Larry's Apocalypse 1
At 12:38 PM 4/9/01 -0400, Dan Sugalski wrote: >>>One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go >>>the multiflagged way, why not reflect `-e' to get the `-6' flag? At >>>the very least, I want a short flag! >> >>But by the time people learned to use '-6' we'd have Perl 7 out. > >I'm still trying to figure out why the flag needs to change. What's wrong >with -e? It seems perfectly serviceable. Because Larry said that by default Perl 6 would assume that its input was in Perl 5...? So we need a way to tell it that it isn't. -- Peter Scott Pacific Systems Design Technologies
Re: Larry's Apocalypse 1
At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote: > > > Hmm... programs that have perl one-liners inside them might be > > > troublesome. > > > > Why not: > > > > perl -e 'perl 5 one-liner' > > > > perl --cmd 'perl 6 one-liner' > > > > i.e. maintain the "-e" switch as a backward compatibility flag, with a new > > cmd line flag for perl 6. > >One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go >the multiflagged way, why not reflect `-e' to get the `-6' flag? At >the very least, I want a short flag! But by the time people learned to use '-6' we'd have Perl 7 out. Whatever we come up with, let's figure out how to avoid having to change it the next time we change Perl. -- Peter Scott Pacific Systems Design Technologies
RE: Larry's Apocalypse 1
At 09:45 AM 4/11/01 +1000, Greg Boug wrote: >Hrmm... It'd have interesting repercussions for CPAN... :-) > >How about doing something like: > >use lib "CPAN::HTML::Module"; > >which goes and grabs the module in question from CPAN for >use. Picking, the closest mirror, of course. > >Would be interesting, but is probably bloatware... It should by default use a local cache, of course. I suppose if you're running it as root it should do a perl -MCPAN -e 'install HTML::Module'. I seem to have misplaced my security hat... -- Peter Scott Pacific Systems Design Technologies
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 12:11 PM 4/16/01 -0400, Dan Sugalski wrote: >There are a number of reasons to *not* claim to parse perl 5 code. > >*) We won't load any perl 5 XS code >*) We won't be getting the corner cases, and perl5 has a *lot*. >*) It complicates the interpreter if we need to add code to support things >that perl 6 doesn't do. (*ocugh*typegobs*cough*) >*) It makes the parser that much more work to write. Even if we switch >parser code entirely when going from perl 5 to perl 6 and back, someone >still has to write the code in the first place. >*) It's even more complexity, which is just that much more stuff we can >potentially break >*) It sets up the expectation (rightly so, IMNSHO) in the user community >that we eat and process all perl 5 code correctly, and we just aren't >going to. Despite our best efforts we're not going to. As a very low-tech solution, why not bundle perl 5 *with* perl 6 so that once perl 6 detects that it's been fed perl 5 code, it can send it to the perl 5 compiler/interpreter. Yeah, I know it makes the resulting bundle huge, but at least it separates the tasks of parsing perl5 and perl 6 into independent projects. -- Peter Scott Pacific Systems Design Technologies
Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)
At 02:33 PM 4/16/01 -0400, Dan Sugalski wrote: >At 09:47 AM 4/16/2001 -0700, Peter Scott wrote: >>As a very low-tech solution, why not bundle perl 5 *with* perl 6 so that >>once perl 6 detects that it's been fed perl 5 code, it can send it to the >>perl 5 compiler/interpreter. > >Besides the size and clunkiness issues, there's another problem. String >evals in a perl 5 section of code will expect to be parsed as perl 5, >which kinda precludes the whole "compile perl 5 to bytecode and pass it >through the p526 converter" solution. Makes mixing and matching perl5 and >perl 6 code rather more difficult. :( Er, I don't get it. I'm proposing that if perl 6 determines it's been given perl 5 code, it does "exec perl5 $0". So thereafter it's as though perl 6 never existed as far as that code is concerned; whatever it wants to do should be completely independent of any perl 6 code. I'm bypassing the "compile perl 5 to bytecode and pass it through the p526 converter" solution. I have my doubts as to how well that's going to work with things like XS anyway. Or were you espousing the notion that perl 6 programs should be able to contain sections of perl 5 code? That gives me strange palpitations. -- Peter Scott Pacific Systems Design Technologies
Re: Strings vs Numbers (Re: Tying & Overloading)
At 09:06 PM 4/24/2001 -0700, Larry Wall wrote:
>Edward Peschko writes:
>: Ok, so what does:
>:
>: my %hash = ( 1 => 3);
>: my $hash = { 1 => 4};
>:
>: print $hash{1};
>:
>: print?
>
>4. You must say %hash{1} if you want the other.
I was teaching an intro class yesterday and as usual, there were several
people who typed just that instead of what I'd taught, so there is
obviously some intuitive merit to it.
Re: Apoc2 - concerns
At 01:51 AM 5/6/01 +0100, Simon Cozens wrote: >The debate rages on: Is Perl Bactrian or Dromedary? It's a Dromedary, it says so in the Colophon. But maybe the symbol of Perl 6 should be a Bactrian, with the extra hump symbolizing the increased power. You knew this was coming... -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: So, we need a code name...
At 08:33 AM 5/6/01 -0500, Jarkko Hietaniemi wrote: >On Sun, May 06, 2001 at 01:31:17AM -0600, Dan Brian wrote: > > For your collective amuse() abuse() dismiss() I humbly submit: > > > > "duran" (or derivatives) > > > > Aside from conjuring images of "reflex", "rio", and maybe "Barbarella" > > for a select few, the word occurs in some interesting contexts. It means > > little aside from it being a last name, a city name, and bearing > > resemblence to some neat stuff. One bummer is the likeness to > > AMD's "Duron". *shrug* > >"durian". You want to name it after a fruit smelling of dead cows and sewer gas? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: So, we need a code name...
At 08:27 PM 5/6/01 +0100, Michael G Schwern wrote:
> durian
>n 1: tree of southeastern Asia having edible oval fruit with a
> hard spiny rind [syn: {durion}, {durian tree}, {Durio
> zibethinus}]
>2: huge fruit native to southeastern Asia `smelling like Hell
> and tasting like Heaven'; seeds are roasted and eaten like
> nuts
>
>I think that's rather descriptive of Perl in general. Its huge, hard
>on the outside, soft on the inside, smells really nasty but if you're
>brave enough (or dumb enough) to take a bite it tastes wonderful.
Have you seen one? Hard as a rock and covered with spikes. If one fell on
you from more than three feet it would spell instant death, which would
probably be more merciful than being exposed to the smell.
Grocers either stock them outside or frozen.
It's not what I'd call a positive image :-)
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Apoc2 - concerns
At 10:32 AM 5/8/01 -0700, Larry Wall wrote: >: One of the places I hope to gain some speed is in eliminating flattening >: and reconstitution of aggregate variables as much as possible. I'm hoping >: to exploit this really heavily to save both the memory for the flattened >: lists and the time it takes to flatten and reconstitute. (If we're really >: lucky we might even be able to rehome some of the underlying data >: structures, making returning a 10M entry hash cost about one pointer >: assignment) > >I suspect one way this saves us a lot of overhead is in knowing how >much memory to allocate for a given subroutine's stack frame. The way >it is done in Perl 5, we pay the variadic stack overhead even on >subroutines that are known not to be variadic. This is suboptimal, >since you have to be ready to extend the stack at any moment. (It also >tends to pessimize linkage into pseudo-variadic languages like C.) Um, how do you know for sure a subroutine isn't variadic? Even if it has a fixed-length prototype, is Perl smart enough to know that it can't be called as an object method, bypassing prototype checking? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Perl, the new generation
At 11:11 PM 5/10/01 +0100, Simon Cozens wrote: >On Thu, May 10, 2001 at 04:41:09PM -0400, David Grove wrote: > > > Anywhere else? :) > > FreeBSD comes to mind, among others. > >Hm. You initially restricted your survey to commercial vendors, but now >you are moving the goalposts. > > > Can we get back to the subject now? > >Certainly. The subject was whether or not Perl 5.6.x has been taken >up by the industry. Sigh. Do I dare wade back in? But the voices in my head won't stop :-) With respect - and I do mean that - the subject as I started it was, Is "Perl 6" the most appropriate title for what we discuss here and what brave people like yourself will be implementing? If it's at all possible to discuss that without devolving into tangential political debates, I'd like to do so. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Perl, the new generation
This is a long shot, but here goes. I was thinking about Perl 6 this morning while jogging (blithely ignoring the forest scenery). It occurred to me that what appears to be emerging as the new language embodies bigger changes than I ever anticipated - which is great, software should improve with time. And so I found myself wondering whether the title does it justice. Perl 6 is looking to me almost like an entirely new language. The change from Perl 5 to Perl 6 is much, much larger than the change from Perl 4 to Perl 5 (virtually all Perl 4 code ran unmodified under Perl 5). So, I wonder aloud, do we want to signify that degree of change with a more dramatic change in the name? Still Perl, but maybe Perl 7, Perl 10, Perl 2001, Perl NG, Perl* - heck, I don't know, I'm just trying to get the creative juices flowing. I do believe that the tremendous effort that is going into Perl 6 deserves more attention than I think it will get with that title. At some point, the Perl 6 cognomen will have attracted enough inertia that we couldn't reasonably change it even if we wanted to. Maybe that time has already come. Maybe not. Can't hurt to raise the question. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Perl, the new generation
At 09:20 AM 5/10/01 -0700, I wrote: >At some point, the Perl 6 cognomen will have attracted enough inertia that >we couldn't reasonably change it even if we wanted to. Maybe that time >has already come. Maybe not. Can't hurt to raise the question. I retract the last sentence. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
RE: Perl, the new generation
At 12:47 PM 5/10/01 -0400, David Grove wrote: >Unless Perl 6 is capable of parsing and running that 99.9% (or higher) of >Perl 5 scripts originally foretold, I foresee a far worse outcome for Perl 6 >than has happened for an almost universally rejected 5.6 and 5.6.1. > >Fun is fun. But work costs money, guys. And if you cost people money with a >free tool, repercussions could be bad not just for Perl but for free >languages, among which Perl has heretofore been the leader of the pack. > >Actually, Peter, I was getting very, very close to writing this anyway. I am not attempting to make nearly so contentious a point (or points). This may be better off in a separate thread. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Perl, the new generation
At 05:36 PM 5/10/01 +0100, Michael G Schwern wrote: >Version numbers are, at best, an indication of the magnitude change. >At worst they are a cheap marketing ploy. I've always liked that >Perl's version numbers are relatively free of marketing hoopla (the >jump from perl3 to perl4 notwithstanding). The move from 5.005_03 to >5.6.0 style was jarring enough (and fairly well justified). Its been >so long since we've had an integer increment that it should be fairly >shocking. Eh, I fully understand that version number magnitudes are simply to attract attention, and that The Faithful don't need the glitz. Since AFAICT the glitz doesn't hurt, though, it doesn't do any harm to give marketing all the help it can get; and let's face it, marketing hasn't been Perl's greatest strength. I was one of the people calling for 5.006 -> 5.6, since the changes, to me, were greater than what was implied by an increment in the fourth significant digit. And it worked, too; I finally saw a couple of articles in trade (non-geek) rags about the upgrade. More or less the only articles about Perl I've seen there for 5 years. (I'm talking about rags like Information Week, Internet Week, Computerworld, that sort of thing.) I'm just applying the same principle here, comparing to the Perl 4 -> Perl 5 change. Like I said, I figure it's a long shot; I just thought I'd run it up the flagpole. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Must pseudo-hashes die?
At 07:47 PM 5/15/01 +, Ton Hospel wrote: > > PSEUDO-HASHES MUST DIE! > > > >I happen to like them I like the feature of a hash whose keys are fixed in the sense that you have to jump through a hoop to add a new one. Without having to download Tie::SecureHash and accept the other features it provides. I'd like to see this in Perl 6. I detest the pseudo-hash implementation (the part that's exposed to the user, I mean). -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Perl, the new generation
At 12:45 PM 5/16/01 -0400, Adam Turoff wrote: >On Wed, May 16, 2001 at 08:57:42AM -0700, Peter Scott wrote: > > It doesn't look to me like the amount of Perl one needs to know to achieve > > a given level of productivity is increasing in volume or complexity at > > all. What it looks like to me is that there are additional features being > > added which enable one to achieve greater levels of productivity and > > performance if one wants to learn them. > >Who *wants* to be unproductive? ENONSEQUITUR. I'm saying that the current ratio of productivity to (learning) investment is undisturbed. Adding features which allow greater productivity with greater investment is a natural progression. Not taking advantage of them does not disturb one's current level of productivity one whit. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
RE: Perl, the new generation
> It's not so much that Perl shouldn't have data structures or modules. > I think what Stephen is saying (and he's not the only one) is that > the bare minimum amount of Perl you *must* know to be productive > is increasing. Either that, or we're giving the impression that > it's increasing. Many people don't want to get bogged down in how > the details of Unicode, upperclass level CS topics or Perl's unique > syntactical peculiarities to parse a damn log file (or find and > use a CPAN module that does it). It doesn't look to me like the amount of Perl one needs to know to achieve a given level of productivity is increasing in volume or complexity at all. What it looks like to me is that there are additional features being added which enable one to achieve greater levels of productivity and performance if one wants to learn them. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Exegesis2 and the "is" keyword
At 10:51 AM 5/16/01 +0200, Carl Johan Berglund wrote: >At 15.02 -0700 01-05-15, Nathan Wiger wrote: >> $*ARGS is chomped; >> >>I wonder if that wouldn't be better phrased as: >> >>autochomp $*ARGS;# $ARGS.autochomp > >I see your point, but I see a clear difference between these properties >and actions taken on the variable. When we say $*ARGS is chomped, we don't >ask $*ARGS to do anything right away, just remember that when we later ask >it to return something, we want that something chomped. I've been reading "is" as a declarative imperative, something which declares a property of something you are creating. Here it's being used to moify the properties of something that already exists, and it reads funny to me. Many properties that one can set at declaration time are compile time only, yet this usage might suggest to many people that they can be changed at run time. If you see what I mean. I'm sure I could get used to it, I'm just speaking to learnability. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Perl, the new generation
At 01:51 PM 5/16/01 -0600, Nathan Torkington wrote: >Hmm, it'd be interesting to see a Map of Perl. Operators, functions, >modules, features, etc. divided up according to topic and complexity >and laid out around the central blob of "Basic Perl" that everyone >knows (variables, assignment, math, chomp, printing, etc). Hmm, I see, so core Perl would be the USA, with scalars in Kansas and hashes in California... moving further afield, objects are European, and tie() is Greek. XS code seems to fit in Polynesia. Then weird stuff like pseudo-hashes are in the really outlying areas like New Zealand... -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Slice refs
Um, this is a tiny little diversion here prompted by something that came up
on perl-beginners, of all places... it's not possible in perl 5 to make a
reference to an array or hash slice without doing some copying. It would
be nice if perl 6 made that possible. Maybe it already does and I haven't
grokked that from the exegeses yet.
That's it. We now return you to the Clinton discussion ("it depends what
the meaning of 'is' is...")
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Slice refs
At 01:31 PM 5/21/2001 +1000, Damian Conway wrote:
>> Um, this is a tiny little diversion here prompted by something that
>> came up on perl-beginners, of all places... it's not possible in
>> perl 5 to make a reference to an array or hash slice without doing
>> some copying.
>>
>
>Hey, this is *Perl*! Of course it's possible...
>
>@A = (1..10); # array
>@I = (3..5);# indices of desired slice
>
>$ref =
> sub{my%k;@k{@{+pop}}=\(@_);splice@_,$_,!$k{$_}for reverse
> 0..@_;\@_}->(@A,\@I);
Oh, well, if I'd known it was *that* succinct...
But... that *does* involve copying; the original poster was talking about
huge arrays where copying was actually significant. You've got the list of
keys and values in the temporary hash there. It certainly violates the
spirit of the request. Which still seems like a reasonable request.
A reference to a slice in perl 5 yields the list of the references to the
slice members. Is that the way it's going to be in perl 6?
Re: Properties and stricture
At 07:29 PM 6/5/01 +0100, Michael G Schwern wrote:
>Consider the following... Foo is a poster-child for a strict class.
>Everything is predeclared and typed. Its entire hierarchy is rock
>solid. Someone uses Foo in their script and calls Foo->bar. They
>also use Bar, a module you installed a long time ago. Bar does this:
>
> package Bar;
> eval "sub Foo::bar { 23 }";
>
>Oh crap! All the wonderful compile-time checking we did on Foo has
>just been blown to pieces.
>[snip]
>Before anyone gets the wrong idea, I don't think the solution is a
>drastic scaling back in Perl's flexibility. I just don't know what
>the solution is yet. Maybe it should be possible for a class to
>completely seal off its namespace to the outside world on request.
I would like to see some sort of "use really_strict" pragma which would
disable at compile time the kinds of things you mentioned:
>No subroutine refs. No dynamic inheritance. No autoloading. No
>dynamic method calls. No symbol table manipulation. No eval. No
>automatic method generation. (That's off the top of my head).
Of those, only subroutine refs and automatic method generation look like
must-haves for major projects, which are willing to surrender some of the
cute stuff in return for stability.
Quite how Foo prevents Bar from causing shenanigans if Bar was used first,
I don't know; might not be possible until runtime.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Properties and stricture
At 02:39 PM 6/5/2001 -0700, Daniel S. Wilkerson wrote: >Thank you, that's what I thought it might be. This can be done at compile >time with a two-stage >compilation. The first one writes the code that the second >compiles. Then the checking can be >done during the second stage. Not when the methods to be generated aren't determined until run time.
Re: Multi-dimensional arrays and relational db data
At 05:58 PM 6/10/2001 -0400, Sam Tregar wrote: >SQL via DBI. It's got a terrible learning curve but it's still around for >a reason. You learn all about SQL's strengths if you start trying to >replace it with arrays and hashes. Go forth and learn! He's right. I do a lot of DBI stuff with Oracle, and every so often I have a hankering for some kind of structured tied variable that would look like my database. Then I wake up and realize that modeling of a single table doesn't do squat for me, and modeling of the whole database requires knowledge of the foreign key relationships, and even with those, no variable structure suggests itself. And then I remember this is why I wrote object classes modeling the things I want to get out of/put into the database. Even if your database is so simple that you do just want to model single tables, it would be easy to build atop DBI. Didn't we have this discussion about six months ago??? I do think it's worth thinking about new variable types for Perl. I keep thinking to myself, how do we continue the progression C -> Perl 4/5 -> ..., where Perl 4/5 said things like, let's make hashes basic variable types, since they're so mind-bogglingly useful. Not that you couldn't do them in C with library functions, but look how much easier they are to read. So I think, what's the next step? But I just keep drawing a blank. Once I spent some time wondering about design patterns and templates, but that didn't lead anywhere either. The thing I don't want to happen is for all the work to go into O-O features, because at the end of the day, all O-O programs look much the same: instantiate a bunch of objects and call methods on them. Then it seems like the only thing left to talk about is whether you use -> or . for component separators. I want Perl to make it easy to implement algorithms, rather than just trying to compete on the same playing field as other O-O languages, because it's just too handicapped by things like performance and lack of static analysis.
Re: Multi-dimensional arrays and relational db data
At 11:07 PM 6/10/01 -0500, Me wrote: > > > [joining 2d arrays] > > > I can't envisage this... Perhaps you could reveal an example. >Seems simple to me. Perhaps you meant the concrete >method and/or syntax to achieve the join, or to reference >the two arrays, or to reference the result table. But thinking >of concrete details like that is way premature. No it isn't. Your position depends on having a syntax so simple that it is somehow worth implementing as a native capability instead of the tied modules others have pointed out. My point is that I don't think there is a syntax that's simple enough to be worth it. > > Particularly I can't envisage it for multicolumn > >Joining the first and last cols of array 1 with the second >and last cols of array 2 would pick the first row from both >arrays. > >Again, this seems simple to me. I understand relational joins. I'm looking for the syntax you propose to use for expressing them. >It's cumbersome describing this in english, but I >would expect it to be really brain dead simple >intuitive as a computer syntax and semantics. I still don't think there's anything to be gained here. As far as I can tell, you're saying, "I want it to be easier to express relational database operations." Me too. I just don't think they get any easier than they already are. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Multi-dimensional arrays and relational db data
At 06:06 PM 6/10/2001 -0500, Me wrote: >Dataset from multiple 'joined' tables > > (A pair of joined tables can be visualized as two > spreadsheet like grids that intersect at right angles > with the intersection point being the joined column. > The vertical slice picks out rows where the joined > column values from the two tables are the same.) > > Whatever is used to support vertical slicing based > on col data should be extensible to do joining too. I can't envisage this. Particularly I can't envisage it for multicolumn joins or outer joins. Perhaps you could reveal an example. I don't know where I was thinking of this being a previous thread. There is some interesting stuff in http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-03/msg01830.html and the followups. I'm still enamored of the $dbh =~ qs// idea.
Re: Multiple classifications of an object
At 11:44 AM 6/25/01 -0700, David Whipp wrote: >When you blass an object in Perl, you give it exactly >one type. The @ISA variable allows that type to refer >to many other classes as the inheritance tree. @ISA >is a list, but ref($obj) isn't. This means that you >sometimes have to create a lot of useless classes to >work around this limitation. > >A simple example: Imagine you have a class "Person". >A Person can be Male or Female. Thats one set of >subclasses. But a Person can also be Employed or >Unemployed. So I might want to say > >bless $self, qw(Employed Male); > >In Perl5 I am forced to create 4 new classes: >Employed_Male, Employed_Female, Unemployed_Male, >Unemployed_Female. The combinatorial explosion can, >well, explode! The other standard solution is to >add a "Person has-a Employment_Status" relationship, >but that doesn't feel much better. Its just another >way of programming round a weakness in the object >models of most mainstream languages > >Can anyone see any problems with making C and >C work with lists? C is not effected. We >might want some magic to ensure 'ref($foo) eq "bar"' >still works as expected. What's wrong with multiple inheritance? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: Per-object inheritance in core a red herring?
At 04:20 AM 6/30/01 -0400, [EMAIL PROTECTED] wrote: >On Sat, Jun 30, 2001 at 01:47:39AM -0600, Dan Brian wrote: > > > Everyone's making these assumptions, WHY WON'T ANYONE LOOK AT > > > CLASS::OBJECT?! > > > > It might not work, Schwern. And even if it did, it might be really slow. > > Somebody should write an implementation first, and then tackle efficiency. > >This is a joke, right? I'm on Candid Camera. I think people are just surprised that you didn't call it Red::Herring. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
Re: type sigils redux, and new unary ^ operator
On Tue, 22 Nov 2005 14:34:12 -0800, Larry Wall wrote:
> What tipped me over the edge, however, is that I want ^$x back for a unary
> operator that is short for 0..^$x, that is, the range from 0 to $x - 1. I
> kept wanting such an operator in revising S09. It also makes it easy to
> write
>
> for ^5 { say } # 0, 1, 2, 3, 4
It seems strange to have a shortcut for 0..$n-1 but no shortcut for 0..$n.
I'm also puzzled that you feel the need to write 0..$n-1 so often; there
are so many alternatives to fenceposting in P5 that I almost never write
an expression like that, so why is it cropping up that much in P6?
--
Peter Scott
Re: handling undef - second draft
I have occasionally felt it would be nice to be able to distinguish between shifting an explicit undef value off an array and calling shift() on an empty array without having to test the length of the array. Is that likely to fall out of any of the current thinking? I do not want shift() on an empty array to die by default. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
Re: Perl 6 Summary
At 01:54 PM 7/3/02 -0600, Thom Boyer wrote: >I'm personally MUCH more interested in >Python's generators ><http://www.python.org/peps/pep-0255.html>. > >A generator is like an iterator in that it can produce a series of values. >But unlike >iterators, when you ask a generator for the next value, it picks up >execution exactly where >it left off when it returned the last value -- including all it's stack. Isn't that a coroutine? I thought they were already slated for P6. *Rummage* Yes: http://www.yetanother.org/damian/diary_April_2001.html Or if you like: http://www.yetanother.org/damian/Perl5+i/coroutines.html -- Peter Scott Pacific Systems Design Technologies
Re: Continuations for fun and profit
At 04:54 PM 7/8/02 -0400, Dan Sugalski wrote: >A continuation is a sort of super-closure. Like a closure it captures >its lexical variables, so every time you use it, you're referring to >the same set of variables, which live on until the continuation's >destroyed. This works because the variables for a block are kept in a >scratchpad--since each block has its own, and each scratchpad's mostly >independent (mostly). > >Now, imagine what would happen if the 'stack', which we track block >entries, exits, sub calls, and so forth, was *also* done with a linked >list of scratchpads, rather than as a real stack. You could have a >sort of "super closure" that both remembered all your scratchpads >*and* your spot in the call tree. That, essentially, is what a >continuation is. We remember the scratchpads with variables in them >*and* the scratchpads with stack information in them. > >When we invoke a continuation, we put in place both the variables and >call scratchpads, making it, in effect, as if we'd never really left >the spot we took the continuation at. And, like normal closures, we >can do this from wherever we like in the program. So if you could serialize a continuation, you could freeze your program state to disk and restore it later? Cool, makes for easy checkpoint/restarts. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/
Re: A thought for later -- POD tables
Maybe this train has already left the station, but I find myself preferring Kwiki syntax to POD these days... any chance we could use Kwiki with WAFL for the Perl 6 POD? That of course has already got tables. (Still bracketing with the =for ... =cut directives, though.) Just a thought... -- Peter Scott
Re: Perl 6 Summary for 2004-10-01 through 2004-10-17
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matthew Walton) writes: >Austin Hastings wrote: >> Does this mean that we're done? :) > >No, it means Larry's about to stun us with something seemingly bizarre >and inexplicable which turns out to be a stroke of genius. This conjured up an image of Larry whacking someone with a coelacanth... -- Peter Scott http://www.perldebugged.com/ *** NEW *** http://www.perlmedic.com/
RE: This week's summary
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Austin Hastings) writes: >PS: While I'm somewhat sympathetic to the fact that eu guys are trying to >spin up 200 years worth of amendments and supreme court decisions at the >same time, it's still a ratf*ck. Eu need to get eurselves a Larry. Just put Damian on it, and there'll be a Lingua::EU::ConstitutionGenerator by Christmas. Probably with a back door making him king with droit du seigneur option in perpetuity. -- Peter Scott http://www.perldebugged.com/ *** NEW *** http//www.perlmedic.com/
Re: looking for good project to learn perl6
Raku libraries for Keras/Tensorflow, or AWS, or Kubernetes, leveraging the novel features of Raku, could be killer apps for Raku. Ambitious, though. Peter Scott > On Dec 7, 2019, at 7:24 PM, Tom Blackwood wrote: > > > Hello William, > > We are actually a small team making the primary job for big data/machine > learning etc. > We know nothing about mailing list gateway and NNTP stuff. > But thanks for your suggestion, I will take a took at the references you > provided. > > Regards > Tom > > >> On Sun, Dec 8, 2019 at 3:30 AM William Michels wrote: >> Hi Tom, >> >> My vote would be for someone to take on the task of writing >> "mailing-list" software in Raku/Perl6, and/or writing >> "mailing-list-archiving" software (e.g. an NNTP server) in Raku/Perl6. >> First of all, for your group this would be a relatively-high profile >> project, with the potential for hundreds or even thousands of >> companies adopting such a module for their own institutional or >> company needs. >> >> Regarding the "archiving" module in particular, you could see how the >> Perl mailing lists are archived, and easily imagine how they might be >> improved. There would be a need to access data from a database, filter >> out spam, organize the data by date and/or thread, and serve up the >> data in a web-accessible format. Selfishly, I would love to see a >> searchable archive of every Perl6/Raku email ever written. >> >> I've communicated with Ask Bjorn Hansen about the Perl software >> presently running the NNTP archive (www.nntp.perl.org), in particular >> the Perl6-Users mailing list. Ask Bjorn Hansen says the NNTP archive >> runs on Colobus which is written in Perl, with commits going all the >> way back to 2001. So why not rewrite it in Raku/Perl6?? In particular, >> I was hoping to see a better "subject threading" algorithm, since with >> Colobus (on occasion) emails from different "eras" are lumped together >> in the same thread (example: emails from 2010 showing up in Sept. 2019 >> threads). >> >> I don't know if your group has an interest in writing a full-blown >> NNTP server, but below are resources for Raku/Perl6, Python, and R. >> You can decide for yourself if the Raku/Perl6 resources need >> improving: >> >> Raku/Perl6: >> https://www.nntp.perl.org/group/ >> https://www.nntp.perl.org/group/perl.perl6.users/ >> https://trainedmonkey.com/projects/colobus/ >> https://github.com/abh/colobus >> >> Python: >> https://www.python.org/community/lists/ >> https://mail.python.org/archives/ >> https://mail.python.org/mailman/listinfo >> >> R: >> https://www.r-project.org/mail.html >> https://stat.ethz.ch/mailman/listinfo >> https://r.789695.n4.nabble.com >> >> >> HTH, Bill. >> >> >> >> On Fri, Dec 6, 2019 at 1:59 AM Tom Blackwood wrote: >> > >> > Thanks, I'll check it out! >> > >> > On Fri, Dec 6, 2019 at 5:50 PM JJ Merelo wrote: >> >> >> >> Try something in the most wanted repo: >> >> https://github.com/perl6/perl6-most-wanted/blob/master/most-wanted/modules.md >> >> That way you will learn _and_ help the community. >> >> >> >> El vie., 6 dic. 2019 a las 8:11, Tom Blackwood () >> >> escribió: >> >>> >> >>> Hello >> >>> >> >>> My team most time developed with ruby language. >> >>> These recent days we took time reading the book Learning Perl 6. >> >>> Then we consider to take an actual project to learn more deeply. >> >>> What project do you suggest for us to get involve into? >> >>> >> >>> Regards, >> >>> Tom >> >> >> >> >> >> >> >> -- >> >> JJ
Re: A grand idea on the documentation
On 12/9/2019 6:06 AM, ToddAndMargo via perl6-users wrote: What school did you go to? Students rate good and bad teachers, good and bad material ALL-THE-TIME. This is a function they are entitled to exercise because they are paying the teachers. As you yourself said: When I was in college, I actually got rid of two bad teachers. Ya, I am a bit of jerk over teachers that take my money and don't do their jobs. If you're trying to get rid of the people who write Raku documentation (who, contrary to your labeling, are not teachers but developers, and either way, unpaid), you're making fine progress. Your repeated questioning of Liz's native language as a diversion from your dissembling about use of derogatory language as though there were no difference between connotative and denotative terms serves only to alienate you from people who have expended enormous effort to help you. If you really don't understand the connotations of referring to someone as a dog then at least understand that it is offensive to most people and expend the necessary effort to learn how to conduct yourself in a community of volunteers. The reference documentation is for reference. You want tutorials. That's a different animal, and exists for Raku mostly in the form of books and e-books which you stated you do not want to study. The major issue with the documentation is that it targets the wrong audience. Those that understand the cryptography, don't' need the documentation. They already know what it is suppose to say. Developers need reminders, in the most succinct form, to minimize time, of data that they should not need to memorize. The documentation satisfies that need in the same way that a phone book satisfies the need to look up someone's number. The phone book is not bloated with explanations of each person's favorite food or the history of the phone company. Your 'keeper' documents sound like they should be shared with others who may be in the same situation as you. Please follow the suggestions for how to do that so you can see how they are received. Peter Scott
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 1/15/2020 2:39 PM, ToddAndMargo via perl6-users wrote: On 2020-01-15 14:18, Elizabeth Mattijsen wrote: Thank you Richard for this long and thoughtful answer. I have already given up on Todd, I'm glad to see others haven't (yet). What will follow is probably a response that is either: a. everybody is against me, b. the Raku community won't listen, c. the various variations on those themes. I sincerely hope that I'm wrong. Liz Hi Liz, Richard has not liked me for a long time. [...] And I even like you too. You help me with things and you don't even like me. ToddAndMargo, you may be in the wrong line of business. Programming a computer requires understanding the computer the way it is, not the way you would like it to be, and to make progress in that understanding you need to be able to understand what people are telling you. The computer will not care whether you like it and it certainly neither likes nor dislikes you. Succeeding in this endeavor requires that you replicate the computer's rigor within your mind; fuzziness in that understanding will result in failure. Yet when people demonstrate for you the required rigor you repeatedly take issue with their assistance or attribute an emotional bias to it. Liking or disliking someone has no bearing on their prowess as a programmer. All that counts is that they understand the abstractions, and that is what people have been trying to help you with, but your comments suggest you see their assistance only through a like/dislike filter. You're making this so difficult for yourself I think that programming is not a good choice of career for you. Certainly you are not demonstrating how someone should behave in a community of developers to grow their skills while respecting the other members of the community. -- Peter Scott
Re: irrational nubmer?
On 2/26/2020 11:14 AM, ToddAndMargo via perl6-users wrote:
I used gnome calculator to 20 digits:
665857/470832
1.41421356237468991063
Sorry. Not seeing any repeating patterns.
Here is NAS doing it to 1 million digits (they have too
much time on their hands):
https://apod.nasa.gov/htmltest/gifcity/sqrt2.1mil
No repeats.
As well there shouldn't be in an irrational number. sqrt(2) !=
665857/470832
So why does base-repeating tell me there is a repeating
pattern when there is not?
Ah ha, 99/70 does have a repeat:
1.4142857 142857 142857 1
Maybe 665857/470832 I just do not go out enough digits to
see a repeat.
Correct. As a really disgustingly quick and dirty way of proving that
the expansion has a repeating cycle of 576 digits:
$ perl6 -e 'say
665857000/470832'
| perl -lne '/(\d{4,})\1/ and print length $1, ": $1"'
576:
135623746899106262955788901349101165596221157440445849050192000543718353892683589900431576443402317599483467563801950589594590002378767798280490705814388146939885139497740170591633533829476331260407109117477146837937948142861997485302613246338396710503958949264281102388962517415978523125021238998198932952730485608454820403031229822951711013694906038671967920617120331668195874536989839263261630475413735684915213919189859652699901451048356951099330546776769633329935093621504060896455635980562068848336561661059571142148367145818466034594080266421993407414959051211472457267
Re: OAuth2?
On 3/21/20 2:20 PM, ToddAndMargo via perl6-users wrote: On 2020-03-18 18:42, ToddAndMargo via perl6-users wrote: This is a long shot, but have any of you figured out how to send eMail through G-Mail with OAuth2? I have a module that uses cURL, but I can't figure out how to get it to work with OAuth2. RFE: please support OAuth2 https://github.com/retupmoca/P6-Net-SMTP/issues/24 Is in the works, but I need to get something going by June 2020 as s-suite will stop supporting Less Secure Apps at that time. Found this: python & smtplib: Is sending mail via gmail using oauth2 possible? https://stackoverflow.com/questions/11445523/python-smtplib-is-sending-mail-via-gmail-using-oauth2-possible But it is python we doh't have anything equivalent to import oauth2 as oauth import oauth2.clients.imap as imaplib I am in almost exactly the same situation. I don't need to send mail, but I do need to read Gmail through IMAP and rename folders and move messages. I am under the same deadline and have done extensive research without getting anywhere. The documentation and online Q&A do not get me very far.
Re: Is the cosine page wrong?
On 12/28/20 10:57 PM, ToddAndMargo via perl6-users wrote: On 12/28/20 4:54 AM, Richard Hainsworth wrote: So please take what I say now as a plea for you to adapt a little, not to get pissed off with us even though you do seem to have pissed some of us off. You have very definite ideas about what the documentation should and shouldn't be. You have stated them over and over again. The Raku community at large - based on replies from multiple individuals over the years - disagrees with you. The Raku community has come to the concensus that there is a distinction between Tutorials and Reference, and that the Documentation site should contain both. Tutorials define how to use some aspect of Raku, with example text and explanation. Reference tries to cover as much of the language as possible, covering all the methods/subs/names/types etc as possible. Reference is written for a person who already knows how to program and who uses Raku. The assumption is that if a person reading a reference does not understand some term, then s/he will search in the documentation on that term to understand it. No set of documentation standards will please everyone - that's life. Even so, there ARE STILL areas of the Raku documentation that are lacking (just look at the issues on the Documentation repository, any of them raised by our indefatigable JJ). Hi Richard, When deciding to write a technical article, the VERY FIRST thing you have to do is determine your TARGET AUDIENCE. In a single sentence, please state for me what you believe the TARGET AUDIENCE is for the documentation. Richard stated the target audience for reference documentation quite clearly: Someone who already knows how to program and uses Raku. Multiple people have told you many times over several years that the purpose of reference documentation is to provide a complete description of the elements of a language expressed in concise formal notation, and is not to be confused with tutorials. Your condescending tone indicates you haven't listened and are still trying to convince them that they are wrong. It isn't going to work.
Re: Is the cosine page wrong?
On 12/28/20 11:49 PM, ToddAndMargo via perl6-users wrote: I will accept your target audience: "Someone who already knows how to program and uses 'Raku.'" I will also accept that the documentation is not for me or anyone else trying to learn Raku. We explained that there are two types of documentation, and that is the target audience for *reference* documentation. The other type of documentation is tutorial, which *is* for people trying to learn Raku. This is different than any other programming language I have used, but it is what it is. Not my call. And by your description of the target audience, I am correct when I say the documentation is meant for those that already know what they are doing. "language expressed in concise formal notation, and is not to be confused with tutorials" Well now, they need to get on the same page as you: https://docs.raku.org/language/classtut "A tutorial about creating and using classes in Raku" It is clearly stated that it is a tutorial, although it is not. It is what you describe above. This is part of my frustration. That page is a tutorial, not reference documentation. It does not attempt to provide a concise and complete description of one feature of Raku in formal notation. It provides narrative and examples proceeding from simple to complex forms in pursuit of a goal of explaining the use of classes in Raku. That is a tutorial. Not all tutorials assume the same starting point for the reader, and tutorials on more advanced features of a language must assume the reader has familiarity with more basic prerequisites. For instance, a tutorial on lookahead assertions in Perl 5 regular expressions will assume that the reader knows what character classes and quantifiers are and will not explain them again. Therefore tutorials need to be consumed and understood in a certain order by the newcomer. Designing and presenting that order so that the reader does not get lost takes considerable skill. Generally, it requires a veteran teacher working closely with an editorial team that provides feedback from expert peers and novices alike in a lengthy evaluation phase. The highest quality tutorials will include exercises. Fortunately, all that work has already been done for Raku by just such a teacher and team. You can find the result at https://learning.oreilly.com/library/view/learning-perl-6/9781491977675/ This thread is titled after the cosine page, which is reference documentation. You keep wanting reference documentation to be changed to do the job of tutorial documentation. It would end up being bad at both. That's not going to happen.
Why does .new initialize?
I'm curious as to why Rat.new initializes instead of leaving as undefined: > $*RAKU Raku (6.d) > my Rat $p (Rat) > put $p Use of uninitialized value $p of type Rat in string context. Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful. in block at line 1 > my $q = Rat.new 0 > put $q 0 Peter Scott
Re: Why does .new initialize?
On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote: If .new wouldn't initialize a type to its basic instantiation, what would be the point of .new then? FWIW, the same goes for: dd Int.new; # 0 dd Num.new; # 0e0 dd Complex.new; # <0+0i> dd Str.new; # "" If you want to leave it undefined, don't call .new on it? *confused* Only that there's a vocal school of thought in O-O that says new() should only allocate memory and never put anything in there. Now I know that Raku doesn't subscribe to that I have no problem. Cheers, Peter
Re: Why does .new initialize?
Yes. I'm agnostic on this point, but there was a time when some prominent Perl contributors were dogmatic about it and I didn't know how widespread it was. Peter On 7/19/2021 10:06 AM, Vadim Belman wrote: Let me guess. The school prohibits object self-initialization? It has to be done by external code? Best regards, Vadim Belman On Jul 19, 2021, at 1:00 PM, Peter Scott <mailto:pe...@psdt.com>> wrote: On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote: If .new wouldn't initialize a type to its basic instantiation, what would be the point of .new then? FWIW, the same goes for: dd Int.new; # 0 dd Num.new; # 0e0 dd Complex.new; # <0+0i> dd Str.new; # "" If you want to leave it undefined, don't call .new on it? *confused* Only that there's a vocal school of thought in O-O that says new() should only allocate memory and never put anything in there. Now I know that Raku doesn't subscribe to that I have no problem. Cheers, Peter
Re: Barewords and subscripts
At 05:01 PM 1/26/02 +, Simon Cozens wrote:
>A4 said that there were no barewords in Perl 6. Does this mean that
> $foo{bar}
>actually should be written
> %foo{"bar"}
>?
No. That's not a bareword.
>I'm vaguely hoping that the answer is yes, because then we could treat
>*all* instances of {...} as a block returning either a closure, a value
>for subscripting, or an anonymous hash, rather than having to decide at
>tokeniser time.
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Barewords and subscripts
At 05:43 PM 1/26/02 +, Simon Cozens wrote:
>On Sat, Jan 26, 2002 at 09:28:18AM -0800, Peter Scott wrote:
> > >%foo{"bar"}
>
>It's bare, and it's a word.
Maybe you want to come up with another term to describe it then... but it
isn't a "bareword" in Perl. Camel III p.64 footnote: "... It's only a
bareword when the parser has no clue." p.65: "If you say C then any bareword will produce a compile-time error."
>I presume you're also happy with these ambiguities:
> $foo{shift} vs. $foo{"shift"}
I'm not arguing with the ambiguities you pointed out (which have vexed me
on occasion also); just that it ain't a bareword. "Unquoted identifier used
as hash subscript" is a bit of a mouthful, though.
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 =>?
--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com
Re: Barewords and subscripts
At 01:16 PM 1/26/02 -0700, Tom Christiansen wrote:
>There is another way to resolve the ambiguity of foo meaning either
>"foo" or foo() depending on current subroutine visibility. This
>would also extend then to issue of $hash{foo} meaning either
>$hash{foo()} or $hash{"foo"}. Just use parens.
I like this.
>In my experience, many programmers would prefer that all functions
>(perhaps restricted to only those of no arguments to appease
>hysterical cetaceans?) mandatorily take (even empty) parens.
Count me among the crazed whales/mad dolphins/whatever you were referring
to. It would make it easier to explain to beginners the rules for calling
functions by eliminating a qualification ("You can leave empty parens off
only if perl has already seen a definition or a declaration"), and it
wouldn't kill me to put empty parens on argumentless function calls.
> % perl -MO=Deparse,-p -e 'push @foo, fred +1, -2'
> push(@foo, ('fred' + 1), -2);
>
>Do you see what I'm talking about? The reader unfamiliar with the
>particular context coercion templates of the functions used in code
>like
>
> use SpangleFrob;
> frob @foo, spangle +1, -2;
>
>can have no earthly idea how that will even *parse*. This situation
>seems at best, unfortunate.
It seems less of a pain than the string/function ambiguity, though. I've
been frequently annoyed by having to quote, say -title:
start_html('-title' => "Vole Sanctuary")
in CGI.pm function calls when everything else is bare, and embarrassed at
explaining to readers why. On the other hand, if someone uses SpangleFrob
you'd think that they would have a clue how many arguments spangle and frob
expected, so they should have less reason to be confused. Usually the
worst trouble a programmer gets into by leaving too many parens off is:
print join "|", sort @foo, "\n";
On the other other hand, I seem to recall something about how Perl 6 should
be easier to parse, and this issue is the poster child for the "Only perl
can parse Perl" camp. Does the price of easier parseability have to be
"oatmeal mixed with fingernail clippings"?
--
Peter Scott
Pacific Systems Design Technologies
Re: rethinking printf
At 01:39 AM 3/11/02 +0100, Eugene van der Pijll wrote: >Why not replace the escape character '%' with '#'? No new quoting >operators or functions to learn. Beat me to it. >And introduce a warning if there are >no #'s in the format string. Maybe if it's a constant, but not if you're doing something like printf "#.3f " x @nums, @nums; and @nums is empty. You could always scan the format for a %-specifier which was valid under the old rules and warn that they seem to be using retro syntax. # bespeaks a number-type of thing... how about ~ ? -- Peter Scott Pacific Systems Design Technologies
Re: Ex4 smart match question
At 10:34 AM 4/7/02 +1000, Damian Conway wrote: > > It's very cool--but why is it $key =~ %hash but $value =~ @array rather > > than one way or the other? > >Because it's *both* ways. Perl 6's C<=~> operator is reversible. > >So you can write: > > $key =~ %hash > >or: > > %hash =~ $key > >and: > > $value =~ @array > >or: > > @array =~ $value > >depending on how the muse takes you. Why give up the chance to let things that look different behave differently? What do @left =~ @right %left =~ %right do? One can imagine useful default interpretations that are not commutative. -- Peter Scott Pacific Systems Design Technologies
Re: Loop controls
At 01:55 PM 4/29/02 -0500, Allison Randal wrote: >On Mon, Apr 29, 2002 at 10:10:01AM -0400, Aaron Sherman wrote: > > Again, it's just first derivative over time. You're not asking "is there > > a false value", you're asking "is the loop false". Just as we understand > > that an array in a conditional context is false if it is empty, so too > > is a loop false if it is "empty". This is a basic Perl concept, and it > > makes sense to promote it from static arrays to more dynamic loops. > >I agree again. > >There will have to be a section of the training material devoted to >"When is a loop false?" (I like that perspective, it nicely unifies the >cases), but it should be a short one. I would have said that the value of a loop was the value of the last expression evaluated in it (and undef or empty list for loops that didn't execute at all). Which means that some loops could execute and still be false. Is this hopelessly retrograde thinking? Are the hordes of programmers yet-to-be that will be weaned exclusively on Perl 6 look scornfully on me for such opinions and say, "There goes another Perl 5 programmer, pass the Geritol"? -- Peter Scott Pacific Systems Design Technologies
Re: Loop controls
At 04:15 PM 4/29/02 -0500, Allison Randal wrote: >On Mon, Apr 29, 2002 at 04:14:01PM -0400, Aaron Sherman wrote: > > > > Well then, I guess we should dump "elsif" from if too. After all, it > > could all be done with nested blocks of if/else > >But C is different. You use it all the time. The frequency with >which you'd need a loop that leads into another loop that leads into a >conditional isn't worthy of special keywords for each combination. It's >like coming up with a catchy word for "that place on the corner of the >sidewalk that dips down for wheel-chairs, bicycles and strollers (er, >prams)". It's not worth it. (Maybe there is such a word, but I don't >remember it because I don't use it.) It's a "curb cut". > > If we're to keep if the same, and add an else to loops, I think the > > syntax should be unified. > >There is a time for unification and a time for differentiation. Total >unification would take us back to assembly, "There can be only jumps." >Everything is a balance. So my question is, what do we lose from putting into the language something which will get very little use, except that a few people will no doubt enjoy it and insist they can't live without it? I'm starting to wonder whether some features should be optional... use extended qw(loop_syntax); -- Peter Scott Pacific Systems Design Technologies
