Re: RFC 138 (v1) Eliminate =~ operator.

> > eq and ne are far more confusing. > > Hm. I've never had problems with this, although it does confuse me to go > back to the shell's [ ] (aka test) and have them be backwards. Yeah, I've got them finally sorted out, it only took me about 5 years... ;-P > >if ( $x == m/stuff/ ) { ... } >

Are Perl6 threads preemptive or cooperative?

Are Perl6 threads preemptive or cooperative? Last week, I asked whether Perl6 threads support SMP. There were a handful of responses, mostly to the effect that - we don't know - we don't care - we get whatever the native thread library gives us This assumes that Perl6 uses the native thread lib

Re: RFC 138 (v1) Eliminate =~ operator.

Nathan Torkington wrote: > > Nathan Wiger writes: > >$x =~ /a/; # $x is roughly equivalent to a > > I've been going at high speed through this thread, but has > anyone mentioned: > > m{$foo}{^baz.*bar$}i > s{$foo}{(\w+) \1}{$1}g > > With the first part of m{} and s{} containing an ex

User-defined quoting operators

A while ago on p5p Joseph Hall allowed as how he would like to have core support for SQL via a construct like qs/SELECT * FROM s_emp WHERE empno IN (101, 343, 573)/ I suggested that one would need to know what database handle it was acting on, and that what made sense (to me) was to ov

Re: RFC 138 (v1) Eliminate =~ operator.

Nathan Wiger writes: >$x =~ /a/; # $x is roughly equivalent to a I've been going at high speed through this thread, but has anyone mentioned: m{$foo}{^baz.*bar$}i s{$foo}{(\w+) \1}{$1}g With the first part of m{} and s{} containing an expression. We lose !~ there, though. Thoughts o

New variable type: matrix

I am little bit confused and probably very ignorant but one thing seems to me very useful. Why doesn't perl support a new data type matrix. If perl wants to become a real "programming language" not just a scripting language it should support number crunching internally in a more intuitive way. I d

Re: RFC 111 (v1) Whitespace and Here Docs

> I was sorta going under the assumption that <<< would cause leading and > trailing whitespace to be ignored (not stripped) when looking for the > end-of-here-doc indicator. Because whitespace is ignored, I was then > proposing some new syntax for stripping whatever one likes from the contents >

Re: How to facilitate ports to other bytecode architectures (was Re: .NET IL)

At 06:24 PM 8/24/00 -0400, Bradley M. Kuhn wrote: >Dan Sugalski wrote: > > Having a solid and correct reference doc for the output bytecode is > > probably the single most helpful thing we can do for folks writing things > > that munch the bytecode. > >Actually, I don't think that munching Perl by

Re: RFC 146 (v1) Remove socket functions from core

Dan Sugalski writes: > One of the current plans is for the parser to have access to a list of > functions that trigger autoloading modules. Isn't dynamic loading really slow? If they're going to incur the penalty of dynamic loading, you might as make them request that slowdown by 'use'ing the m

Re: RFC 146 (v1) Remove socket functions from core

At 03:34 PM 8/24/00 -0600, Tom Christiansen wrote: > >I have several RFCs I need to write about removing certain functionality > >out of the core (math functions, IPC, networking, "user"). I don't want to > >go too overboard. I don't know that we want to go so far as to remove > >printing and su

Re: RFC 111 (v1) Whitespace and Here Docs

>Unfortunately the quoting on the terminator following << decides the type >of interpolation; we're missing a way of indicating how to recognize the >terminator other than an exact match. If we say that we want varia

Re: Episode 4 - A New Version

Ok, time to head back to planet Earth and the story of perl6. Back to the grindstone! Nat (party pooper)

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

Bart Lateur writes: > Oh. I would have put my hopes on a better (= more generic) O::Deparse > mechanism to make Perl analyse the source code for you. Rewriting a Perl > in a module seems a bit silly to me. I don't know enough swear words to say how much I fucking hate the stupid braindead dumbfuc

Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

