Re: \z vs \Z vs $

On Wed, 20 Sep 2000 15:16:20 -0600, Tom Christiansen wrote: >>That was my second thought. I kinda like it, because //s would have two >>effects: > >> + let . match a newline too (current) > >> + let /$/ NOT accept a trailing newline (new) > >Don't forget /s's other meaning. I gather you're talki

Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely

On Thu, 28 Sep 2000 10:16:43 +0100, Tom Christiansen wrote: >Try thinking of it this way: it's only a bareword if >it would make use strict whinge at you. So every bareword would be recognized as a sub. That, is nice. For starters, Perl parsers can more easily recognize a sub name, without a ne

Re: regexp RFCs: freeze 'em or lose 'em

On Sat, 30 Sep 2000 13:55:40 +0100, Hugo wrote: >The RFCs listed below are still listed as 'developing'. The deadline is >given as 1st October, but I'm not sure where the precise cutoff point >is - Nat, can you confirm? > >As I understand it, RFCs not frozen by the deadline will be treated as >wi

Re: RFC 348 (v1) Regex assertions in plain Perl code

On Sat, 30 Sep 2000 00:57:47 +0100, Hugo wrote: >:"local" inside embedded code will no longer be supported, nor will >:consitional regexes. The Perl5 -> Perl6 translator should warn if it >:ever encounters one of these. > >I'm not convinced that removing either of these are necessary to the >main

Re: RFC 290 (v1) Remove -X

On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: >Another option is to stuff the long names into some namespace, and >export them upon request (or maybe not export them, upon request). Can you say "method"? -- Bart.

Re: RFC 267 (v1) Eliminate dump() function

On 21 Sep 2000 03:55:21 -, Perl6 RFC Librarian wrote: >Eliminate dump() function >Get rid of it completely. I think that, for the rare occasions people want this functionality, one of the many O (B) modules should offer it, at least in spirit. -- Bart.

Re: RFC 72 (v4) Variable-length lookbehind.

On 30 Sep 2000 19:50:27 -, Perl6 RFC Librarian wrote: >In Perl6, lookbehind in regular expressions should be extended to permit >not only fixed-length, but also variable-length lookbehind. I see no mention of negative lookbehind. As I wrote before, in: /(?

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

On 28 Sep 2000 20:57:39 -, Perl6 RFC Librarian wrote: >Currently, C<\1> and $1 have only slightly different meanings within a >regex. Let's consolidate them together, eliminate the differences, and >settle on $1 as the standard. I wrote this before, but apparently you didn't hear it. Let me

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

On Wed, 04 Oct 2000 03:15:22 -0600, Tom Christiansen wrote: >We did this for the camel. Which, I remind the world, was >written in pod. You, masochist. (duck, and run) -- Bart.

Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()

On Tue, 26 Sep 2000 08:10:39 -0700, Nathan Wiger wrote: >Well, you can easily do this already with > > $date = utcdate (time + $offset); > >Or even: > > $date = utcdate (time + &getoffset('US/Pacific')); Unfortunately, because Daylight Saving Time is largely equivalent to Time Zones, $offset

Re: (random) musings on I/O disciplines

On Wed, 27 Sep 2000 16:56:37 -0400, Dan Sugalski wrote: >My gut feel is that there'll be a "default encoding" for filehandles and we >*won't* try and get clever. My gut feeling says that the text read from file should be treated as native text, and should remain native text. I want plain Mac te

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

I should have said: file-scoped lexical. On Sat, 30 Sep 2000 21:56:43 +0100, Nicholas Clark wrote: >If it's lexically scoped, would it be for arrays declared in that scope, or >for arrays accessed in that scope? >I'm not sure. I think I see potential breakage both ways. You don't declare Perl a

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

On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian wrote: >Perl6 make it *easier* to write CGI programs than Perl5. That is a strange sentence. But anyway: whould this imply that URL- and simple HTML escaping and back, will now be available through pack()/unpack()? Just like UUE? ;-) -

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

On Sat, 30 Sep 2000 16:39:04 -0400, Adam Turoff wrote: >I repeat: > >> >All of the other features offered by Lincoln Stein's CGI.pm should remain, >> >but should not be deeply integrated into Perl6. > ^^^ >:-) > >The proposed 'use cgi;' pragma is concerned with gluing Perl into a cgi

