Re: formats and localtime

Nathan Torkington writes: : Damian Conway writes: : > My (limited) understanding of the aims of Perl 6 were to start again with a : > clean slate and fix the things that are broken, or that could be designed : > better with hindsight. Backwards compatibily was to be fed to the lions. : : Larry's

Re: formats and localtime

Chaim Frenkel writes: : > "DC" == Damian Conway <[EMAIL PROTECTED]> writes: : : DC> Only if you simultaneously remove Perl 5! : : DC> My (limited) understanding of the aims of Perl 6 were to start again with a : DC> clean slate and fix the things that are broken, or that could be designed :

Re: RFC: Reimplement Warnings and Tainting as Pragmas

Nathan Wiger writes: : Is there any interest to do this in the community with tainting? Adding : a 'use tainting' to Perl 6 (or 5.7, for that matter)? Unfortunately, tainting is a data-flow/data-typing concept, and when you try to implement data-flow/data-typing concepts with lexical scopes, you

Re: RFC: Filehandle type-defining punctuation

Peter Scott writes: : If the prefix-less form of filehandles was absent from Perl 6, I would be : far less enthusiastic about my RFC. I agree; they're a kind of scalar. In fact, they're a kind of object. : (Just occurred to me that one could view the % prefix of hashes as denoting : a key-val

Re: RFC: Filehandle type-defining punctuation

Peter Scott writes: : At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote: : >ref() has always been a de facto typeof operator, no? : > : > open my $fh, "< /etc/motd"; : > print ref $fh : >GLOB : : Can we make that IO in P6...? Maybe, but it might be some class derived from an IO object, de

Re: RFC: Higher resolution time values

Graham Barr writes: : On Wed, Aug 02, 2000 at 11:50:10AM -0400, Sam Tregar wrote: : > On 2 Aug 2000, Gisle Aas wrote: : > : > > =head1 PERL5 PORTABILITY : > > : > > Calls to time() could be transformed to int(time()) when converting : > > perl5 programs to perl6. : > : > Unless there's a: : >

Re: RFC: Request For New Pragma: Implicit

Chaim Frenkel writes: : No. This sort of argument is not terrilby useful. Really, I don't see any big problem with the notion of the values of void expressions being sent somewhere, as long as it's lexically scoped, and doesn't rely on a global default filehandle. This kind of default output ha

Re: RFC: Filehandle type-defining punctuation

Tom Christiansen writes: : >Not sure I agree with that. I think one point of confusion / perceived : >difference between filehandles, open(), and basically every other : >builtin is that all the others *return* what you want. : : Think of all the {file,dir}handle syscalls. They don't do that.

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

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

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

John Porter writes: : Michael Mathews wrote: : > how shall I, as an RFC > Maintainer determine what that status is? : > : > Personally I don't want anything to do with judging the "status" of this : > RFC, beyond my one voice. I do accept responsibility for compiling some : > organized record of

Re: RFC for recursive regexps

[EMAIL PROTECTED] writes: :> In perl5, :> :> /(??{ $FOO })/ :> :> delays the interpolation of $FOO, so as to be able to have :> recursively defined regexps. : : Of course, that example might in itself be sufficient reason : to completely redesign the regex syntax! On

Re: Things to remove

Jonathan Scott Duff writes: : Here in my pre-caffiene morning trance it occurs to me that a few of : the "fringe" features of perl should be removed from the langauge. : Here's a few things that I would venture to say that none of the : "perl5 is my first perl" people have probably ever actually u

Re: perl 6 requirements

Johan Vromans writes: : On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote: : > So Larry is doing most of the evaluation for us. He's the one who : > gave us the good things in the Perl language we have now. He'll be : > the one vetoing the ridiculous ideas. : : Larry said: "Perl

Re: what will be in Perl6 ?

raptor writes: : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html That's a good summary of what we've been thinking. Here's another article that talks about a lot of the things we *should* be thinking. In fact, it's possible this article should be required reading for anyone who

development relationship of Perl 5 and Perl 6

Johan Vromans writes: : Nick Ing-Simmons <[EMAIL PROTECTED]> writes: : : > perl.exe + perl.dll or .../bin/perl + libperl.so : : RFC: Should the perl program be called differently (e.g., perl6) to : allow sites to run 5 and 6 in parallel until their migration is : completed (if ever)? We will

Re: what will be in Perl6 ?

Jonathan Scott Duff writes: : On Wed, Aug 02, 2000 at 10:57:27AM -0700, Larry Wall wrote: : > raptor writes: : > : http://www.oreillynet.com/pub/a/linux/rt/07282000/transcript.html : > : > That's a good summary of what we've been thinking. Here's another : > art

Re: RFC 58 (v1) C changes.

Ted Ashton writes: : Thus it was written in the epistle of Segher Boessenkool, : > : > The magic defined($_ = ) only happens if is the only thing : > inside while(). : > : > In this case, it's not (there's a chomp() inside as well), so the magic : > doesn't apply. : : Ok. One more time . . .

