Re: -X's auto-(un)quoting?

Juerd wrote: Nathan Wiger skribis 2005-04-25 13:35 (-0700): My point is simply that we pick one or the other, instead of both/aliases/etc. But TIMTOWTDI. One way may be great for writing maintainable code, while the other is useful in oneliners (including single line method definitions). Then I

Re: -X's auto-(un)quoting?

Paul Seamons wrote: meth foo { $_.meth; # defaults to the invocant .meth; # operates on $_ which defaults to the invocant $^.meth; # is the invocant $^1.meth; # is the first invocant $^2.meth; # is the second invocant I'm starting to get confused at the "need" for all these sp

Re: -X's auto-(un)quoting?

Paul Seamons wrote: So then, to get back to the invocant... I can't say that I liked many of the proposals. The one that seemed to have merit though was $^. I'd propose the following. meth foo { $_.meth; # defaults to the invocant .meth; # operates on $_ which defaults to the invo

Re: Perl 6 modules plan

Michael G Schwern wrote: > > I think you misunderstand. This isn't named parameters vs prototyped > parameters vs args as list. The problem is the idea that functions > should accept *multiple styles by default* which the proposed > Module::Interface does. No, it doesn't. Unfortunately, I used

Re: Perl 6 modules plan

Kirrily Robert wrote: > > I also think there's too much overhead in learning (and remembering) > each library's quirks. My most common mistakes when using CPAN or core > modules occur when the modules have inconsistent interfaces and I forget > which ones take hashes and which take hashrefs, etc

ALLCAPS subs, properties, etc (Re: Multiple classifications)

* Damian Conway <[EMAIL PROTECTED]> [06/25/2001 13:20]: > > But one could also imagine that Perl 6 might allow individual objects to > have an C property that pre-empted their class's C<@ISA> array. At some point, it is probably worth talking about Perl's ALLCAPS subs for special methods. For ex

~ for concat / negation (Re: The Perl 6 Emulator)

* Simon Cozens <[EMAIL PROTECTED]> [06/14/2001 15:16]: > > OK, I've been teasing people about this for weeks, and it's time to stop. > This is the current state of the Perl 6 emulator; it applies most things > that Damian talked about in his keynote yesterday, and most of the things > I've picked

Re: properties

* Jonathan Scott Duff <[EMAIL PROTECTED]> [05/21/2001 09:39]: > > If anything, all variables should have a "value" property that evaluates > to its, well, value and only that property would be considered in > conditionals. Then these would be equivalent: > > print keys (+$foo).prop; >

Re: Separate "as" keyword? (Re: 'is' and action at a distance)

Dammit, I got the example exactly backwards. Try this: >$Foo is true; >$Foo = 0; >print "Stuff" if $Foo; # *WOULD* print - "is" assigns a > # permanent "true" property > >$Foo as true = ""; >$Foo = 0; >print "Stuff" if $Foo; # *

Separate "as" keyword? (Re: 'is' and action at a distance)

* Michael G Schwern <[EMAIL PROTECTED]> [05/18/2001 12:32]: > Let me see if I understand this... > > $Foo is true; > > # Meanwhile, in another part of the city... > > $Foo = 0; > print "My spider sense is tingling" if $Foo; > > Does that print or not? Maybe there are two different fea

Re: apology (was Re: Exegesis2 and the "is" keyword)

* Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 11:25]: > > I recently received the following email from someone whose name I > have snipped. > > > * Dave Storrs <[EMAIL PROTECTED]> [05/16/2001 08:11]: > > > > > > Ok, this is basically a bunch of "me too!"s. > > > > Keep the snide comments

Re: Exegesis2 and the "is" keyword

* Michael G Schwern <[EMAIL PROTECTED]> [05/15/2001 17:49]: > > Is that autochomp as a keyword or autochomp as an indirect method call > on $*ARGS? Who cares? ;-) > > The thing I worry about is this: I don't think actions should be > > declared using "is", necessarily. > > > >$STDERR is fl

Exegesis2 and the "is" keyword

So, I finally got around to reading the link Nat sent out: http://www.perl.com/pub/2001/05/08/exegesis2.html First off, nice job Damian (as always), it looks excellent. I like the examples of stuff like this: my int ($pre, $in, $post) is constant = (0..2); Awesome. Simple, Perlish, easy

Re: p6 casting as shortcut for lengthier p5 syntax