> OK here is a basic question: how do we specify element access in > PDL type arrays? > > $a[$i][$j][$k] or $a[$i,$j,$k] Both of these already have firm meaning in Perl. The second one is used to bite off selected elements of an array. So if you want a different syntax you'll have to use some ot

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

Dan Sugalski writes: > Personally I think I'm in favor of Nat's suggestion of allowing the > definition of new infix operators and let this be taken care of in a > module, but that's just passing the buck. (Not that it's a bad strategy, > mind... :) Solve the generic problem, not a specific on

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

Tom Christiansen wrote: > > Perl already does the sanity check for you: "can't call method > without package or reference". What you're saying requires the > programmer to diddle about, which is never a win. I'll concede that point, with the counter that it lets you get exactly what you want. C

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

On Thu, 24 Aug 2000, Nathan Torkington wrote: > You'd obviously want to have a module that collected together your > favourite new operators. But if they were lexically scoped, they'd > be lexically scoped to the module they were defined in, i.e. your > collection rather than your main program.

Re: Structured exception handling should be a core module.

At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote: >Peter Scott wrote: > > > > At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote: > > > > > >In fact, not only would I be pleased and honoured to author the > > >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard > > >reference implementatio

Re: Structured exception handling should be a core module.

Peter Scott wrote: > > At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote: > > > >In fact, not only would I be pleased and honoured to author the > >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard > >reference implementation. > > >Peter, I think we should make this approach more c

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 05:24:14PM -0700, Peter Scott wrote: > At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: > >But you don't need that when you can and possibly should just write this: > > > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > > Others may be focussing on th

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

At 01:32 AM 8/25/00 +0200, Bart Lateur wrote: >On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote: > >Yes, this is losing information; the former $! is no longer around. I > >contend that it's eliding functionality that is seldom, if ever, used, in > >favor of a natural simplification. There'

Re: Structured exception handling should be a core module.

At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote: >In fact, not only would I be pleased and honoured to author the >Perl 6 core Try.pm module, I'm already working on a Perl 5 standard >reference implementation. That should certainly tell you whether it's doable :-) >Peter, I think we should make th

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 05:41:00PM -0600, Tom Christiansen wrote: > But you don't need that when you can and possibly should just write this: > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > | Attention criminal slacker, we have yet > | to receive payment for our legal services.

Re: RFC 111 (v1) Whitespace and Here Docs

At 05:41 PM 8/24/00 -0600, Tom Christiansen wrote: >But you don't need that when you can and possibly should just write this: > > print <<"EOF" =~ /^\s*\| ?(.*\n)/g; > | Attention criminal slacker, we have yet > | to receive payment for our legal s

Re: On the case for exception-based error handling.

Glenn Linderman wrote: > > Tony Olekshy wrote: > > > > Glenn Linderman wrote: > > > > > > actually wrapping a bunch of code inside a try block > > > affects how that code reacts to die, thus affecting the > > > behavior of the program that previously used die to mean > > > terminate the program.

Structured exception handling should be a core module.