Re: RFC 136 (v3) Implementation of hash iterators

On 28 Sep 2000 19:40:01 -, Perl6 RFC Librarian wrote: >=head2 How iterators might work in perl 6 > >In perl 6 the keys and values functions should no longer use the >same iterator as the each function - each use of keys and values >should use it's own private iterator instead. Is that per Da

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

On 1 Oct 2000 06:26:40 -, Perl6 RFC Librarian wrote: >If you did the following: > >C<"Bilbo Baggins" =~ /((\w+)\s+(\w+))/> > >Then @/ would contain the following: > >C<$/[0]> the compiled equivalent of C, > >C<$/[1]> the string "Bilbo Baggins" > >C<$/[2]> the string "Bilbo" > >C<$/[3]> the s

Re: RFC 332 (v1) Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

On Thu, 28 Sep 2000 23:54:20 +0100, Hugo wrote: >I still like the idea of $$, as I described it in the original thread. >I've seen no comments for or against at this time. I intend to put this in the RFC: Hugo prefers to add an alternative, like /$$/, wich would behave like this. But an al

redraft for v2: RFC 332 Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

=head1 TITLE Regex: Make /$/ equivalent to /\z/ under the '/s' modifier =head1 VERSION Maintainer: Bart Lateur <[EMAIL PROTECTED]> Date: 1 Oct 2000 Mailing List: [EMAIL PROTECTED] Number: 332 Version: 2 Status: Developing (redraft) =head1 ABSTRACT To most Perlers

Re: RFC 361 (v1) Simplifying split()

On 1 Oct 2000 06:40:08 -, Perl6 RFC Librarian wrote: >Perl 5 split does five things that I think are just annoying, and >which I suggest be removed: I've got one more problem. for my $i (0 .. 4) { $_ = ':' x $i; my @a = split /:/, "", -1; my $coun

Re: RFC 361 (v1) Simplifying split()

On Sun, 01 Oct 2000 11:18:58 +0200, Bart Lateur wrote: > my @a = split /:/, "", -1; Oops. that should be my @a = split /:/, $_, -1; -- Bart.

Re: redraft (v2) for RFC 348 Regex assertions in plain Perl code

On Sun, 01 Oct 2000 18:43:27 +0100, Hugo wrote: >:This makes the implementation very tricky. I >:wouldn't be surprised if precisely this feature is the main reason why >:the current implementation is so notoriously unstable. > >I'm not aware of any instability caused by this. The instability is >

Re: Undermining the Perl Language

On Sun, 1 Oct 2000 22:24:12 +0100, Tim Bunce wrote: >FWIW, I agree entirely with Randal here. How do you prove that you're not paranoid, that "they" are really after you? How do you prove that putting aluminum foil on your head really helps? You can't. That said, I can only say one thing: if y

Re: RFC 290 (v1) Remove -X

On Sun, 24 Sep 2000 23:05:45 -0700, Nathan Wiger wrote: >> Perl programmers happy with the -X syntax will need to get used to the >> lengthier replacement. > >Blech. I certainly think that long functions are fine and dandy, but I'd >loathe the day that I'd have to give up my -X stuff. I *love* it

Re: RFC 290 (v1) Remove -X