* Damian Conway <[EMAIL PROTECTED]> [05/11/2001 14:46]: > > Here's a translation table from my soon-to-be-released article, Exegesis 2: > > Access through... Perl 5 Perl 6 > = == == > Array slice @foo[$n]

Perl5 Compatibility, take 2 (Re: Perl, the new generation)

* Dan Sugalski <[EMAIL PROTECTED]> [05/11/2001 07:19]: > > > > > > I think you're in violent agreement here. This has been declared a > > > goal of Perl 6 from almost day one. > > > >Ok, fair enough, but until just a little bit ago I was hearing stuff different > >from Dan. That has been changed,

Re: perl5 to perl6

* Nathan Torkington <[EMAIL PROTECTED]> [05/10/2001 17:31]: > > Here's the corresponding perl6 program: > > #!/usr/bin/perl -w > > while (<$ARGS>) { ^ Whoa! Is RFC 94 being considered?! I thought I retracted that. ;-) > Notice the variable changes: %count{...} because I'm

Re: You will not have to rewrite your Perl 5 programs!

* Adam Turoff <[EMAIL PROTECTED]> [05/10/2001 15:20]: > > Yes, it has, in Apocolypse 1: > > Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. > > http://www.perl.com/pub/2001/04/02/wall.html Yup, I saw that - actually, the discussion I was referencing was post-A

Re: You will not have to rewrite your Perl 5 programs!

* Dan Sugalski <[EMAIL PROTECTED]> [05/10/2001 14:18]: > > > >Perl 6 *will* provide a backwards compatible Perl 5 parser. The > >details are not nailed down, but this definately will happen. > > Damn straight. One way or another, perl 6 will eat perl 5 code close to > painlessly. (Typeglobs, pe

Re: Perl, the new generation

* Larry Wall <[EMAIL PROTECTED]> [05/10/2001 11:57]: > > Nathan Wiger writes: > : Maybe the name "Perl" should be dropped altogether? > > No. The Schemers had to do a name change because the Lisp name had > pretty much already been ruined by divergence. &g

Re: Perl, the new generation

* Peter Scott <[EMAIL PROTECTED]> [05/10/2001 10:55]: > > 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

Re: Apoc2 - Context and variables

* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 10:11]: > > Nathan Wiger writes: > : First off, before I forget to mention it, nice job on Apoc2 Larry! You are > : the man. I know alot of us on p6l can seem like harsh critics at times, but > : it's only because we love Pe

Re: Apoc2 - concerns

* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 09:36]: > > Taking history into account is good, though I'd argue that now is the > proper time to change history, if we're going to change. Perl would > never have been accepted in the first place had it been too different > from what came before, but

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/07/2001 13:46]: > > > To quote you: > > : http://dev.perl.org/rfc/28.pod > > > > I'm not trying to be a jerk at all, but I think at times we're losing > > sight of the above. > > I hope not, since it was primarily written with you in mind. :) Hmm, that's o

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/07/2001 13:33]: > > > I'm not against a "cleaner" way to do qw() in principle, but I > > definitely think <> is not it for a lot of reasons (glob, readline, > > can't use =>, iterators, ...) > > Sheesh. Yes, those would be problems with using <> in Perl 5. >

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/07/2001 13:17]: > > Bother. Well, you'd have to quote it, but then you wouldn't really have > a hash key called => that often, either. Yeah, but you couldn't make use of a way to assign alternate values without some specialized syntax. I don't think this:

Re: Apoc2 - concerns

* Simon Cozens <[EMAIL PROTECTED]> [05/05/2001 17:51]: > > %foo = ( foo => 1, bar => 1, '=>' => 'baz' ) > > Of course, that could be spelt > > %foo = <+foo +bar =>("baz")>; Actually, it couldn't be because the > in => would end the parsing. Same problem that the POD <> chars have. I think Ur

Re: Apoc2 - concerns

Ok, this is long, so here goes... > I expect the real choice is between <$FOO and <$FOO>. I can convince > myself pretty easily that a unary < is just another name for "next", or > "more", or something. On the other hand <$FOO> has history. And if > one special-cases <$...>, we could also have

Re: Traffic lights and language design

[again, apologies if this is a duplicate] * Michael G Schwern <[EMAIL PROTECTED]> [05/04/2001 15:51]: > > Oddly enough, varying the number of traffic lights can effect > efficiency. By over-regulating you can choke off traffic. Constant > fiddling with the setups and timings, trying to control