Re: RFC 58 (v1) C changes.

Larry Wall writes: : (Note that under Unicode, we might well have one line terminated with a : line separator, and the next line terminated with a page separator, and Make that paragraph separator. Larry

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

Bart Lateur writes: : On Wed, 9 Aug 2000 08:59:41 +0100, Leon Brocard wrote: : : >D'oh! ;-) : : Ah, yes. Chris Nandor's module D'oh couldn't possibly be called with : this appropriate name any more. : : : : : OTOH, try this: :

Re: Things to remove

[EMAIL PROTECTED] writes: :> Most of the requests for deletion seem to begin with, "This isn't :> used..." :> :> To which, "*I* use it." is a very valid argument. : : Agreed. The real problem with ?...? is that it complicates the hell out : of the parser. So long as the special

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

[EMAIL PROTECTED] writes: : Note that it may not be possible to satisfy conflicting requests. If : module C and module C demand two different versions of the same : module C, the compiler should halt and state the module conflicts. Pardon me for sniping at a great RFC, but I already promised the

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

Dan Sugalski writes: : Does that mean, then, that when module A does a "$C::bar = 1" it affects a : different package namespace than module B doing a "$C::bar = 2"? Presumably. : And does it also extend to things like this: : : package A; : use C 1.2; : package B; : use C 1.4;

Re: RFC 79 (v1) Code which is both executable and POD.

John Porter writes: : Michael Mathews wrote: : > : > This ... underlines why POD is not a good way to comment code. : > ... : > This RFC would seem to address the issue quite neatly. : : So, are you saying that if this RFC is implemented, POD would be : an good way to comment code? It already i

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

Dan Sugalski writes: : At 11:11 AM 8/9/00 -0700, Larry Wall wrote: : >Dan Sugalski writes: : >: Does that mean, then, that when module A does a "$C::bar = 1" it affects a : >: different package namespace than module B doing a "$C::bar = 2"? : > : >Presumab

Re: RFC 8 (v2) The AUTOLOAD subroutine should be able t

[EMAIL PROTECTED] writes: : =head1 IMPLEMENTATION : : This strikes me as being a fairly easy thing to do, but then again : internals ain't my thing, baby. The problem I see here isn't the internals--it's how do you translate Perl 5 to Perl 6? Larry

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[EMAIL PROTECTED] writes: : p52p6 would handle it (by translating all Perl 5 C"y">'s to Perl 6 : C<'x',"y">'s. : : I *must* put this in the RFC! I think most of the RFCs could use a MIGRATION POLICY section, or some such. Larry

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

[EMAIL PROTECTED] writes: : It is proposed that a new syntax for declaring constants be introduced: : : my constant $PI = 3.1415926; : my constant @FIB = (1,1,2,3,5,8,13,21); : my constant %ENG_ERRORS = (E_UNDEF=>'undefined', E_FAILED=>'failed'); Can't put a modifier like "constant" in the

Re: Portable upper/lower case regexp matchesre and procedures

Dave Storrs writes: : Here's my question of procedure: plenty of times on these lists, : I see something that I think is a really good idea. I don't want to waste : bandwidth by posting just a "me too!", but I also don't want the idea to : die because no one weighed in in support of it. I

Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)

Dan Sugalski writes: : Yup. It's an issue for things that implement any non-standard semantics for : existing ops, especially if those ops are overridden at runtime so the : optimizer doesn't know. It's one thing to mess with tied variables, its : another entirely to make + behave differently.

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

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

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[EMAIL PROTECTED] writes: : Yep. Or more generally "Standardize Perl on all platforms to one : common time epoch" and reccommend the Unix epoch since it's so : widespread. :-) Oh, gee, where's your sense of history? (As in creating our own. :-) Maybe we should invent our own epoch, like the ye

Re: RFC 126 (v1) Ensuring Perl's object-oriented future

[EMAIL PROTECTED] writes: : To put it another way, no one should ever be tempted to do this: : : $obj->{'attribute'} : : for efficiency reasons inside a tight loop or what have you. (And no, : the solution is not to "use C when you need efficiency." I shouldn't : need to use portable assem

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

Nathan Torkington writes: : Steve Fink writes: : > We are NOT here to construct a radically better language. We are here to : > design the underpinnings of one. : : Perhaps. And by "perhaps", I mean "no". : : We're here to say what we'd like to see in the next version of Perl. : These can be bi

Re: Ideas that need RFCs?

[EMAIL PROTECTED] writes: : Bare C and bare C *are* the main culprits. They require : the tokenizer to track expression semantics so that when it encounters a : '/' or '?' it can tell whether a pattern is plausible in this place or : whether they've reached a division or hook operator, respectivel

Re: RFC 23 (v3) Higher order functions

Nathan Torkington writes: : The fact that other languages can implement it trivially doesn't mean : that Perl can. I'd like us to have realized what kind of internals : support is needed for a language feature (e.g., optree duping for : partially-evaluated subroutines) *before* speccing out the i

Re: RFC 76 (v1) Builtin: reduce

Jarkko Hietaniemi writes: : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still : > > consider the $ and $b to be warts.) : > > : > And anyhow, this will work just fine (see RFC 23): : > : > $sum = reduce ^a + ^b, @numbers; : : I have been amply reminded of this, thank

... as a term

Randal L. Schwartz writes: : if ($a == $b) { ... } # should this be string or number comparison? Actually, it's a syntax error, because of the ... there. :-) But that reminds me of something I wanted a few months ago. I'd entertain a proposal that ... be made a valid term that happens

Re: Things to remove

Tom Christiansen writes: : >I've very rarely found cases where ?? was useful and // didn't work, and : >never in regular code. : : >From the Camel: : : The C operator is most useful when an ordinary pattern match : would find the last rather than the first occurrence: : : open DIC

Re: Pre-RFC: Require a warning on spaces after here-document "terminator"

Ariel Scolnicov writes: : I was asked to debug a weird Perl5 problem yesterday. The code in : question looked roughly like this (indented 4 spaces, but otherwise : unchanged): : : #!perl -w : use strict; : : print <

Re: ... as a term

Ed Mills writes: : But don't {} or {1} sort of do the same thing? Well, { warn "Encountered stub"; (); } would be more like it. But the biggest problem with {} or {1} is that they don't resemble an ellipsis. Larry

Re: Pre-RFC: Require a warning on spaces after here-document "terminator"

[EMAIL PROTECTED] writes: :> : I would like to see a compiler warning for this: :> : "Spaces detected after apparent here document terminator", but :> : preferably phrased better. :> : :> : Are there any objections? :> :> I object, vaguely. I think it should just Do

Re: ... as a term

[EMAIL PROTECTED] writes: : I take it the existing C<...> operator would be unaffected? Essentially. The lexer is (and will continue to be) quite aware of the difference between terms and operators. The interesting thing about ... is that you have to be able to deal with it a statement with an

Re: Things to remove

[EMAIL PROTECTED] writes: : How about this then: : : In a void context, C dumps the program's current opcode representation : to its filehandle argument (or STDOUT, by default). It's not clear to me that reusing a lame keyword for this is the highest design goal. Let's come up with a real inter

Re: RFC: extend "study" to produce a fast grep through many regexes

David L. Nicol writes: : What if there were a faster way to do this, a way to C a : group of regexes and have the computer determine which ones had : parts in common, so that if $situation =~ m/^foo/ is true, the : fifty rules that start ^bar don't waste any time. At all. Perl 4 did this sort of

Re: ... as a term

[EMAIL PROTECTED] writes: : We already have plenty of statements with implied semicolons: : : print "foo"; : for @list {} : print "bar"; Yes, we do, and I'm trying to figure out how to write a prototype for one of those. :-) / 2 : I'd have expected: : : print (1, 2,

Re: ... as a term

John Porter writes: : Could you make it "evaporate" and compile time, just like the (proposed) qc()? Hard to make it evaporate at compile time and still give a warning at run time. :-) Larry

Re: Things to remove

Dan Sugalski writes: : What I've been hoping for is: : : 1) The ability to dump the program and its current state out into something : that can be reloaded later. (Though filehandles and other : external-interface things make this tricky) : : 2) The ability to dump out a variable and all its a

Re: Ideas that need RFCs?

Dan Sugalski writes: : At 10:35 AM 8/19/00 +1000, Damian Conway wrote: : >However, for Perl 6 I'd really like to see run-time access to the : >Real Tokenizer (tm): : > : > use tokenizer; : > : > my $tree = tokenizer( $sourcecode ); : > : >This would be dead handy for building sourc

Re: Things to remove

Tom Christiansen writes: : >2) The ability to dump out a variable and all its attached state into : >something that can be loaded in later somewhere else. : : To hope to do this completely and correctly is courageous. : : my @funx = (); : for my $name (qw/violet purple cream/) { :

Re: Ideas that need RFCs?

Randal L. Schwartz writes: : > "Joe" == Joe McMahon <[EMAIL PROTECTED]> writes: : : Joe> This is done by using SNOBOL's dynamic function evaluation and : Joe> conditional assignment during a pattern match. To do this kind of : Joe> thing in Perl, we'd need to be able to match a substring, and

Re: Perl should become PEARL

Suresh Kumar R writes: : Perl should become PEARL Er, the folks at http://www.irt.uni-hannover.de/pearl/pearl-gb.html might have something to say about that. Larry

Re: RFC 45 (v1) || should propagate result context to bo

Tom Christiansen writes: : It would appear that altering &&/|| on LHS context would entail, : in the list assignment scenario, calling that operand in list context : and then deciding whether it were true or not by some "intuitive" : means (almost certainly by using whether its element count were

Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

Bart Lateur writes: : Apropos those extended mechanisms: couldn't we use the same mechanism as : is currently in use for $!, for $@ too? I mean: $! in numerical context : gives an error number, in string context a text string. Then : : die "I'm outta here: $!"; : : should assign both the n

Re: RFC 127 (v1) Sane resolution to large function returns

Chaim Frenkel writes: : LW> P.S. I think we *could* let @foo and %bar return an object ref in scalar : LW> context, as long as the object returned overloads itself to behave as : LW> arrays and hashes currently do in scalar context. : : Isn't this an internals issue? Not completely. The scalar

Re: RFC 127 (v1) Sane resolution to large function returns

Dan Sugalski writes: : And do we want to consider making this (and its ilk) Do The Right Thing? : :(@foo, @bar) = (@bar, @foo); We certainly want to consider it, though perhaps not in -internals. You can talk about passing @bar and @foo around as lazy lists, and maybe even do lazy list-flatt

Re: Larry's ALS talk summary

Jarkko Hietaniemi writes: : > * XS, the system for extending Perl with C or C++, will be replaced : > with something much easier to use. This will give people very : > convenient access to existing code libraries, and write C or C++ : > subroutines that can be called as Perl subrout

Re: Larry's Apocalypse 1

David Grove writes: : [1] Strongs is pure Koine. I'd think Larry would be more of the Ionic : type. You might say I get a charge out of Homer. :-) Actually, I've done more Attic than Ionic. And I haven't done enough of any of them to get very far from my lexicon. But I started Greek at Seatt

Re: Larry's Apocalypse 1

Randal L. Schwartz writes: : > "Nathan" == Nathan Wiger <[EMAIL PROTECTED]> writes: : : Nathan> This is interesting, and in my gut I like it. Many people I've worked : Nathan> with end up writing: : : Nathan>@foo[0] : : Nathan> Which works. : : "Works", for some odd meaning of the word

Re: Larry's Apocalypse 1

David Whipp writes: : You may be right that there are no useful literals other than : strings, integers, reals and lists. OTOH, if we are going to : construct a meta-language which supports multiple syntaxes, : then it is very likely that each application-specific language : would have its own lit

Re: Larry's Apocalypse 1

Dan Sugalski writes: : If we're going to provide a mechanism to define the syntax of : a mini-language (or a maxi one, I suppose, though there are probably better : ways to do it) then the details of colons and constants and what-have-yous : are pretty close to irrelevant. I expect that most o

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

Dan Sugalski writes: : At 10:16 AM 4/17/2001 +0100, Tim Bunce wrote: : >On Mon, Apr 16, 2001 at 02:49:07PM -0500, Jarkko Hietaniemi wrote: : > > People seem to think that telling Perl 5 apart from Perl 6 is trivial. : > : >My reading of Larry's comments is that it will be _made_ trivial at the : >

Re: Larry's Apocalypse 1 \}

Dan Sugalski writes: : At 12:17 AM 4/20/2001 -0500, David L. Nicol wrote: : >Recursive parsing is not needed. We have the HERE string, which can : > include anything in with the rest of the code, by looking for the : > end-token. The perl5 Inline module works that way. Indeed, Perl 5 works th

Re: Tying & Overloading

=?iso-8859-1?Q?Dav=ED=F0?= Helgason writes: : 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 s

Re: Tying & Overloading

Stephen P. Potter writes: : Maybe this is a crazy (or stupid) idea, but why couldn't we use the $, @, : and % characters? : : @foo = @a @+ @b; # element by element add Because it's difficult to tell the operators from the terms visually. Larry

Re: Tying & Overloading

Nathan Wiger writes: : 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 us

Re: Tying & Overloading

[EMAIL PROTECTED] writes: : Okay, then: : : @foo = @( @a + @b );# @(), $(), and %() set context. : : Easier to identify the operators, and little or no question about the : context... Well, sure, though it was already in list context from the assignment... I do expect that @() and

Re: Tying & Overloading

Glenn Linderman writes: : Why not : :@foo = @( a + b ); # element by element add of @a and @b I expect that's be written: @foo := @a + @b; where the := says to treat the left side as a prototype, and a bare array in a prototype is going to put scalar context on the right side, and a

Re: Tying & Overloading

Graham Barr writes: : On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote: : > I do expect that @() and $() will be used for interpolating list and : > scalar expressions into strings, and it is probably the case the $() : > would be a synonym for scalar(). @() would then be a sy

Re: Tying & Overloading

Bart Lateur writes: : Or, in analogy to "cmp", "gt" etc: : : $a = $b plus $c; : or : $a = $b cat $c; It would probably have been C if it had come to that. Larry

Re: Tying & Overloading

Simon Cozens writes: : On Mon, Apr 23, 2001 at 11:48:35AM -0700, Larry Wall wrote: : > :@foo = @( a + b ); # element by element add of @a and @b : > I expect that's be written: : > : > @foo := @a + @b; : : Two different assignment operators? I can understand the inte

Re: Tying & Overloading

John Porter writes: : Larry Wall wrote: : > I do expect that @() and $() will be used for interpolating list and : > scalar expressions into strings, and it is probably the case the $() : > would be a synonym for scalar(). @() would then be a synonym for : > the mythical list() oper

Re: Tying & Overloading

[EMAIL PROTECTED] writes: : On 4/23/01 3:25 PM, Larry Wall wrote: : > : >From a trainer's point of view, having two operators which look very : > similar, : are used for the same thing in various different languages, and do : > *almost* : the same thing but not quite, is comple

Re: s/./~/g

Branden writes: : I'm starting to be a bit worried with what I'm reading... : : 1) Use $obj.method instead of $obj->method : : : The big question is: why fix what is not broken? Why introduce Javaisms and : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 : code (and Pe

Re: s/./~/g

John Porter writes: : Larry Wall wrote: : > Surely it's not the . itself, but the requirement that you fit everything : > into that one syntactic mold. Perl's not going to do that. : : I'm not opposed to the change, but I want to make one point: : certain characters (lik

Re: Larry's Apocalypse 1 \}

David L. Nicol writes: : Dan Sugalski wrote: : > I'm not a parser guy by any means (unfortunately) but we have : > the distinct possibility of completely replacing all of the : > parser rules after token X appears, whatever that token might : > be. (Heck, we may have the possibility of replacing t

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

Bart Lateur writes: : On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote: : : >Using + for concat: no! : > : >My vote is to use . and require space before and after. : >$this.$is.$ugly.$anyway ;) : : My vote is to ditch the concat operator altogether. Hey, we have : interpolation! : :

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

Edward Peschko writes: : I guess my question is what would be the syntax to access hashes? Would : : $hashref.{ } : : be that desirable? I really like ->{ } in that case.. It won't be either of those. It'll simply be $hashref{ }. Larry

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

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

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

Bart Lateur writes: : Ok. So how about hash slices? Is $hash{$a, $b}, the faked : multidimensional hash, going to go? Yes, fake multidimensional hashes will be defenestrated. Larry

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

Bart Lateur writes: : Er... hip hip hurray?!?! : : This is precisely the reason why I came up with the raw idea of : highlander variables in the first place: because it's annoying not being : able to access a hash passed to a sub through a hash reference, in the : normal way. Not unless you do al

Re: Flexible parsing (was Tying & Overloading)

Eric Roode writes: : John Porter wrote: : >IIUC, this ability is precisely what Larry was saying Perl6 would have. : : I may have my history wrong here, but didn't Ada try that? Not at all. The syntax of Ada was nailed down tighter that almost any language that ever existed. : Super-flexible,

Re: Flexible parsing (was Tying & Overloading)

Dan Sugalski writes: : And on the other hand you have things like Forth where every program : essentially defines its own variant of the language, and that works out : reasonably well. (Granted it's more of a niche language, especially today, : but that's probably more due to its RPN syntax) P

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

Nathan Wiger writes: : Now, it may be that all the "We should use ." people are just keeping : quiet, or think it's obvious why this is a benefit, but I'm unconvinced. : Again, I'm open-minded, but the only argument I've really heard is to : make Perl more Java/Python-like. This doesn't sway me at

Re: Flexible parsing (was Tying & Overloading)

Dan Sugalski writes: : It's also the one reason that I really like the idea of policy files of : some sort, to allow sites that don't want this sort of thing to forbid it. : I'm not talking things like perl automagically loading policy files in. : Rather having "use site_policy;" set limits tha

Re: Flexible parsing (was Tying & Overloading)

John Porter writes: : Larry Wall wrote: : > On the other hand, people don't generally declare which dialect they're : > going to speak in before they start speaking. : : On the other other hand, perl already embraces the philosophy : of pre-declaring things that change the l

Re: Flexible parsing (was Tying & Overloading)

Dan Sugalski writes: : Besides, having the site administrator forbid the installation of parser : tweaks might not be what is wanted. If we get PPython in there, a site may : well have a Python.pm module handy, and source might start: : :use site_policy qw(Python); : : for modules that wer

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

Simon Cozens writes: : Hey, that would make "_ _ __" legal Perl code. Abigail, Abigail! Now we just need to make "... ___ ..." mean something exceptional. : (I still prefer ~, but acknowledge that this is just bikeshed painting.) Bikesheds need to be painted occasionally. Larry

Re: Flexible parsing (was Tying & Overloading)

[EMAIL PROTECTED] writes: :> use OReilly::Policy; :> :> or :> :> use Mongolian::Navy::ProcurementOffice::Policy; :> :> might be more in order. : : You Americans and your non-ISO penchant for putting the specific before : the general. Surely that should be: :

Re: Flexible parsing (was Tying & Overloading)

Dan Sugalski writes: : I hadn't really considered having a separate module for each type of site : policy decision. Er, neither had I. Each site only has one policy file. I just want it named after the actual site, not some generic name like "Policy". I think policy files are inherently non-p

Re: Please make "last" work in "grep"

Michael G Schwern writes: : (grep {...} @stuff)[0] will work, but its inelegant. It's inelegant only because the slice doesn't know how to tell the iterator it only needs one value. If it did know, you'd call it elegant. :-) Larry

Re: .NET

David Grove writes: : Larry, et. al.: Is this similarity on purpose? Yes, but only becase .NET is a VM, not because it's from MicroSoft. The basic goal is to have a Perl VM that can sit easily on other VMs, whether .NET's or Java's or our own. Another example of competing by cooperating, which

Re: Please make "last" work in "grep"

H.Merijn Brand writes: : On Wed, 2 May 2001 08:05:29 -0700 (PDT), Larry Wall <[EMAIL PROTECTED]> wrote: : > Michael G Schwern writes: : > : (grep {...} @stuff)[0] will work, but its inelegant. : > : > It's inelegant only because the slice doesn't know how to tell th

Re: Please make "last" work in "grep"

Bart Lateur writes: : Because you might have a wantarray situation that expects no values? : : () =3D whateveryouwant(); : : You can always expect one more than is on the LHS. : : How is this currently handled with split()? It fakes up a third argument that is one more than the length of

Re: Please make "last" work in "grep"

Dan Sugalski writes: : I'd really like to get into the details of what is and isn't valid for the : optimizer to do, though I expect it's still a little early in the : Apocalypse season for that. Doubtless we'll do as other compilers do, and have a little knob you just keep turning up until som

Re: Please make "last" work in "grep"

[EMAIL PROTECTED] writes: :> >Hopefully the "something similar", I hope in Perl 6 we will able to :> >bury the "0 but true" workaround to the backyard on a moonless night :-) :> :> Especially since you don't need it. "0E0" and "0.", to name just two, :> work just as well. ;-