On Mon, 25 Sep 2000 10:22:46 -0400, Clayton Scott wrote: >It: > + stacks multiple tests quite cleanly without excess verbiage > (if (-e && -T && -s && -x){...} gets a little tedious especially > if you don't use $_) Perhaps you want is to use $_. A "with" statement, or is it an expression, s

Re: RFC 361 (v1) Simplifying split()

On Fri, 6 Oct 2000 23:26:44 -0500, Jonathan Scott Duff wrote: > @foo = split; > # BECOMES > @foo = split; pop @foo until $foo[-1]; That doesn't fly. What if that last field is "0"? > @foo = split ' '; > # BECOMES > @foo = split /\s+/; shift @foo; What if th

Re: code name for perl 6

On 19 Oct 2000 22:01:23 -, [EMAIL PROTECTED] wrote: >the code name "omega" would be a fitting handle...after all, this will be >the last perl of all...i am obviously assuming perl 6 will not be still born. Hey, why not something in the line of "2PI" ("P2PI"?). After all, 2 * PI is what the v

Re: Critique available

On Thu, 2 Nov 2000 16:10:12 +, Simon Cozens wrote: >On Thu, Nov 02, 2000 at 10:11:56AM -0500, Mark-Jason Dominus wrote: >> My critique of the Perl 6 RFC process and following discussion is now >> available at >> http://www.perl.com/pub/2000/11/perl6rfc.html > >Agree 100% to every poin

Re: SvPV*

On Fri, 24 Nov 2000 08:54:43 +0100, Roland Giersig wrote: >Maybe the title should be : > >"Perl should use XML as its basic data type instead of linear strings" Horrible. I kinda liked your original proposal. But you should NOT focus on XML. That leaves out too many other possible data sources:

Re: To get things started...

On Tue, 21 Nov 2000 17:24:49 +, Simon Cozens wrote: >I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles, >Techniques and Tools". AKA "The Dragon Book". You're not the only one to mention this book on this list. IMO, this book is really thick to crawl through, and in the e

Re: To get things started...

On Wed, 22 Nov 2000 14:15:57 -0500, Dan Sugalski wrote: >>We bootstrap on perl5 to get a bytecode stream, and then that bytecode >>stream had better stay supported. > >Yup. It's one way to ensure backwards compatibility... :) I assume a byte is still 8 bits? So you have a max of 256 different (1

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

On Fri, 15 Dec 2000 13:42:44 -0700, Kevin Walker wrote: >Deven seems to be advocating thinking about regular expressions >without worrying too much about the implementation, even at a fairly >abstract level. Here's a counter example: /dc/ Shouldn't a non-greed

Re: Now, to try again...

On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote: >I think the problems with this that were raised in the past are: > * parsing partial source > * does this mean that the parser has to reparse the whole sourcefile > every time you type a character? Hold it. I don't think that

Re: perl IS an event loop (was Re: Speaking of signals...)

On Sat, 6 Jan 2001 00:45:11 +, Simon Cozens wrote: >No, it's exactly what Perl 5 does. > >This is the Perl interpreter: >while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) { >PERL_ASYNC_CHECK(); >} > >The only problem is that right now, PERL_ASYNC_CHECK doesn't actually >do a

Re: JWZ on s/Java/Perl/

On Sat, 27 Jan 2001 18:16:52 -0500, Michael G Schwern wrote: > o The architecture-interrogation primitives are inadequate; there is no > robust way to ask ``am I running on Windows'' or ``am I running on > Unix.'' > >**We have $^O, but it requires parsing every time** Uhm, I'm

Re: RFC195: Do not remove 'chop' PLEASE!

On Sat, 27 Jan 2001 15:42:43 -0700, root wrote: >I read RFC195 suggesting to drop 'chop' and go with 'chomp'. >What does 'chop' have anything to do with 'chomp'? >I'm totally oppose to that. Consider: > >my $s; >map { /\S/ && $s .= "$_ " } split(/\s+/,@_); >chop($s); >return $s; Excuse me, but y

Re: RFC195: Do not remove 'chop' PLEASE!

On Mon, 29 Jan 2001 11:47:47 -0500, Uri Guttman wrote: >well, according to this > >perl5.6.0 -le '%h = qw( a b c d ); $_ .= 1 for %h ; print values %h ; chop %h ; print >values %h' >b1d1 >bd > >it doesn't appear to be a chop specific thing. unraveling a hash always >seems to use aliases for the

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

On Tue, 30 Jan 2001 04:13:39 -0500, Michael G Schwern wrote: >Is there any really good reason why sleep() doesn't work for >microseconds? I mean, if I can do this: > >sub sleep { >my($time) = shift; >if( /^[+-]?\d+$/ ) { >sleep($time); >} >else { >

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

On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote: >Why the urge to move it out of the core? Should perl6 be like Python, >where you first need to do a gazillion imports before you can do anything >useful? Say goodbye to quick one-liners then. It doesn't have to be like that. Functions

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

On Wed, 31 Jan 2001 08:53:13 -0600, Jarkko Hietaniemi wrote: >So nice of you to volunteer for being our help desk person man for >explaining to people why their time() just got broken :-) I'd use the same function name for both the integer version of time(), and the hires version. All you need i

Re: safe signals + sub-second alarms [was: sleep(0.5) should DWIM]