Re: Apoc2 - concerns

> >:$FH = open "<$file" or die "Can't open $file: $!"; > >:$line = next $FH; > >: > >: If so, I can live with that. > > > >Yes, that's the reason it's C, and not something more specific > >like C, which isn't even true in Perl 5 when $/ is mungled. > > I dunno. Color me unconvinced--I do u

Re: Apoc2 - Context and variables

> Horrors is right. The default perl5 behaviour is *useful*. I use the %b=(%a,%c) > metaphor all of the time. > > Why not just keep it simple? And perl5-ish. Two contexts, scalar and list, > hashes NOT a context of its own. I agree. But what to do with: (%a, %b) = (%c, %d); Surely that shoul

Re: Apoc2 - concerns

> We do have to worry about the C loop control function though. > It's possible that in > > FOO: while (1) { > next FOO if /foo/; > ... > } > > the C label is actually being recognized as a pseudo-package > name! The loop could well be an object whose full name is C. > Or something like t

Re: Apoc2 - Context and variables

>>$a = @b; >> >>2. Pull a reference to @b (like Perl5's "$a = \@b") > > Yep. Scalar context eval of arrays, hashes, and subs produces a reference. Perfect. >> Similarly, how about: >> >>%c = @d; >> >> Does this: >> >>1. Create a hash w/ alt

Apoc2 - Context and variables

First off, before I forget to mention it, nice job on Apoc2 Larry! You are the man. I know alot of us on p6l can seem like harsh critics at times, but it's only because we love Perl so much. ;-) Anyways, in addition to the $file.next stuff, I'm curious about a few clarifications on the new semant

Re: Apoc2 - concerns

> While perhaps inconsistent, I'd really rather it did #2. Here's the > basic argument... compare how often you dup a filehandle with how > often you read from one. Duping is swamped by several orders of > magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line = > $STDIN.next should still

Re: Apoc2 - concerns

> : This one. I see a filehandle in *boolean* context meaning "read to $_", > : just like the current "while ()" magic we all know and occasionally > : love. I'd expect $FOO.readln (or something less Pascalish) to do an > : explicit readline to a variable other than $_ > > It would be $FOO.next, b

Apoc2 - concerns

[apologies if this is a duplicate, but my mail's been dropping] There's a lot of good stuff in Apoc2, but I did have at least one semantic concern. In it, there's this proposal: : There is likely to be no need for an explicit input operator in Perl 6, : and I want the angles for something else.

Apoc2 - concerns

There's a lot of good stuff in Apoc2, but I did have at least one semantic concern. In it, there's this proposal: : There is likely to be no need for an explicit input operator in Perl 6, : and I want the angles for something else. I/O handles are a subclass of : iterators, and I think general it

Re: Traffic lights and language design

* Michael G Schwern <[EMAIL PROTECTED]> [05/04/2001 15:51]: > > Oddly enough, varying the number of traffic lights can effect > efficiency. By over-regulating you can choke off traffic. Constant > fiddling with the setups and timings, trying to control each and every > intersection to maximize t

Re: a modest proposal Re: s/./~/g

Graham Barr wrote: > You don't get it. > > We are not looking for a single char to replace -> > > We WANT to use . With complete respect here, I'm still not convinced this is true. Specifically, what the value of "we" is. It hardly sounds like everyone's united on this point. In fact, I've coun

Curious: -> vs .

I'm just gonna post this, then back off and listen (been yapping too much...) The previous discussions about string concat and how to replace . have revealed that people are somewhat divided over whether replacing -> with . is actually good thing or not. I'm just curious what the arguments for a

Regexp::Func (Re: YA string concat proposal)

"Stephen P. Potter" wrote: > > Oh, and since it hasn't been mentioned for awhile, I'd still prefer if =~ > and !~ went away and were replaced by match(string, [pattern], options), > replace(string, [pattern], options) and trans(string, ["pattern"], options) > or some such. This is one place wher

Re: Sane "+" string concat proposal

"Stephen P. Potter" wrote: > > You still haven't given a good explanation of > > $a += sub(); # is it a string or a number? > > Does your plan mean that we can no longer have subs that are context > dependent? No, Schwern asked me this same thing off list, here's what I said: One possibi

Re: YA string concat proposal

Uri Guttman wrote: > > on the other hand, i use .= all the time and wouldn't like to lose > it. schwern idea of ce doesn't work for me as only the op= stuff means > assignment and ce would break that (e for = isn't visual enough). I was just thinking, too bad that Larry's claiming the colon curr

Re: Sane "+" string concat proposal

Michael G Schwern wrote: > > Oh, not to seed the clouds or anything, but what about "+=" and ".="? > Any proposal will have to deal with those. Under what I originally posted: $a += "$b";# string $a += $b; # numeric Seems easy enough... -Nate

Re: YA string concat proposal

Michael G Schwern wrote: > > cc and ce > > Perl 5 Perl 6 > print "foo" . "bar";print "foo" cc "bar; > print 2 . 4;print 2 cc 4; > print "foo " . ($i + 1);print "foo " cc ($i + 1); > $foo .= "

Re: Strings vs Numbers (Re: Tying & Overloading)

Michael G Schwern wrote: > > On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote: > > ok, well.. I've heard arguments for '+' (namely that its intuitive, other > > language compatible, etc...) so what are the arguments against it? > > This one seems to have slipped by... > http://arch

Re: Sane "+" string concat proposal

"Stephen P. Potter" wrote: > > | In Perl 6, you would do this like so: > | > |$string3 = "$string1" + "$string2"; > > Once you go this route, you've pretty much destroyed the usefulness of > having a concat operator. It is far less typing to do > >$string3 = "$string1$string2"; Ag

Sane "+" string concat proposal

THESE ARE NOT THE SAME TIRED ARGUMENTS! If you're on p5p, you're probably already rolling your eyes. However, I searched p5p all the way back to 1997 and could not find this proposal anywhere. Even though it looks similar to the standard "Java + concat overload" stuff, it is not, so please try to

Re: Strings vs Numbers (Re: Tying & Overloading)

John Porter wrote: > > > One of the reasons I program in Perl as my > > primary language is *because of* the syntax. > > With all due respect, I don't believe that's why you, > or anyone else, likes to program in Perl. I *really* don't want this to turn into a religious argument, which it's fas

Strings vs Numbers (Re: Tying & Overloading)

Larry Wall wrote: > > The . is just syntax. Do you mean something semantic by ".-based"? No, but I think "just syntax" is a little misleading. I do agree that we "well, Perl 5 did it this way" is not a sufficient design decision at this point. However, if you changed Perl's syntax too radically

Re: Tying & Overloading

Larry Wall wrote: > > : I _really_ think dot-syntax would make perl prettier as well as make it > : more acceptable to the world of javacsharpbasic droids. Which is some > : kind of goal, no? > > Consider it a given that we'll be using . for dereferencing. (Possibly > with -> as a synonym, just

Re: Tying & Overloading

Jarkko Hietaniemi wrote: > > > // numeric comparisons > > int (*NUMCMP) (SVAL *this, SVAL *value); > > int (*NUMEQ) (SVAL *this, SVAL *value); > > int (*NUMNE) (SVAL *this, SVAL *value); > > int (*NUMLT) (SVAL *this, SVAL *value); > >

Re: Parsing perl 5 with perl 6 (was Re: Larry's Apocalypse 1)

Dan Sugalski wrote: > > 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 an

Perl 5 compatibility (Re: Larry's Apocalypse 1)

Ted Ashton wrote: > > Thus it was written in the epistle of Michael G Schwern, > > I think [Nate]'s saying that its annoying to have to write any tag > > that says "Hey, I'm starting a new Perl 6 program here!" at the top of > > every single program, much in the same way its tiresome to write "in

Re: Larry's Apocalypse 1

Nathan Torkington wrote: > > *tap* *tap* is this thing on? (lame attempt at a "feedback" joke - ha ha) Like others, I'm amazed. It looks like Perl 6 is going to be incredibly coherent, despite the RFC frenzy. For now I have mainly compliments, and a few thoughts: 1. Breaking @foo vs. $foo

Re: Turn 'em on! (was Re: Warnings, strict, and CPAN)

[EMAIL PROTECTED] wrote: > > > Command-line flags on by default [-T -Mstrict -Mwarnings]: > > We already beat this to death with the .perlrc discussion. You'll > break reams of Perl code you probably don't even know you have this > way. > > It destroys the portability of Perl programs. Yup,

Re: Turn 'em on! (was Re: Warnings, strict, and CPAN)

[EMAIL PROTECTED] wrote: > > But we can run an experiment. Warnings can be made default for the > first few releases of Perl 6 and we'll see what happens. If it looks > good, leave them on. If not, shut them off. Unlike most other > features, this one doesn't have any serious backwards compati

The binding of "my" (Re: Closures and default lexical-scope for subs)

Branden wrote: > > As to the second item b), I would say I withdraw my complaints about `my' if > my other proposal of `use scope' gets approved (since then I don't need `my' > anymore!). I guess I would be happier with `use scope', and I also think it > would make you happier, since it wouldn't

Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[resent to perl6-language, sorry for any duplicates] Edward Peschko wrote: > > > I personally think that this is something Larry is going to have to > > decide. However, I would like to note that leaving these off by default > > lowers the transition curve to Perl 6 immensely for those people th

Re: Closures and default lexical-scope for subs

Peter Scott wrote: > > >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 i

Re: Closures and default lexical-scope for subs

Peter Scott wrote: > > At 01:15 PM 2/15/01 -0500, John Porter wrote: > > > my $a, $b, $c;# only $a is lexically scoped > > 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 > tak

Re: Really auto autoloaded modules

Dan Sugalski wrote: > > >Regarding #1, if there's no need to make it extensible by users, why > >have a file at all? This shouldn't change after Perl is built, right? > >And all of the stuff that's going to be "autoloaded" in this way will be > >included in the core dist, right? Sounds like some

Re: Really auto autoloaded modules

Dan Sugalski wrote: > > > > The parser needs to have it in a standard system-wide place. > > > >Hmmm. I see what you mean, but why couldn't it be in @INC, first one > >wins? The file could be named AutoUse.pm or something. > > That strikes me as very much too high level a thing. I'm figuring the

New export mechanism (Re: Really auto autoloaded modules)

Damian Conway wrote: > > I like that, though I'd go with different key names ("always" isn't > always, and "tags" is not well related to its effect). How about: > >use export implicit => [qw(you get this)], >explicit => [qw(only by request)], > comp

Re: Really auto autoloaded modules

Damian Conway wrote: > > >> Where should this info be maintained? In a module in @INC (sort of like >> CPAN/MyConfig.pm)? Or in a special file that's only written to via a >> module install? Or in a block atop each module that's yanked out via >> MakeMaker? Or??? > > The parser

Re: Really auto autoloaded modules

Damian Conway wrote: > > > >However, it also seems that this is getting *really* complicated > > >really quickly. > > > > I'd agree. I was picturing the file the parser used reading > > something like: > > > >socket|Socket|1.0|gt > > I think this is the way to go. I'd suggest that the

Re: Really auto autoloaded modules

Dave Rolsky wrote: > > That's what I was thinking. The point is that the module identifies the > services it provides. Multiple modules may provide overlapping sets of > services. Modules could also be somehow ranked (memory usage and speed > come to mind). > > Then I could put this into my m

Re: Really auto autoloaded modules

Ted Ashton wrote: > > It appears to me that there's a focus problem here. After all, > if I want to use CGI or CGI::Minimal, I can already do that. > The auto-autoloading, unless I am sorely mistaken (which is > quite possible :-), is for the purpose of moving things out > of the core and yet a

Re: Really auto autoloaded modules

Dan Sugalski wrote: > > At 12:33 PM 2/1/2001 -0500, Michael G Schwern wrote: > > > >Have a look at AnyLoader in CPAN. > > Looks pretty close to what's needed. Care to flesh it out (and streamline > it where needed) to a PDD? There's also autouse, a pragma that ships with Perl. Again, not exactl

Re: Why shouldn't sleep(0.5) DWIM?

"Stephen P. Potter" wrote: > > Why do we have to worry about changing time()? There's a real parallel > between sleep() and alarm(), so we would want to do both if we did either, > but time() really has no relation to them. > > Or, should we just implement usleep() and (for lack of a better nam

UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)

Jarkko Hietaniemi wrote: > > As I said the problem isn't the p52p6 doing that kind of transformation. > The problem is someone familiar with perl5 writing code in perl6: > > if (my $fh = open(">/tmp/$$".time())) { > > and later something crashing and burning because some other place exp

Re: This is PDD #1--a high-level overview of the perl system

First off, this looks really cool to me, nice job. The only thing I'm a little surprised by is this: > =head2 Independent subsystems > > Perl also has a number of subsystems that are independent of any > single module. > > =item PerlIO subsystem > > =item Regex engine I would have actually ex

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

>The crux of the problem is that non-greedy qualifiers don't affect the >"earliest match" behavior, which makes the matches more greedy than they >really ought to be. > >Here is a simple example: (tested with perl 5.005_03) > > $_ = ""; > ($greedy) = /(b.*d)/;

Re: OO AV/HV's and tie (was Re: Meta-design)

Simon Cozens wrote: > > Oh boy, it's OO syntax nargery time again. *sigh*. > > I think it would be cool > > Good for you. This is internals design; perl6-language is over there ---> > and the "ph33r mY |<" phase is supposed to be over now > anyway. Cool! Thanks alot for the useful feedback. Co

Re: Tech documentation (Re: Perl Apprenticeship Program)

Kirrily Skud Robert wrote: > > Open Source Writers Group (http://oswg.org/) is a good starting point. > I'm subscribed to their mailing list. This is really cool. Should we consider posting an announcement to this website for potential docs people? Or is it still premature to do something like

OO AV/HV's and tie (was Re: Meta-design)

Simon Cozens wrote: > > =head2 Implementation Language > > C++ gives us OO and headaches, is wildly non-portable due to a lack of > decent implementations, and we don't have enough experience of it. C's > portable and everyone knows it, but it's a swine for doing OO things. Don't forget we can

Tech documentation (Re: Perl Apprenticeship Program)

Steve Fink wrote: > > David Grove wrote: > > > Also, as far as documentation goes, I think it _should_ be written by > > apprentices, so that non-masters can understand it too. > > Except it's a particular duty that nobody really likes to perform. One thing that might be really cool is if ther

Re: how the FreeBSD project gets its "core members"

Adam Turoff wrote: > > No worries. These BSD guys are onto something... > http://www.daemonnews.org/200010/dadvocate.html Thanks for the great link. This is a really interesting article. In particular, I found these points about FreeBSD to be reminiscient of concerns some have raised about

Re: Now and then

Nathan Torkington wrote: > The immediate question facing us is how to structure software design. > This is different from the ongoing maintenance of Perl. > The architecture will be partially decided by Larry, and seems best > done by a few experienced with such things. Detailed design seems >

Re: Continued RFC process

Dan Sugalski wrote: > > Works. We still have those Quantum Ninja that we're holding in reserve for > Damian... :) Yeah... they're vicious, too - they kick ass in constant time. ;-) -Nate

Re: Continued RFC process

Dan Sugalski wrote: > > > > Just that it not be *too* hard to get on the closed lists > > > >Yep, this is my only concern. It should be reasonably easy to say "I > >really want to help" and get on the closed lists. Perhaps the best way > >of making sure the lists don't bloat into "everyone has a

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

John Porter wrote: > > RFCs like "330: Global dynamic variables should remain the > default" should not need to be written! (No disrespect to you, > Nate.) None taken; I actually agree. Unfortunately, I thought that -strict did nowhere near enough analysis of scoping issues besides the initial s

Re: RFC 357 (v2) Perl should use XML for documentation insteadof POD

> Retracting would have been easier, but could very well be seen as giving up > on pointing out PODs deficiencies. Pointing POD deficiencies is fine. But the fundamental thrust of the RFC is still "replace POD with XML". That's why I even noted the alternative names and corresponding emphasis in

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

> I may be raining on your RFC 337 parade here (sorry I didn't get to it > earlier - travel), but I think it entirely reasonable to want to specify a > type for an array different from the type of thing it contains. But what > syntax will you use? If I make one up for the sake of illustration: >

Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

> >However, making it a UNIVERSAL method also dictates that this: > > > >my SomeType @a :someattr; > > > >*must* be either: > > > >1. a builtin type > >2. tied > > > >To get its attributes back out. I'm not sure this is going to always be > >true. > > It must be my sinuses. I don't g

Re: RFC 324 (v2) Extend AUTOLOAD functionality to AUTOGLOB

> =head1 CHANGES > > Comments received have been that it would be better to use AUTOSCALAR, > AUTOHASH etc instead of AUTOGLOB in the interests of encapsulation. > The argument being that if you only want to implement AUTO scalars in > your program, then doing: > > C # do some stuff > }

Re: RFC 290 (v3) Better english names for -X

Bart Lateur wrote: > > On 1 Oct 2000 06:48:11 -, Perl6 RFC Librarian wrote: > > >-r freadable() > >-R Freadable() > > This still doesn't sound like an improvement. I can remember that -r > stands for readable, but the difference between -r and -R is very > obscure. How to remember

Re: RFC 333 (v1) Add C and C funtions to coredistribution

Alan Gutierrez wrote: > > This just in from RFC 2068 HTTP/1.1 - 4.2 Message Headers: > > The field value may be preceded by any amount of LWS, though a single SP > is preferred. Header fields can be extended over multiple lines by > preceding each extra line with at least one SP or HT. Yes, sim

Re: RFC 319 (v1) Transparently integrate C

Alan Gutierrez wrote: > > The suggested C< use optimize > pragma is starting to grow many heads. > C< use less > was such a simple little pragma, a general direction for > the interpreter to take. Here it seems that the optimizations apply to > the C< package int; > only. Are we suggesting that o

Re: RFC 352 (v1) Merge Perl and C#, but have default Main class for scripting.

Simon Cozens wrote: > > On Fri, Sep 29, 2000 at 09:47:51PM -, Perl6 RFC Librarian wrote: > > I am a fan of Perl and like what I see of the core C# _language_. > > What I propose is to move Perl in the C# direction. > > So, this is the comedy RFC, eh? Indeed. Since you quoted a couple of m

Re: RFC 339 (v1) caller->eval BLOCK

> > caller->eval EXPRESSION; > > That's mad, bad, scary and dangerous. Let's do it. Yes, this is cool. In fact, I'm writing Regexp::Func right now as a prototype for RFC 164 and discovering I could really use this - in fact, need it. A couple things: 1. Implement this eval as UNIVERSA

Re: RFC 350 (v1) Advanced I/O (AIO)

> you would do: > > $sock = AIO::Open( Host => 'www.perl.org', >Port => 80 ) ; > Similarly for LWP you would just do: > > $sock = AIO::Open( Url => 'http://www.perl.org' ) ; > $event = AIO::Open( Host => 'www.perl.org', >

Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

> =head1 ABSTRACT > > Remove all interpolation within single quotes and the C operator, to > make single quotes 100% shell-like. C<\> rather than C<\\> gives a single > backslash; use double quotes or C if you need a single quote in your > string. Yes. If people really need single quotes inside

Re: RFC 324 (v1) Extend AUTOLOAD functionality to AUTOGLOB

David Cantrell wrote: > > You can do it by explicitly calling your parent's AUTOGLOB as well if you're > asked to deal with something you don't support yourself (see below). Also, > having it as a single sub would be more easily extensible if we ever have > more datatypes (I think!) and results

Why -> cannot autoquote the LHS (was Re: RFC 244 (v1) Method calls should not suffer...)

> =head1 TITLE > > Method calls should not suffer from the action on a distance > Currently, > > foo->bar($baz) > > can be parsed either as C<<'foo'->bar($baz)>>, or as C> > depending on how the symbol C was used on other places. The proposal > is to always choose the first meani

Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes

> > =head1 TITLE > > > > Common attribute system to allow user-defined, extensible attributes > > Err... have you read perldoc attributes? There's already a mechanism > for doing this (see my japh), though it is a complete PITA to use and > I'd like to see it tidied up (and possibly have attribut

Re: RFC 330 (v1) Global dynamic variables should remain the default

Piers Cawley wrote: > > Nathan Wiger <[EMAIL PROTECTED]> writes: > > > Another proposal suggests that users should be forced to declare all > > variables with C explicitly. Blech. That doesn't make anything > > easy. Perl is not a B&D language. > &g

Re: RFC 333 (v1) Add C and C funtions to coredistribution

> Hm. This makes it difficult to construct a header incrementally -- for > example, @HEADERS=(); push @HEADERS, header(content_type=>'a', > author=>'b'); # 75 lines later; push @HEADERS, header(last_modified=>'c', > accept=>'d'); > > Since in this case, there would be two "blank" head lines inste

Re: RFC 288 (v2) First-Class CGI Support

Alan Gutierrez wrote: > > This header functionality is application specific and does not belong in > the core any more than the socket stuff which seems to be on its way > out. I don't see why this has be implemented in the core in C. > > Once again, if core means core modules, and as a part of

Re: RFC 331 (v1) Consolidate the $1 and C<\1> notations

> =item * > C<\1> goes away as a special form > > =item * > $1 means what C<\1> currently means (first match in this regex) > > =item * > ${1} is the same as $1 (first match in this regex) > > =item * > ${P1} means what $1 currently means (first match in last regex) Here's the big problem with

  1   2   3   4   5   >