Graham Barr wrote: > Peter Scott wrote: > > Tony Olekshy wrote: > > > Graham Barr wrote: > > > > > > > > I am of the opinion that only a class name should follow > > > > catch. If someone wants to catch based on an expression > > > > they should use > > > > > > > > catch { > > > > if () { >

Re: On the case for exception-based error handling.

Peter Scott wrote: > > Tony Olekshy wrote: > > > > I just don't think that with with respect to the infrastructure > > mechanism per se, "fatality" should have anything to do with it. > > In the end, that's a judgement call; that's what we get paid the > > big bux for ;-) > > I have reservations a

Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit assignment

> "JM" == James Mastros <[EMAIL PROTECTED]> writes: JM> If those two paragraps (and the two after them) are replaced with < what's still wrong with the RFC? JM> Therefore, return values of lvalue subs stay as their final GV, which is JM> passed into the assignment, and is then assigned to the

Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Can be called as any of these forms by default: NW>$old = assign($var, $val); NW>$old = assign($var) = $val; NW>$old = assign = $var, $val; NW> Make sense? This RFC doesn't address true lvalue subs, rather that NW> rvalue su

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

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >> But >> >> ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) >> >> Actually, looking at it like that makes it an ugly situation. The 'new' >> expectation would be to have it

Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors

> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >> But the drawback would be that the actual victim may not be the primal >> cause. >> >> sub foo { >> my $fh = open(); >> ... Lots more code ... >> return $fh; >> } >> >> $victim = foo; >> print $victim "I'm helpless"; JH> Tough.

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

On 24 Aug 2000 15:53:42 -, Perl6 RFC Librarian wrote: >Everyone on this list should be familiar with the problem. You can't >tell scalars and references apart by looking at them. They are >completely ambiguous. Consider: > > $stuff{key} # hash value > $stuff[0]# array value

Re: RFC 111 (v1) Whitespace and Here Docs

>Basically, it's shorthand for the current syntax: >$message = <<"EOF" =~ s/^\s*\| ?//g; >| Attention criminal slacker, we have yet >| to receive payment for our legal services. >| >| Love and kisses >| >EOF >print $message; >But any i

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 05:26:36PM -0600, Tom Christiansen wrote: > >I thought this problem would've been neatly solved by my proposed: > > >print <<<"FOO" =~ s/^ {8}//; > >Attention criminal slacker, we have yet > >to receive payment for our legal services. > > >

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

On Thu, 24 Aug 2000 13:50:56 -0700, Peter Scott wrote: >>But $@ is an entirley different beast. >The proposal is that $! would be overwritten with the die string. Reason: >whoever's interested in both $@ and $! at the end of an eval? There was an >error; everyone looks at $@, which almost c

Re: RFC 111 (v1) Whitespace and Here Docs

>I thought this problem would've been neatly solved by my proposed: >print <<<"FOO" =~ s/^ {8}//; >Attention criminal slacker, we have yet >to receive payment for our legal services. >Love and kisses >FOO The result of substituting the leading 8 bla

Re: RFC 111 (v1) Whitespace and Here Docs

>Today around 4:30pm, Tom Christiansen hammered out this masterpiece: >: print print <<" FOO" =~ /^\s+(.*\n)/gm; >Unless, of course, you want `xx oo' to be indented still, and the blank >remain. That r

Re: RFC 111 (v1) Whitespace and Here Docs

On Thu, Aug 24, 2000 at 06:14:10PM -0400, Michael G Schwern wrote: > Paragraphs. > > sub legal { > print << Attention criminal slacker, we have yet > to receive payment for our legal services. > > Love and kisses > FOO > } > > Obvi

Re: RFC 111 (v1) Whitespace and Here Docs

Today around 4:30pm, Tom Christiansen hammered out this masterpiece: : print <'[EMAIL PROTECTED]',site=> 'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n"; print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig}; my $VERSION = '0.01'; #'patche

Re: 122 (v1): types and structures

[I am not subscribed to the perl6-language-data list, so I would appreciate it if responses are CC'd to me.] On Thu, Aug 24, 2000 at 08:45:50AM -0700, Nathan Wiger wrote: > How is RFC 122 different from RFC 15? Seems like they accomplish a > similar thing but RFC 15 is a much more Perlish approac

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

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

Re: RFC 111 (v1) Whitespace and Here Docs

At 04:30 PM 8/24/00 -0600, Tom Christiansen wrote: > >I'm coming into this a bit late, so forgive me if this is impossible or > >already dismissed, but what about > > > print < > Attention, dropsied weasel, we are > > launching our team of legal beagles > >

Re: RFC 146 (v1) Remove socket functions from core

>Perhaps it would be better to have Perl support all of perlfunc(1) in the >core still, but allow users to turn subsets off? >Or, perhaps the core functions could be syntactic sugar for access to >modules, and have a transformation happen automagically in the parser? (My >gut says "here there be

Re: RFC 111 (v1) Whitespace and Here Docs

>I'm coming into this a bit late, so forgive me if this is impossible or >already dismissed, but what about > print < Attention, dropsied weasel, we are > launching our team of legal beagles > straight for your scrofulous crotch. >

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

>However, consider this in a different light for a moment: > $a = "MyClass"; > *a = MyClass->generate; # ask for ref back > $a->blah; > *a->blah; # use our ref >Whether or not having to care about your refs is good or bad depends on >which way you look at it. In one cas

Re: RFC 146 (v1) Remove socket functions from core

> >I admire micro-kernel-type systems. C and Java give you no functions out of > >the box. Keywords are just that, keywords. I believe python is like this > >as well. The idea being that everything has to come from a module.. This > >limits how much a new developer has to learn, and it doesn'

Re: RFC 111 (v1) Whitespace and Here Docs

At 06:14 PM 8/24/00 -0400, Michael G Schwern wrote: >Okay, devil's advocate. > >Paragraphs. > > sub legal { > print << Attention criminal slacker, we have yet > to receive payment for our legal services. > > Love and kisses > FOO > }

How to facilitate ports to other bytecode architectures (was Re: .NET IL)

bkuhn wrote: > >I *think* that the consensus is that we should make it easy for people who > >want to port to the JVM, or the so-called ".NET Implementation Language". > >As the JVM porter, I'd like my life easy, but I don't expect perl6 to hand > >me a JVM implementation---I just want to right co

Re: RFC 111 (v1) Whitespace and Here Docs

Okay, devil's advocate. Paragraphs. sub legal { print <

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

Tom Christiansen wrote: > > You pretend that a reference is not a "true" scalar. > That's certainly not valid. It obviously is. Well, this is a matter of semantics, pure and simple. Technically, it is. But I would argue that cognitively it is not by any means. Especially if a reference points t

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

Tom Christiansen wrote: > > So it seems that what you're saying is that you'd like a way to > *know* for certain whether you were invoked as a method -- or not, > as the case might be. Sort of. Actually, I want to not care. Adding a :method constraint doesn't help (actually hurts) because then t

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

At 02:09 PM 8/24/00 -0400, John Porter wrote: >Markus Peter wrote: > > > > Another possibility would be to use cmpi and eqi > >Actually, all we need is cmpi, since eqi is just !cmpi. >(And eq is !cmp.) Nope. Read the manual. --- Ma

Re: RFC 157 (v1) Delete C and C commands.

On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote: > The C and C commands are legacy commands which have been > deprecated for at least 5 years. They should be removed from the language. Two nit picks. First, dbmopen() isn't deprecated. [This function has been largely sup

Re: RFC 155 - Remove geometric functions from core

>A friend pointed out, technically most are trigonometric functions, >not geometric. atan2, cos, sin, acos, asin and tan are all trig. >exp, log, sqrt are... just math I guess. >So I suppose the proposed module would be Math::Trig or some such. Or >maybe, as the source code suggests, Math::High

Re: RFC 155 - Remove geometric functions from core

A friend pointed out, technically most are trigonometric functions, not geometric. atan2, cos, sin, acos, asin and tan are all trig. exp, log, sqrt are... just math I guess. So I suppose the proposed module would be Math::Trig or some such. Or maybe, as the source code suggests, Math::High:Falu

Re: RFC 146 (v1) Remove socket functions from core

>I have several RFCs I need to write about removing certain functionality >out of the core (math functions, IPC, networking, "user"). I don't want to >go too overboard. I don't know that we want to go so far as to remove >printing and such. It might be nice to generalize some functions (like th

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

>It's a pain if you want to support both function-oriented and >object-oriented calling forms, as CGI.pm does. For example, you can use >both of these: > print header; > print $r->header; >with CGI.pm. Now you need a self_of_default special method, since >sometimes $_[0] has a class ref and

Re: RFC 146 (v1) Remove socket functions from core

Lightning flashed, thunder crashed and "Michael Maraist" whispered: | >From this, socket, and virtually all IPC methods should go the wayside. | This includes pipes, shell environment ops ( the get and set functions ), | and even the file-io (open, close, and possibly even printf, sprintf). At |

Re: RFC 138 (v1) Eliminate =~ operator.

Nathan Wiger wrote: > > > : =~ has no real world equivalent, and in fact I don't know how to > > : pronounce it in English so that $x =~ /a/ makes sense. > > > > Yes, that's all pretty much on the mark. > > Not true, IMO. In math, =~ is used to indicate "rough equivalence". > (Actually, the ~ go

Episode 4 - A New Version

Dan Sugalski <[EMAIL PROTECTED]> writes: > I'm picturing a WAP-enabled cellular furbie with > an R2D2-style projector thingie for the video. > It's not a pretty sight... "Help us Lawrence Wall, you're our only hope..." bzzp! "Help us Lawrence Wall, you're our only hope..." bzzp! "Help us Lawr

Re: RFC 145 (v1) Brace-matching for Perl Regular Expressions

One thing I'd like to see is being able to specify qr//d regexes or list (refs) within this, to be able to give multiple equivlent objects. For example, the list ("<<" => ">>", "\N{left gimmulet}" => "\N{right gimmulet}") would allow << to match >> and « to match ». However, (["<<", "\N{left gim

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

> "Nathan" == Nathan Wiger <[EMAIL PROTECTED]> writes: Nathan> The key difference is this: $_[0] always contains the first method Nathan> argument, regardless of whether you're in an object-oriented or Nathan> function-oriented context. So, if you need to support both (like CGI.pm Nathan> and

Re: RFC 156 (v1) Replace first match function (C) with a flag to the match command.

Bart Lateur wrote: > > And, what's so special about the first match? What if I want the second > match, or the third? (/foo/g)[2] ??? -- John Porter We're building the house of the future together.

Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit assignment

From: "Chaim Frenkel" <[EMAIL PROTECTED]> Sent: Thursday, August 24, 2000 2:42 PM Subject: Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit assignment PRL> Therefore, the definition of the return function must be changed PRL> such that it is lazy. PRL> Additionally, the definition of

Re: RFC 156 (v1) Replace first match function (C) with a flag to the match command.

On 24 Aug 2000 20:29:21 -, Perl6 RFC Librarian wrote: >Replace first match function (C) with a flag to the match command. Sounds reasonable. I propose "1". ?foo? becomes /foo/1 Eh, no, that looks silly. And, what's so special about the first match? What i

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

At 10:37 PM 8/24/00 +0200, Bart Lateur wrote: >On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote: > > >Merge C<$!>, C<$^E>, and C<$@> > >Merging $! and $^E makes perfect sense to me. I don't know why there are >two different error variables. $! eq "No such file or directory"; $^E eq "CD-R

Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

On 24 Aug 2000 20:24:52 -, Perl6 RFC Librarian wrote: >Damian Conway's Text::Balanced module does a pretty good job of >tokenizing Perl code. However, bare C and C require >semantic analyis to distinguish them from division and the hook >(C) operator. > >To remove this hassle, and thus permi

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

On Thu, 24 Aug 2000 13:27:01 -0700, Nathan Wiger wrote: >It's a pain if you want to support both function-oriented and >object-oriented calling forms, as CGI.pm does. For example, you can use >both of these: > > print header; > print $r->header; > >with CGI.pm. Now you need a self_of_default

Re: RFC 145 (v1) Brace-matching for Perl Regular Expressions

- Original Message - From: "Eric Roode" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 24, 2000 1:56 PM Subject: Re: RFC 145 (v1) Brace-matching for Perl Regular Expressions > Well, if we stick to the model of a lowercase/uppercase pair > for this proposed feature,

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

Bart Lateur wrote: > > Suppose you want to keep the case on the hash keys, because you > enumerate them. But you still want to find hash entries in a case > insensitive manner... ...then you simply reach for Tie::CPHash on CPAN! -- John Porter

Re: RFC 93 (v2) Regex: Support for incremental pattern matching

Damian Conway <[EMAIL PROTECTED]>: > > It is proposed that the Perl 6 regular expression engine be extended to > allow a regex to match against an incremental character source, rather than > only against a fixed string. > > Specifically, it is proposed that a subroutine reference could be bound

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

On 24 Aug 2000 16:03:56 -, Perl6 RFC Librarian wrote: >Merge C<$!>, C<$^E>, and C<$@> Merging $! and $^E makes perfect sense to me. I don't know why there are two different error variables. Er... wasn't that three? I'm not absolutely certain, but I thought there was a third one, too. Oh yes

Re: RFC 155 (v1) Remove geometric functions from core

On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Remove geometric functions from core > > =head1 VERSION > > Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> > Date: Aug

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

Hildo Biersma wrote: > > > =head1 TITLE > > > > Replace $self in @_ with self() builtin (not $ME) > > > > Don't impose your religion on others. If people want 'this' instead of > 'self', that should be just fine. Whoa! I'm not imposing religion on others. FAR FROM IT! Maybe the examples I demo

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

On Thu, Aug 24, 2000 at 10:28:51PM +0200, Bart Lateur wrote: > On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: > > >Perl currently only has C and C operators which work case-sensitively. > >It would be a useful addition to add case-insensitive equivalents. > > Next you'll want case)ins

RFC 156 (v1) Replace first match function (C) with a flag to the match command.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Replace first match function (C) with a flag to the match command. =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Num

RFC 157 (v1) Delete C and C commands.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Delete C and C commands. =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 157 =head1 ABSTRACT The C and C com

RFC 155 (v1) Remove geometric functions from core

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Remove geometric functions from core =head1 VERSION Maintainer: Stephen P. Potter <[EMAIL PROTECTED]> Date: Aug 24 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 155 =head1 ABSTRACT Mov

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

On 24 Aug 2000 15:40:00 -, Perl6 RFC Librarian wrote: >Perl currently only has C and C operators which work case-sensitively. >It would be a useful addition to add case-insensitive equivalents. Next you'll want case)insensitive hashes! Er... actually, that sounds rather useful, even more tha

Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)

Tom Christiansen wrote: > > It is? I don't see that this is a pain at all. It seems like > a beautiful point of homogenization. You don't force the user > to say $self; they could use $this if they wanted. Heck, they > don't need it at all. > > my(undef, @args) = @_; It's a pain if you

RFC 93 (v2) Regex: Support for incremental pattern matching

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Regex: Support for incremental pattern matching =head1 VERSION Maintainer: Damian Conway <[EMAIL PROTECTED]> Date: 11 August 2000 Last Modified: 24 August 2000 Version: 2 Mailing List: [EMAIL PROT

RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: August 20, 2000 Last Modified: August 24, 2000 Version: 2 M

Re: Why "fatal" errors aren't special.

Peter Scott wrote: > At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote: > >By building up a > >non-fatal error handling technique on top the existing fatal error > >handling technique, you are forcing code that assumes it will die to > >behave differently, when you wrap a try block around it. Now

Re: RFC 153 (v1) New pragma 'autoloader' to load modules on-demand

Tom Christiansen wrote: > > >A main goal for Perl 6 is to make it faster, more compact, and lighter > >weight. This means moving lots of former core functions into modules. > > Andy D once posted something showing empirical evidence > that this hypothesis is in fact *FALSE*. Ok. Perhaps I shoul

Re: OT: pronouncing "www" (was: Re: ... as a term)

Thus it was written in the epistle of Austin Hastings, > "foo.bar" ne "www.foo.bar" > > pronounce("foo.bar") eq pronounce("www.foo.bar") > > As in, "Surf to www.perl.org and read the new ..." > > sounds like > > "Surf to perl dot org and read the new ..." > > =Austin Just to be absolutely ce

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

Chaim Frenkel wrote: > ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) > > Actually, looking at it like that makes it an ugly situation. The 'new' > expectation would be to have it become > # $foo=1 $baz=2 @bar=(4) Actually? How about it becoming

Re: WAP-enabled cellular furbie

On Thu, Aug 24, 2000 at 03:49:01PM -0400, [EMAIL PROTECTED] wrote: > At 07:28 PM 8/24/00 +, Nick Ing-Simmons wrote: > >When a Palm "is" a WAP Phone it will have one, and while Teddy Bears may > >not I am sure Furbie-II will... > > I'm picturing a WAP-enabled cellular furbie with an R2D2-style

Re: 122 (v1): types and structures

David Corbin wrote: > > "int" and "float", vary greatly per > machine, though I believe ALL the numeric types can vary from one > machine to another. not _SPECIFYING_ just DECLARING. I imagine we'd default to "use native" for the internals of what the types meant, but "use java" would be one

Re: OT: pronouncing "www" (was: Re: ... as a term)

"foo.bar" ne "www.foo.bar" pronounce("foo.bar") eq pronounce("www.foo.bar") As in, "Surf to www.perl.org and read the new ..." sounds like "Surf to perl dot org and read the new ..." =Austin --- Tom Christiansen <[EMAIL PROTECTED]> wrote: > >The "www" in e.g., "www.netscape.com" is pronounce

Re: 122 (v1): types and structures

Tom Christiansen wrote: > > >Tom Christiansen wrote: > > >> C type declarations are pretty universally despised. > > >By whom? > > >This is news to me. I have always thought that the C type declaration > >is a concise and platform-independent way of declaring a packed > >structure, and effect

Re: RFC 146 (v1) Remove socket functions from core

At 07:28 PM 8/24/00 +, Nick Ing-Simmons wrote: >Dan Sugalski <[EMAIL PROTECTED]> writes: > > > >*) It makes optionalizing (now there's a good word... :) the functions > >easier for platforms that just don't have 'em. Like, say, the Palm, or > >embedded gadgets. (Most teddy bears aren't likely

Examples from RFC 88 redone using RFC 119 facilities [Was: Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism]

Tony, Having done the exercise of redoing all your RFC 88 examples into RFC 119 syntax, I conclude that the two biggest differences between the syntaxes is the explicit or implicit try, which is mostly an irrelevant placeholder; some like it, some don't. The biggest syntax simplifications came i

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

Dan Sugalski <[EMAIL PROTECTED]> writes: >At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >>But >> >>($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) >> >>Actually, looking at it like that makes it an ugly situation. The 'new' >>expectation would be to have it become >>

Re: RFC 146 (v1) Remove socket functions from core

Dan Sugalski <[EMAIL PROTECTED]> writes: > >*) It makes optionalizing (now there's a good word... :) the functions >easier for platforms that just don't have 'em. Like, say, the Palm, or >embedded gadgets. (Most teddy bears aren't likely to come with a network >stack...) Most everything will h

Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like "with" or "express"

> "Bart" == Bart Lateur <[EMAIL PROTECTED]> writes: Bart> On Tue, 22 Aug 2000 00:03:48 -0600 (MDT), Nathan Torkington wrote: >> Normally what you'd say is: >> >> with (%record) { >> >> } >> >> (look at me, using Larry's new ... operator :-) Bart> No you didn't. You typed four dots. T

Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default

Chaim Frenkel wrote: > > Why this limitation? > > If the lvalue is a fundemental type (whatever that is) everything works > as if the lvalue were actually in place > > sub foo { return $a } > foo =~ s///;# same as $a =~ s///; This is not the type of lvalue sub that th

Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default

> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> The key to the proposal is this: lvalue and rvalue versions of a sub PRL> would work I, and both would be enabled by default. PRL> I, assignment is the only valid operator for these default PRL> lvalue subs. Attempts to use other

Re: 142 (v1): Enhanced Pack/Unpack

Tom Christiansen wrote: > printf "uid %d logged on from %s on %s.\n", > $him->ut_uid, $him->ut_host, scalar local $him->ut_date; > > Is ut_uid a scaler value here? It occured to me when I read this that it would be nice to get rid of the distinction between $him->{ut_uid} $him->[ut

Re: Exception handling [Was: Re: Things to remove]

"BSOD" => huh? Oh, Blue Screen of Death. Certainly if the OS doesn't support trapping an error, then the language running on it cannot either. But if the OS does, then the language could. If the language could, then the question remains whether it should, and that's a -language topic that hasn

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

At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: >But > >($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) > >Actually, looking at it like that makes it an ugly situation. The 'new' >expectation would be to have it become > # $foo=1 $baz=2 @bar=(4) Woul

  1   2   3   >