On Wed, 31 Jan 2001 11:36:32 -0500, Ken Fox wrote: > You want perl to block a thread and then busy wait until >it's time for the thread to wake up? What if we take the ordinary sleep() for the largest part of the sleeping time (no busy wait), and the 4 argument select for the remainder, i.e. sub

Re: assign to magic name-of-function variable instead of "return"

On Sun, 4 Feb 2001 15:43:29 -0500, James Mastros wrote: >The $__ option seems a lot better to me, because there's no syntatical >reason against self-reference. ($^R for return might be a better name -- >unless we've already used that for somthing else. Nope.) What do you mean, "nope"? It *is*

Re: Really auto autoloaded modules

On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote: >> > use autoload { Bar => 'http://www.cpan.org/modules/Bar' }, >> > { Baz => 'ftp://my.local.domain/perl-modules/Baz', VERSION => >>2 }; >> >>Very good idea indeed!!! Append the wishlist to add this module to perl6's >>standard

Re: assign to magic name-of-function variable instead of "return"

On Tue, 6 Feb 2001 04:36:36 +1100 (EST), Damian Conway wrote: >RFC 271 handles this. Your example would be: > >sub readit { >open F, "< $f" ... >scalar() >} >post readit { >close F; >} The connection between these two things is

Re: Magic [Slightly Off-Topic... please point me to documentation]

On Tue, 6 Feb 2001 17:53:17 -0200, Branden wrote: >It appears you're blessing one reference and returning another... like > >sub new { >my $key; >my $a = \$key; >my $b = \$key; >bless $a; >return $b; >} > >I think the problem is not with the overloa

Re: vtables: Assignment vs. Aliasing

[CC'ed to language, because I think it's there that it belongs] On Mon, 5 Feb 2001 15:35:18 -0200, Branden wrote: >There are two possible things that could happen when you say: >$a = $b; >@a = @b; # or >%a = %b; > >These two things are assignment and aliasing. No way. Although I th

Re: POST blocks (like END, but in a sub or sub-like scope)

