> I just want to hit this point a little more, to make sure we're actually
> in agreement.
Ok, ok... sorry about this. I've been hammering away at a stubborn gray area
and now I'm seeing that "duh!" it's all right there. Yes, of course 'int'
would be a subclass of Scalar. You know, it's silly...
Jeremy Howard wrote:
> Basically, I want to be able to create a list ref of list refs, specify a
> data type (eg 'int') and attributes of ':compact' or ':sparse', and have the
As Dan Sugalski suggested it seems not a good idea to bring in the list
of list ref into the proposal. Why does it have
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
> Peter Scott wrote:
> >Graham Barr once allowed as how he thought it would be neat if you could say
> >
> > for my($x, $y, $z) (@list) { ... }
>
> ObLanguageMinimalist:
>
> Um. Is this so frequently-used that the above syntax is pr
Buddha Buck wrote:
> > I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> > the sounds of it), and make current arrays a little more flexible. It
> > sounds like we'll just have to add an extra dimension somehow, and then
> > "arrays of compact arrays" will simply be "arrays
> I think the better way is to take Buddha's idea (soon to be RFC'ed, by
> the sounds of it), and make current arrays a little more flexible. It
> sounds like we'll just have to add an extra dimension somehow, and then
> "arrays of compact arrays" will simply be "arrays with some compact
> elemen
Christian Soeller wrote:
>
> The other problem with arrays is: how do we deal with functions that
> take multiple piddle arguments if they are arrays:
>
>@result = integrate @x, @y, @bounds;
>
> Won't those all be clumped into one big input array?
This should be overrideable by prototypes.
Doug Hunt wrote:
>
> What I meant to say (but failed, alas) was that I support the idea for a
> new perl variable type called compact array:
>
> $foo -- scalar
> @foo -- array
> %foo -- hash
> ^foo -- compact array (or whatever notation)
>
> Given this notation, you could have hashes of compa
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > So if open, for example, can set $! without invoking die, then
> > $! and $@ must not be merged. As I read it, 151 would (as
> > currently promulgated) not meet my requirement for the unique
> > nature of a $@-style variable. I don't think ov
This is a bit limiting.
I'd offer a more flexible approach. We should be able to represent
any packed structure. We should be able to handle anything that an
pack/unpack format can currently handle. Except that the data does
not have to be moved out into an array/hash.
This might fit in with t
"Randy J. Ray" wrote:
>
> ># These are pretty cool...
> >foreach (@old) { @new = subst /hello/X/gi, @old;
> > s/hello/X/gi;
> > push @new, $_;
> >}
> >
> This implies that the subst keyword would *both* modify LIST in-place and
> return a complete copy of t
First of all, apologies for my lack of input over the last
week--unfortunately I went on holidays pretty much as this list went online,
so I've been pretty quiet. Anyhow, for those who don't know me, I'm the
chair of perl6-language-data. For the remainder of its existance I'll be
more active.
Thi
Steve Fink wrote:
>
> But then what does my $x = BlueFoo->new(); print
> "$x" do, assuming there is a BlueFoo::STRINGIFY? Print
> "BlueFoo=HASH(0x0b38134)"?
The current thinking it to preserve the default behavior, which would be
to print out the ref info, UNLESS there is a STRING function. That
Matt Youell wrote:
>
> Originally I was trying to avoid explicit typing through new keywords, like
> 'int'. So the latter option would have been the case. But after Nathan
> Wiger's reply to my RFC, I realized that either syntax would work. Under one
> scenario, 'int', as in your example, would si
The way people seem to be showing the status of RFCs is by putting
"Status: foo" up near the maintainer info etc. This makes good sense.
Can this be reflected in the sample RFC and the instructions and so on?
K.
- Forwarded message from Peter Scott <[EMAIL PROTECTED]> -
>From: Peter Sc
At 12:16 PM 8/27/00 -0400, Bennett Todd wrote:
> > The ramifications of some of these things are sufficiently
> > important that drawing attention to them might be a good thing.
> > In this case, note that Perl 6 will need to spell out which core
> > exceptions are by default fatal (eg, :arithmeti
Make your suggestions. But I think it is all off-base. None of this is
addressing some improvement in working conditions, ease of use, problems
in the language, etc.
You are addressing stylistic issues. Issues that effect the way _I_ want
to work with the language. All of you are being fascist.
At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> > If $@ and $! are merged, then in code like
> >
> > try {
> > system_call_that_fails();
> > more_stuff_that_succeeds();
> > }
> > finally {
> > }
> >
> > does
Karl Glazebrook wrote:
>
> Consider
>
> @x[10:20, 20:40:2, 30:50]
>
> This ALMOST works in the current Perl. @x gives array context,
> then the , produces a list.
I see a number of problems with the current (scalar) PDL objects being
turned (essentially) into perl arrays in perl6.
1) How do y
Tom Christiansen wrote:
> Hm I don't recall C++ ever thinking to overload the control-flow
> operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
> Even if their "a && b" should produce a more mundane 1 or 0, one
> still might wish control.
>
'&&', '||', et al are just operato
At 10:13 AM 8/25/00 +0200, Bart Lateur wrote:
>You're citing my objection for merging in $@ with the rest of the error
>variables. $@ currently is the "eval failed" flag, irrespective of what
>else failed. We *must* have such a flag. If $@ and $! would be merged,
>$! will have to be cleared if the
Chaim Frenkel wrote:
>
> > "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
>
> DLN> What if every subroutine tagged itself with a list of the globals
> DLN> it uses, so a calling routine would know to add those to the list
> DLN> of globals it wants locked?
>
> And what about all the sub
Tom Christiansen wrote:
>
> But if *MOST* perl1 .. perl5 programs aren't going to work unchanged,
> that means that most people's existing perl knowledge-base will no
> longer be valid. That probably means that they aren't going to be
> able to just type in the Perl that they already know, either
>But for style, I don't see why
>the interpreter can't also check for various non-obscure syntaxes / styles.
(You mean "compiler", not interpreter.)
You have to be quite careful there: Perl is so humungous that what's
obscure to one person is well-known to the next. For example, $#foo
is vergin
Tom Christiansen writes:
> if you truly must--are important things. If the perl6:perl5
> relationship is similar in breadth to what we saw in the perl5:perl4
> one, then perhaps, maybe even probably, one will get away with it.
> However, if the stretch is appreciably further, I don't think one
>
>The compatibility path for perl5 to perl6 is via a translator. It
>is not expected that perl6 will run perl5 programs unchanged. The
>complexity of the translator and the depth of the changes will be
>decided by the decisions Larry makes.
This becomes not merely
"It is not expected that perl
> > ^foo -- compact array (or whatever notation)
>
> I seem to remember that ^ was in the process of being highjacked by some
> other RFC already. Was it higher-order functions?
Yes: RFC 23 (v4): Higher order functions
Damian
Michael Maraist writes:
> Compatibility is going to have to be maintained somehow. And we can either
> have some sort of perl6 designator (such as the pragma) to designate
> incompatible (and otherwise ambiguous) code, or we're going to have to
> continue tacking on syntactic sugar to legacy code
Doug Hunt wrote:
> What I meant to say (but failed, alas) was that I support the idea for a
> new perl variable type called compact array:
>
> $foo -- scalar
> @foo -- array
> %foo -- hash
> ^foo -- compact array (or whatever notation)
I seem to remember that ^ was in the process of being hig
Hildo Biersma writes:
> Hold on - post conditions are not intended to veto a change, they're
> intended to terminate the program if an assertion is invalid. Hence it
> should not matter if they run before or after assignment.
>
> Given that the assertion should be "now this and that should be tr
> >Simple solution.
>
> >If you want to require formats such as m/.../ (which I actually think is
a
> >good idea), then make it part of -w, -W, -ww, or -WW, which would be a
perl6
> >enhancement of strictness.
>
> That's like having "use strict" enable mandatory perlstyle compliance
> checks, an
> > 1. Return the number of matches
> >
> > 2. Iterate over each match in sequence
> >
> > 3. Return list of all matches
> >
> > 4. Return a list of backreferences
>
> Please see RFC 164. It can handle all of 1-3.
You seem to have missed my point. I'm not ask
> Drawing on some of the proposals for extended 'for' syntax:
> for my($mo, $dy, $yr) ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
> ...
> }
>
> This still requires that you know how many () matching groups are in
> the RE, of course. I don't think I would consider that onerous.
If ther rege
On Mon, Aug 28, 2000 at 06:05:03PM -0400, Mark-Jason Dominus wrote:
> # WRONG
> while (($mo, $dy, $yr) = ($string =~ /\d\d-\d\d-\d\d/g)) {
> ...
> }
I assume you mean:
while (($mo, $dy, $yr) = ($string =~ /(\d\d)-(\d\d)-(\d\d)/g)) {
...
}
Drawing on some
Christian: You are right, it would not be best to confuse normal perl
lists with compact arrays--they both have their purposes and can be
combined usefully.
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo
>I can currently overload + < > * to do this, but not &&. That's broken.
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a && b" should produce a more mundane 1 or 0, one
still might wish contr
Tom Christiansen wrote:
>
> How nice of you to put words in my mouth. Please cite me the precise
> message ID, date, and appropriate text in which I said "we can't
> change anything because of precedent".
First off, I wasn't trying to insult you, or push a hot button, or
suggest we should destro
> What about
>
> sub somename : method (@args) {...}
>
> And leaving your$self some other way at the object?
That's the idea. By default you get the invocant in $_[0],
but you can have the compiler extract it for you via C.
Then you get to choose your access mechanism (lexica
Mark-Jason Dominus wrote:
>
> > > $count = () = $string =~ /pattern/g;
> >
> > Which I find cute as a demonstration of the Perl's context concept,
> > but ugly as hell from usability viewpoint.
>
> I'd really like to see an RFC that looks into making the following
> features more orthogonal:
>Simple solution.
>If you want to require formats such as m/.../ (which I actually think is a
>good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6
>enhancement of strictness.
That's like having "use strict" enable mandatory perlstyle compliance
checks, and rejecting the
On Mon, Aug 28, 2000 at 01:30:41PM -0500, Jarkko Hietaniemi wrote:
> > $count = () = $string =~ /pattern/g;
>
> Which I find cute as a demonstration of the Perl's context concept,
> but ugly as hell from usability viewpoint. I how to assign to an
> empty list to get a number of something? H
Dan Sugalski wrote:
> If you want efficiency, n-dimensional arrays really need to be a concrete
> data type all of their own. That way one big block of memory can be
> allocated and, if it's a typed array, properly sized.
I wholeheartedly agree ;)
>
> That doesn't mean that n-dimensional array
> Just to extend this idea, at least for the exercise of it, consider:
>
>match; # all defaults (pattern is /\w+/?)
>match /pat/;# match $_
>match /pat/, $str; # match $str
>match /pat/, @strs; # match any of @strs
>
>subst; # like s///, pre
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> What if every subroutine tagged itself with a list of the globals
DLN> it uses, so a calling routine would know to add those to the list
DLN> of globals it wants locked?
And what about all the subroutines _it_ will call? And if you so
>I think they would *improve* readability. Certainly over $_[0], and
>even over:
> sub method {
> my ($self, @args) = @_;
> ...
> }
>I'm *forever* writing that and just it clutters up the code.
What about
sub somename : method (@args) {
...
What you want is a pre-condition on the overridden assignment operator.
What you want to do may involve having the suggested transactional
variables.
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Damian Conway writes:
>> pre mymethod : group("safe-coding practice") { @_ > 0
>Well, as I mentioned in another recent parallel thread, if C is to
>be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
--tom
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> However, I have given thought to allowing conditions to be grouped,
DC> and de-activated by group. This would probably meet your need.
>>
DC> pre mymethod : group("safe-coding practice") { @_ > 0 }
DC> pre mymethod : group("debugging")
> > $count = () = $string =~ /pattern/g;
>
> Which I find cute as a demonstration of the Perl's context concept,
> but ugly as hell from usability viewpoint.
I'd really like to see an RFC that looks into making the following
features more orthogonal:
1. Return the number of match
> I'm still in favor of moving the socket functions into Socket if for no
> other reason than it may help beat into people's heads that code like:
>
> eval 'require "sys/socket.ph"';
> eval 'sub SOCK_DGRAM {-f "/vmunix" ? 2 : 1;}' if $@;
>
> and
>
> $csock = pack('S n a4 x8', 2, 0,
Stephen P Potter <[EMAIL PROTECTED]> writes:
> At this point, should I go ahead and abandon the Math/Trig and/or
> Sockets ones?
I'm still in favor of moving the socket functions into Socket if for no
other reason than it may help beat into people's heads that code like:
eval 'require "sys/
> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
SF> Or what about a variable attribute:
SF> my $x : transactional
SF> and making the effect completely lexical? Why would other scopes need to
SF> see such variables?
You haven't handled the multiple variable variety. You will need to
able t
Doug Hunt wrote:
> But I would like to speak up in support of Baris' idea. I have long
> found it
> confusing (both to myself and to those I must explain my code to) the
> mix of
> pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
> appear to be scalars. I was even asked once
At 08:18 AM 8/29/00 +1200, Christian Soeller wrote:
>Dan Sugalski wrote:
> > That doesn't mean that n-dimensional arrays won't be just sugar over the
> > standard list-o-list structure to start, but they won't have to stay
> that way.
>
>That seems to be a possible route. Get multi-dim syntax for
I like a lot of what is in this RFC. It rings true for me, since my favorite CPAN
modules are OO. The less I need to learn about a package, the happier I tend to be.
Also, powerful objects tend to be slower (though it's getting better).
I haven't seen all of the discussion reguarding this RF
On Mon, 28 Aug 2000 14:43:08 -0400 (EDT), Eric Roode wrote:
>Damian Conway wrote:
>
>> @hash{grep /^[^_]/}
>>
>>gives you the public values of %hash.
>
>
>And the advantage of that over
>
>@hash{ grep /^[^_]/, keys %hash }
>
>would be what? Brevity?
What if I want those keys of %has
>>BTW, I have access to Rational Software's Quantify (and PureCoverage and
>>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests.
>
>If you want to get "in the mood" it would be good to fire it up on
>(say) perl5.6.0 and see where the hot-spots are.
Planning on it as part of
Lightning flashed, thunder crashed and Nick Ing-Simmons <[EMAIL PROTECTED]>
whispered:
| I think this is inappropriate for sin/cos/tan et. al. and possibly even
| sockets (although Win32 sockets are weird enough that it would be worthwhile)
|
| But for getpw* or shm/queue/msg or other may-not-b
On Mon, Aug 28, 2000 at 01:32:49PM -0700, Nathan Wiger wrote:
> We can pick self(). Or this(). Or me(). Or context(). Or invocant().
>
> Or $ME. Or $SELF. Or $THIS. Or $CONTEXT. Or $INVOCANT.
>
> But we have to f**king pick *something*!!!
I'll just wait for Rule #1 to be exercised, personally
Damian Conway wrote:
>
> I wouldn't be averse to C as the default and C as a sop to
> the Cerites and C<$ME>ophiles. But *they* might be!
This is baloney. I agree, we need to *pick something*!!
What should we do, make a "rename" pragma so everyone can be happy?
use rename want => '$NEED', && =
On Mon, Aug 28, 2000 at 04:04:20PM -0400, John Porter wrote:
> Well, I think it's likely that the perl6 parser would be made to
> handle this; but even if not, it shouldn't be too hard to get it
> to allow a ref to such a list:
>
> for [ $x, $y, $z ] ( @list ) { ...
I'm wondering how we ge
Damian Conway wrote:
> I have a draft RFC that proposes that the LIST argument of a
> grep be optional in a hash slice, and default to the key list
> of the sliced hash. So:
That's a waste of RFC paper, Damian. But let's generalize it a bit,
and say that Perl6 should have a standard intrinsic
Peter Scott wrote:
>Graham Barr once allowed as how he thought it would be neat if you could say
>
> for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
?
Damian Conway wrote:
>> I think it would be a good thing for user prototypes to be able to
>> handle this case and I wholeheartedly support the RFC; but it opens
>> a can of worms that should be addressed. Perhaps in another RFC. Do
>> any other (Damian) RFCs on (Damian) prototypin
On 8/28/00 3:53 PM, Damian Conway wrote:
>> Too much B&D for a Monday?
>
> No. I *do* have sympathy with the desire for One True Way, but *only* if the
> access function is called C (my own religion ;-).
>
> And *that's* the problem.
Yeah, there'll never be consensus on this list or in the comm
Peter Scott wrote:
>
> for my($x, $y, $z) (@list) { ... }
> ...
> IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
> was could say whether this construct would really give the parser problems
> or whether looking ahead for the block will disambiguate.
Well, I t
Tom Christiansen <[EMAIL PROTECTED]> writes:
>
>Explain why things like #ifdef HAS_SETLOCALE are not sufficient for
>this stated purpose.
Because the source has to have something like:
#ifdef HAS_SETLOCALE
...
setlocale(...)
...
#else
#endif
That does not help someone who has Locale
> I was talking about the hypothetical situation where you're (re)using or
> modifying a bunch of code or classes written by different people and you
> constantly have to be aware of which self-thingie to use in which file or
> package or whatever. Yeah, you can just glance up to the
> If you want to change STUPID behaviour that should be avoided by current
> programs (such as empty regexes) fine.
Simple solution.
If you want to require formats such as m/.../ (which I actually think is a
good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6
enhancement
On 8/28/00 3:35 PM, Damian Conway wrote:
>> ...while also giving the compiler enough information to allow such
>> invocant access to execute in an optimized manner...right? C'mon,
>> I'm dying here thinking that all this (admittedly cool) stuff is
>> gonna end up giving Perl 6 even more OO overhea
> > The use invocant was proposed as a way to maintain backwards
> > compatibility and yet give everyone the invocant access syntax he
> > or she personally favours.
>
> ...while also giving the compiler enough information to allow such
> invocant access to execute in an optimize
On 8/28/00 3:09 PM, Damian Conway wrote:
>> (Or, was it already intended that the implementation of 'use
>> invocant' might be some sort of compile-time macro?)
>
> No. I think a macro facility for Perl should be more general than just
> whacking some code in at the start of every subroutine.
>
> What I meant to say was more along the lines of "if this could be done as a
> macro, does it need to be a pragma, or could it be part of a standard macro
> package?"
>
> And, secondly, "if this *is* part of a standard macro package, wouldn't it
> be cool to let it shove arbitr
> > (Or, was it already intended that the implementation of 'use
> > invocant' might be some sort of compile-time macro?)
> No. I think a macro facility for Perl should be more general than just
> whacking some code in at the start of every subroutine.
Yes. I didn't phrase my comments well
> (Or, was it already intended that the implementation of 'use
> invocant' might be some sort of compile-time macro?)
No. I think a macro facility for Perl should be more general than just
whacking some code in at the start of every subroutine.
The use invocant was proposed as a way to ma
> I think it would be a good thing for user prototypes to be able to
> handle this case and I wholeheartedly support the RFC; but it opens
> a can of worms that should be addressed. Perhaps in another RFC. Do
> any other (Damian) RFCs on (Damian) prototyping impact (Damian)
> this a
> And the advantage of that over
>
> @hash{ grep /^[^_]/, keys %hash }
>
> would be what? Brevity?
Yes.
Damian
> Summary: I think these should all simply break down into a single
> Boolification test of some sort, as occurs already with operator
> overload.
Counter-summary: Although the high and low precedence binary ops could be
rolled together, the current version of operator o
Damian Conway wrote:
>I have a draft RFC that proposes that the LIST argument of a
>grep be optional in a hash slice, and default to the key list
>of the sliced hash. So:
>
> @hash{grep /^[^_]/}
>
>gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^
On 8/28/00 2:35 PM, Tom Christiansen wrote:
>> Object-oriented features were added to Perl with version 5, and in many
>> ways still appear somewhat "tacked on", with perhaps undue respect
>> for the Old Ways of Perl 4.
>
> [NB: This is not a serious missive.]
>
> Hey, that Perl uses packages fo
At 11:28 AM 8/28/00 -0700, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> > If the vtable stuff goes into the core perl engine (and it probably will,
> > barring performance issues), then what could happen in the
> >
> > my Foo $bar;
> >
> > case would be that all the vtable functions for Foo are
Steve Simmons wrote:
>
> IMHO the code
>
> $a = '3.14'; # from reading a file
> $b = '3.1400'; # from user input
> if ($a == $b) { ... }
>
> should see the two args being tested in numeric context, do the numeric
> casting, get floats, and do a floating compare. Durned if I know wh
Steve Fink wrote:
>
> "cond" for conditional?
I was thinking along that line, too. But coopting "conditional" in any way
is probably an ungood idea.
Probly "trans" is good; it has multiple useful mnemonic values: transactional,
transfer, transparent...
--
John Porter
We're building
My apologies for being too succinct. "lost" is a bit of an emotive word
which is somewhat inaccuracte.
I still believe in RFC 109 and I think I made a good case based on my
own reasons. However the overwhelming majority of responses were negative,
for their own very good albeit different reasons
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> But if perl6 bytecode does not need to be modified to be used
I'd assume that.
-- Johan
> Well, $hash{/re/} would only evaluate to a single scalar.
> More likely, you'd want @hash{/re/}, which would be
> equivalent to @hash{ grep { /re/ } keys %hash }.
I have a draft RFC that proposes that the LIST argument of a
grep be optional in a hash slice, and default to the key li
>Object-oriented features were added to Perl with version 5, and in many
>ways still appear somewhat "tacked on", with perhaps undue respect
>for the Old Ways of Perl 4.
[NB: This is not a serious missive.]
Hey, that Perl uses packages for classes, subroutines for methods, and
references for o
> Which I find cute as a demonstration of the Perl's context concept,
> but ugly as hell from usability viewpoint. I how to assign to an
s/how/have/;
$need_more_coffee++;
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'd
On Mon, Aug 28, 2000 at 12:23:48PM -0600, Tom Christiansen wrote:
> >Have you ever wanted to count the number of matches of a patten? s///g
> >returns the number of matches it finds. m//g just returns 1 for matching.
> >Counts can be made using s//$&/g but this is wastefull, or by putting some
>Move the mathematic functions (C, C, C) from the core
>binary into a loadable module. Remove the trigonomic (C, C,
>C) functions from the binary, they can already be loaded from the
>Math::Trig.pm module.
>=head1 DESCRIPTION
>It is desirable to make the perl core binary be easy to maintain a
Dan Sugalski wrote:
>
> If the vtable stuff goes into the core perl engine (and it probably will,
> barring performance issues), then what could happen in the
>
> my Foo $bar;
>
> case would be that all the vtable functions for Foo are taken as specially
> named subs/methods in the Foo packag
>Have you ever wanted to count the number of matches of a patten? s///g
>returns the number of matches it finds. m//g just returns 1 for matching.
>Counts can be made using s//$&/g but this is wastefull, or by putting some
>counting loop round a m//g. But this all seams rather messy.
It's r
At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote:
>=head2 Prototypes
>
>Currently, several built-ins do not provide prototype information.
>
> prototype("CORE::abs") ==> ;$
> prototype("CORE::shift") ==> undef
>
>This must be fixed. One might even call this a bug, although the
>cur
On Mon, Aug 28, 2000 at 05:40:11PM -, Perl6 RFC Librarian wrote:
> =head1TITLE
>
> counting matches
> =head1 DESCRIPTION
>
> Have you ever wanted to count the number of matches of a patten? s///g
> returns the number of matches it finds. m//g just returns 1 for matching.
> Counts
On Mon, Aug 28, 2000 at 05:39:20PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Less line noise - let's get rid of @%
...
> I withdrew it on 28th August as I figured I had lost the
> argument!
I'm sorry, but this just doesn't jive with me. There is no "argument".
We are discussing pro
Steve Simmons wrote:
>In all the straining at gnats over whitespace, filtering, etc, I have yet
>to see a single proposal that isn't accomplished by just using variables
>and manipulating them appropriately. And it avoids all the problems with
>whitespace on the HERE word.
In many cases, I agree
General comment on all the discussion of HERE docs.
When HERE docs cause you a problem, don't use 'em. There is little win
if any over
print << HERE;
Dear Sir:
You owe me bucks. Pay up.
Me.
HERE
and
$msg =
'Dear Sir:
You owe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Ensuring Perl's object-oriented future
=head1 VERSION
Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 16 2000
Last Modified: Aug 28 2000
Version: 2
Mailing List: [EMAIL PROTECTED
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
i.e., more than one loop variable, assigned successively from the list. He
didn't have time to RFC it, but when I looked at it, a problem arose: if
the loop variables aren't
At 12:19 PM 8/28/00 -0500, Jarkko Hietaniemi wrote:
> > Or what about a variable attribute:
> >
> > my $x : transactional
> >
> > and making the effect completely lexical? Why would other scopes need to
> > see such variables?
>
>Hear, hear! We do not want zillion and a half new keywords now that
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
counting matches
=head1 VERSION
Maintainer: Richard Proctor <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last Modified: 28 Aug 2000
Version: 3
Mailing List: [EMAIL PROTECTE
1 - 100 of 164 matches
Mail list logo