Re: So, we need a code name...

Edward Peschko writes: : > : (is a nice city in Italy with a great symbol, the tower of Pisa). : > : : > : a'P' at the beginning, which means 'Perl', : > : an 'I' which may mean 'Interpreter', : > : a'S' which may means'Six' : > : an 'A' which may

Re: apo 2

David L. Nicol writes: : I am going to miss doublequoting being the default quoting for : here strings. I find that to be a very nice optimization and : would like to know more about the reasoning behind taking it : away. I worry that official standard p6 will be more difficult : to use than off

Re: apo 2

Edward Peschko writes: : Anyways, my one curiosity that sticks out would be: why \Q as being a way to : disambiguate? You could do the same thing with: : : print "$foo\[1]\n" : vs : print "$foo[1]\n"; Not good enough. Consider what this might means: m/$foo\[a-z]\n/ Is it matching a litera

Re: Apo2: \Q ambiguity

Richard Proctor writes: : In Apocalypse 2, \Q is being used for two things, and I believe this may be : ambiguious. : : It has the current \Quote meaning admitibly \Q{oute} it is also being : proposed for a null token disambiguate context. As in $foo\Q[bar]. Hmm, yes, that's a problem. I'd for

Re: Apo2: \Q ambiguity

Larry Wall writes: : Richard Proctor writes: : : In Apocalypse 2, \Q is being used for two things, and I believe this may be : : ambiguious. : : : : It has the current \Quote meaning admitibly \Q{oute} it is also being : : proposed for a null token disambiguate context. As in $foo\Q[bar

  1   2   3   4   5   6   7   8   9   10   >