On Wed, 7 Feb 2001 23:41:32 +, Nicholas Clark wrote: >[on the other hand, I'll argue the other side that > >{ > my $flag > open FOO, " ... >} >post { > close FOO if $flag; >} > >is clearer because the tidy up doesn't visually get in the way of the flow >of what you're doing, and you can s

Re: Auto-install (was autoloaded...)

On Thu, 8 Feb 2001 17:39:01 +, Nicholas Clark wrote: >On Thu, Feb 08, 2001 at 12:26:59PM -0500, Dan Sugalski wrote: >> (Including Archive::Tar as part of the base perl distribution's not >> inappropriate, assuming we can get permission. ) Since it's already part of the "standard distributio

Re: Auto-install (was autoloaded...)

On Thu, 8 Feb 2001 17:49:45 -0200, Branden wrote: >I've never actually used PPM, only read about it in >the web. I guess their file format is a disguised .tar.gz, right? It's a combination of an XML file, file extension "PPD", which describes the properties and dependencies, and platforms, and a

Re: Auto-install (was autoloaded...)

On Fri, 9 Feb 2001 21:18:55 +, Nicholas Clark wrote: >> What? tar -z not good enough for you? > >I believe that that wognt work ugnless you have gnu tar. As a Windows user, I should add: * Archive::Tar is part of the Perl 5.6.0 distributions for Win32 (Activestate and IndigoPerl) * On a

Re: JWZ on s/Java/Perl/

On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote: >There are two main reasons advanced garbage collectors are fast: > > 1. Cheap allocations. Most fast collectors have a one or two >instruction malloc. In C it looks like this: > > void *malloc(size) { void *obj = heap; heap += size; ret

Re: JWZ on s/Java/Perl/

On Fri, 9 Feb 2001 16:14:34 -0800, Mark Koopman wrote: >but is this an example of the way people SHOULD code, or simply are ABLE to >code this. are we considering to deprecate this type of bad style, and force >to a programmer to, in this case, supply a ref to %baz in the arguements to >this s

Re: End-of-scope actions: do/eval duality.

On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote: >In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is >set to the result of an eval or do. How does this impact exception >handling tests on $@ to determine if an exception was thrown, if $@ can >be set by a do ? OR

Re: End-of-scope actions: do/eval duality.

On Thu, 15 Feb 2001 10:04:51 -0300, Branden wrote: >Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a >little too much not-orthogonal? Why don't we require `eval { do FILE }' to >have the behaviour of not dying and setting $@ ? The reason for its existence is simple: histor

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

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. That doesn't mean that davocates for either side don't have anything interesting to say. For starters, it's usually dissatisfaction wi

Re: Warnings, strict, and CPAN

On Fri, 16 Feb 2001 21:03:54 -0800, Edward Peschko wrote: >It is one hell of a burden to find a missing 'use strict' or 'use warnings'. >'Well, type them then' you say. Right, and always type ';' at each line, or 1; >at the end of each file. Its as unavoidable as a *syntax error*, which is the >

Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test

On Mon, 19 Feb 2001 15:47:12 +0100, Johan Vromans wrote: >As an active non-smoker, I'd appreciate a different name. You guys (=plural) are nuts. So much bickering over such a tiny irrelevant detail. But anyway, if you want a clear and explicit name, why not "smoketesters". Nothing to do with to

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

On Tue, 20 Feb 2001 16:31:35 -0500, Bryan C. Warnock wrote: >Scalar value @foo[$bar] better written as $foo[$bar], for one. I agree on this one (hash slices too), if this expression is in list context. There is no error in @r = map { blah } @foo{$bar}; -- Bart.

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

On Wed, 21 Feb 2001 16:01:39 -0500, [EMAIL PROTECTED] wrote: >Has anyone actually used a language which has run-time warnings on by >default? Or even know of one? Actually, it's pretty common. Only, most languages are not as forgiving as perl, and what is merely a warning in Perl, is a fatal er

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

On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote: >On Wed, 21 Feb 2001, Bart Lateur wrote: > >> Actually, it's pretty common. Only, most languages are not as forgiving >> as perl, and what is merely a warning in Perl, is a fatal error in those >> language

Re: Schwartzian Transform

On Wed, 21 Mar 2001 15:40:20 -0500, John Porter wrote: >Uri Guttman wrote: >> JP> y/L/A/; >> >> tell that to perllol :) > >I do, through clenched teeth, every time I see it. IMHO, it is: HoA HoH LoA LoH -- Bart.

Re: Schwartzian transforms

On Wed, 28 Mar 2001 11:11:20 -0500, Dan Sugalski wrote: > "Can perl automatically optimize away function and tie calls inside >a sort function, and under what circumstances?" > >It doesn't really matter if the functions inside the sort function are >idempotent--what matters is whether it's

Re: PDD 4 internal data types, version 1.1

On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote: >And then, if we have BigFloat, we need a way to specify rounding and >precision. Otherwise 1/3 eats up all memory or provides limits ;o) Er... may I suggest ratio's as a data format? It won't work for sqrt(2) or PI, but it can easily store

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

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! "$this$is$just$as$ugly$but$it$works"

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

On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote: >How do you concatenate together a list of variables that's longer than one >line without using super-long lines? Going to the shell syntax of: > >PATH=/some/long:/bunch/of:/stuff >PATH="${PATH}:/more/stuff" > >would really be a shame.

Re: Tying & Overloading

On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote: >While that's true, concatenation is quite a common operation >that I'd be really >uncomfortable with it necessitating 4 keystrokes (" cat") instead of one. Er, "~" is an extremely annoying character to type at many keyboards. It may depen

Re: Tying & Overloading

On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote: >Let's put it a different way - if we can find a short operator which >is readily accessible on most people's keyboards, then that would >score over a longer operator which is readily accessible on most >people's keyboards. Maybe ~ isn't th

Re: Sane "+" string concat proposal

On Wed, 25 Apr 2001 00:37:53 +0100, Simon Cozens wrote: >>$string3 = $string1 . $string2; >>$string3 = "$string1" + "$string2"; > >That's now *five* characters required to perform a very common operation. > >Rather than one. I'm really beginning to like $string3 = $string1 _ $s

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

On Tue, 24 Apr 2001 19:17:08 -0500, Jarkko Hietaniemi wrote: >Wasn't Perl also taken, so why care...? I vaguely remember reading >about another language called PERL... It was "Pearl", AFAIK. That's why the "a" got missing. So I've been told... ("Practical Extracting And Reporting Language"... y

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

On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), Larry Wall wrote: >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 $hashre

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

On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote: >: 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. Ok. So how about hash slices? Is $hash{$a, $b}, the faked multidimension

Re: Tying & Overloading

On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote: >If the idea is supporting arbitrary add-on operators, which I believe will >be done seldom, for only some specific classes, wouldn't it be better to >have a ``catch all'' entry for operators different than the built-in ones? > >Of course, add-

Re: Sane "+" string concat proposal

On Wed, 25 Apr 2001 08:25:40 -0400, Stephen P. Potter wrote: >| I'm really beginning to like >| >| $string3 = $string1 _ $string2; >| >| The underscore indeed "connects" the two strings. > >This still breaks because _ is a valid word character. So are "cmp", "and", "lt", and the proposed

Re: Curious: -> vs .

On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: >the idea of a "dereference operator" dumbfounds lots >of folks. "What's an object got to do with a reference, much less a >pointer?" A p5 object is very confusing to others for this reason, and so >is the syntax. So you want a method in

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

On Thu, 26 Apr 2001 10:15:14 +0200, Bart Lateur wrote: >For example, in > > -3.4 > >and in > > 2-3.4 > >the - sign is a *different* kind of operator. No conflict. Well alright, in the first line, the "-" might be part of the number. Replace &

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

On Wed, 25 Apr 2001 18:19:40 GMT, Fred Heutte wrote: >Yes, I know ~ is the bitwise negation operator. Have you EVER used it? Yes. A lot. But there is no conflict. ~ is currently just an unary operator, while your use would be as a binary operator (are those the correct terms?). For example, in

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

On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote: >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

Re: Curious: -> vs .

On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: >$bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. -- Bart.

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

On Wed, 2 May 2001 11:41:32 -0500, Jarkko Hietaniemi wrote: >but I suspect in this case want('LIST') would >> return that magical "0 but true" or something similar. > >Hopefully the "something similar", I hope in Perl 6 we will able to >bury the "0 but true" workaround to the backyard on a moonle

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

On Wed, 2 May 2001 17:05:31 +0100, Graham Barr wrote: >wantarray-ness is already passed along the call stack today. Thats >the whole point of it. So what is the difference in passing a number >instead of a boolean ? Because you might have a wantarray situation that expects no values? ()

Re: Apo2: \Q ambiguity

On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote: >Have you considered allowing Unicode characters as alternatives to some of >the less pleasant looking bits? $foo<<1>> (where << and >> are the double >angle characters) as an alternative to $foo\Q[1] if the user's got the >characters han

Re: apo 2

On Thu, 03 May 2001 22:14:47 -0500, David L. Nicol wrote: >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 was already panicking when I saw this me

Re: apo 2

On Fri, 4 May 2001 10:49:48 -0500 , Garrett Goebel wrote: >> > > And btw . . . Wouldn't >> > > >> > > $thing has property >> > > >> > > make more sense than >> > > >> > > $thing is property >> > >> >"$foo has true" doesn't flow as well as "$foo is true". Dunno quite >> >what the oth

Re: Apoc2 - concerns

On Sat, 5 May 2001 15:22:40 -0700, Nathan Wiger wrote: > I suggest >that we simply create another q-op to do the qw-ish things you're proposing. >Perhaps qi() for "interpolate" or something else. qqw -- Bart.

Re: what I meant about hungarian notation

On Tue, 08 May 2001 20:21:10 -0500, David L. Nicol wrote: >What if, instead of cramming everything into "scalar" to the point >where it loses its value as "a data type that magically converts >between numeric and string, as needed," we undo the Great Perl5 >Dilution and undecorate references. Un

Re: what I meant about hungarian notation

I really need to spell-check better. >Undecorated if for function calls and methods. And buolt-ins, of course. Undecorated is for function calls and methods. And built-ins, of course. -- Bart.

Re: what I meant about hungarian notation

On Wed, 9 May 2001 11:06:45 -0400, Bryan C. Warnock wrote: >>At that >> point, Hungarian notation fell apart for me. Its strict use adds (IMO) as >> much confusion as MicroSoft's redefinition of C, with thousands of >> typedefs representing basic types ("LPSTR" and "HWND" come to mind as the >> m

Re: what I meant about hungarian notation

On Wed, 9 May 2001 09:47:56 -0400, John Porter wrote: >> Undecorated if for function calls and methods. And buolt-ins, of course. > >No, that's the situation already. David is proposing a change. > >> So what you're really saying is that references aren't really scalars, >> but their own type. T

Re: Apoc2 - concerns ::::: new mascot?

On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote: >I remember someone (whether at O'Reilly or >not I don't remember) saying that, even if it looks like a horse but has a >hump, it's not allowed. Or was that an alpaca with a llama... > >The RFC pleads for a community spirit from ORA. Barring t

Re: Apoc2 - concerns

On Fri, 4 May 2001 18:20:52 -0700 (PDT), Larry Wall wrote: >: 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, but yes, that's the basic idea. It's possible >that iterator variables should be more synta

Re: Perl, the new generation

On Fri, 11 May 2001 08:20:53 -0400, John Porter wrote: >> Let's not confuse Perl 6, the Language, with Perl 6, the Implementation, >> which includes compatibility apparatus that knows about Perl 5. > >Maybe we need more difference in the names than "exactly one bit". Then maybe it's a good thing

Re: A proposal for more powerful text processing to be built in to Perl: Flex and Pushdown Expressions.

On Fri, 11 May 2001 08:29:07 -0500, Tad McClellan wrote: >On Thu, May 10, 2001 at 04:26:56PM -0700, Daniel S. Wilkerson wrote: > >> Flex - Put all of flex right into Perl. >Don't we already have that in Perl 5? Sortof. What he is proposing, is again the age old proposal of putting the notion o

Re: Tying & Overloading

On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr wrote: >> Or we change the concatenation operator. >I am thinking that maybe it should be a 2 character operator with at >least one of then being + as + is common in many other languages >for doing concatenation. Or, in analogy to "cmp", "gt" etc:

Re: Apoc2 - concerns

On Thu, 10 May 2001 17:15:09 +0100, Simon Cozens wrote: >> What you could do, is treat an iterator as "something similar to reading >> a line from a file". Tied filehandles allow something like it in Perl5. > >You know, if what you say is true, I'd expect to find a module on CPAN which >turns the

Re: Apoc2 - concerns

On Mon, 14 May 2001 12:39:11 +0100, Simon Cozens wrote: >I think the more immediate problem with Sather is that it's totally obscure. >I'd never heard of it. I'd never read any articles about it. It has no >publicity. If people haven't heard of it, it'll remain unpopular.

Re: what I meant about hungarian notation

On Mon, 14 May 2001 20:38:31 +0100, Graham Barr wrote: >You forgot > > $bar[$foo]; # $bar is an array reference > $bar{$foo}; # $bar is a hash reference As to what the combined $bar[$foo] would mean: that depends on what $bar contains. (Aw! That hurt!) -- Bar

Re: Damian Conway's Exegesis 2

On Wed, 16 May 2001 13:49:42 +0200, Carl Johan Berglund wrote: >sub show {print "6"} >print "Perl ${show()}\n"; > >(That prints "6Perl", not "Perl 6".) > >If you want to call the subroutine in the middle of the string, you >should make it _return_ something, not print it. This person obviously

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

On Fri, 18 May 2001 23:26:53 +0200, Trond Michelsen wrote: >While I understand how "0 but true" is a cute hack that is destined to >be replaced by a truth property, I fail to realize how it's useful to >have a value that's true no matter what value you assign to it later. I thought the "truth" p

Re: slices

On Thu, 24 May 2001 22:19:12 -0400, James Mastros wrote: >But what about: @foo[(1,2,3)]? > >Are those parens a list-maker, or are they a scalar expression using >the comma operator. Both. But in this case, I'd say: it depends on the context the slice is called in. @bar = @foo[(1,2,3)]

Re: PDD 2nd go: Conventions and Guidelines for Perl Source Code

On Tue, 29 May 2001 18:25:45 +0100 (BST), Dave Mitchell wrote: >diffs: > >-"K&R" style for indenting control constructs >+"K&R" style for indenting control constructs: ie the closing C<}> should >+line up with the opening C etc. On Wed, 30 May 2001 10:37:06 -0400, Dan Sugalski wrote: >I realize

Re: Should we care much about this Unicode-ish criticism?

On 05 Jun 2001 11:07:11 -0700, Russ Allbery wrote: >Particularly since part of his contention is that 16 bits isn't enough, >and I think all the widely used national character sets are no more than >16 bits, aren't they? It's not really important. UTF-8 is NOT limited to 16 bits (3 bytes). With

  1   2   3   4   >