Damian Conway [EMAIL PROTECTED] writes:
Errr. I would imagine that $ME contains:
* a reference to the object, within an object method
* the name of the class, within a class method
* a reference to the *subroutine* itself, within a non-method.
Ooh, recursive anonymous
Bart Lateur wrote:
On Thu, 17 Aug 2000 07:44:03 +1000, Jeremy Howard wrote:
$a and $b were done for speed: quicker to set up those global
variables than to pass values through the stack.
The solution is to pass args in as $_[0] and $_[1].
sort { $_[0] = $_[1] } @list
is very ugly.
I
[EMAIL PROTECTED] wrote:
I think all discussion fo RFC 76 (reduce) should be on the new -data
sublist. Jeremy, am I on track here?
You sure are. Any stuff related to data crunching features belongs over
there, please.
In [EMAIL PROTECTED], you wrote:
count = array; # scalar context because of assignment to
scalar.
alt_array[] = array; # list context
and if array is a subroutine?
count = array();
count = array; # warning - special meaning in p5.
Either would be just as messy -
Here in my pre-caffiene morning trance it occurs to me that a few of
the "fringe" features of perl should be removed from the langauge.
Here's a few things that I would venture to say that none of the
"perl5 is my first perl" people have probably ever actually used.
reset # How
I've very rarely found cases where ?? was useful and // didn't work, and
never in regular code.
From the Camel:
The C?? operator is most useful when an ordinary pattern match
would find the last rather than the first occurrence:
open DICT, "/usr/dict/words" or die "Can't open
Ken Fox wrote:
Dave Storrs wrote:
On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
BTW, if we define Cwith to map keys of a hash to named place holders
in a curried expression, this might be a good thing:
with %person {
print "Howdy, ", ^firstname, " ", ^lastname;
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines should be able to return an lvalue
=head1 VERSION
Maintainer: Johan Vromans [EMAIL PROTECTED]
Date: Aug 18, 2000
Last Modified: Aug 21, 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Those rule are hard to read. I've tried reading them quite a few times
and I have trouble understanding them. I can't tell if the rules are
complex or it simply needs to be reworked. If it is complex then I
don't think this is the right approach. The rules should be simple.
As for legacy. I
At 11:03 AM 8/21/00 -0400, Chaim Frenkel wrote:
Those rule are hard to read. I've tried reading them quite a few times
and I have trouble understanding them. I can't tell if the rules are
complex or it simply needs to be reworked. If it is complex then I
don't think this is the right approach.
http://www.cminusminus.org/ has pointers to three implementations.
None are 'industrial strength' yet.
You can't really implement C-- on top of C efficiently, because of (a) tail
calls
and (b) the runtime interface for garbage collection, exception handling
etc. But you can do it inefficiently,
Steven W McDougall wrote:
Does Perl6 support Symmetric MultiProcessing (SMP)?
This is a *huge* issue. It affects everything else that we do with
threads.
No it isn't. SMP is completely somebody else's problem. We need
a language that worlks right on a single processor. If the hooks we
Dave Storrs [EMAIL PROTECTED] writes:
If we are going to use this, I'd like to see us standardize on the
highest-precision (i.e. attosecond) version. While it's not necessary
in any application that I can currently think of and will probably never
be necessary in 90% of Perl applications,
From rfc 98:
=head2 acceptable coercions
When resolving which method Cfoo() to call in a context CTXT, and there
is no method Cfoo() defined for the context CTXT, Perl will examine
the types listed in C@CTXT::ISA{OVERLOAD_CONTEXTS} for a list
of other contexts
to see if Cfoo() can
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL A Cprivate keyword that lexically scopes hash keys to the current
PRL package, and allows hashes to contain two or more identically named (but
PRL differently scoped) entries. This would solve the problem of
PRL encapsulation in
Jeremy Howard writes:
: How much hand-waving can we do with implementation efficiency of anonymous
: subs and higher order functions? How much can we expect Perl to optimise
: away at compile time? For instance, if:
:
: $sum = reduce ^_+^_, @list;
:
: has any substantial overhead on each
Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
: Today around 11:48am, Tom Christiansen hammered out this masterpiece:
:
: : So basically, it would be nice if each, keys, values, etc. could all deal
: : with being handed a hash from a code block or subroutine...
: :
: :
: No. keys() expects something that starts with a %, not
: something that starts with a .
Wow. Now that, that, is lame. You're saying that keys() expects it's first
argument to begin with a %? Why should it care what it's argumen begins with?
You're just now figuring this out? Really?
All
The interesting thing about ... is that you have to be able to
deal with it a statement with an implied semicolon:
print "foo";
...
print "bar";
We already have plenty of statements with implied semicolons:
print "foo";
for @list {}
David L. Nicol writes:
: What if there were a faster way to do this, a way to Cstudy a
: group of regexes and have the computer determine which ones had
: parts in common, so that if $situation =~ m/^foo/ is true, the
: fifty rules that start ^bar don't waste any time. At all.
Perl 4 did this
Casey R. Tweten writes:
Wow. Now that, that, is lame. You're saying that keys() expects
it's first argument to begin with a %? Why should it care what it's
argumen begins with?
The keys function changes its arguments' data structure. keys resets
the each iterator (see the documentation
On Mon, Aug 21, 2000 at 09:00:26PM -0400, Casey R. Tweten wrote:
Today around 3:34pm, Tom Christiansen hammered out this masterpiece:
: No. keys() expects something that starts with a %, not
: something that starts with a .
Wow. Now that, that, is lame. You're saying that keys() expects
: In a void context, Cdump dumps the program's current opcode
: representation to its filehandle argument (or STDOUT, by
: default).
It's not clear to me that reusing a lame keyword for this is the
highest design goal. Let's come up with a real interface, and then if
[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
:
: print "foo";
: for @list {}
: print "bar";
Yes, we do, and I'm trying to figure out how to write a prototype for
one of those. :-) / 2
: I'd have expected:
:
: print (1,
[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
:
: print "foo";
: for @list {}
: print "bar";
Yes, we do, and I'm trying to figure out how to write a prototype for
one of those. :-) / 2
Under RFC 128 and the
On Mon, Aug 21, 2000 at 01:01:20PM -0600, Nathan Torkington wrote:
Larry Wall writes:
I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks. Or better, make it an official "stub" for rapid
[EMAIL PROTECTED] writes:
: : I would like to see a compiler warning for this:
: : "Spaces detected after apparent here document terminator", but
: : preferably phrased better.
: :
: : Are there any objections?
:
: I object, vaguely. I think it should just Do The
In a void context, Cdump dumps the program's current opcode representation
to its filehandle argument (or STDOUT, by default).
In a scalar or list context, Cdump dumps nothing, but rather returns the
Isource code of its arguments (or of the current state of the entire
program, by default).
Instant program migration:
host-a:foo.pl: print SOCKET dump;
host-b:bar.pl: { local $/; eval SOCKET };
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump
Damian Conway writes:
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die;
Ariel Scolnicov writes:
: I was asked to debug a weird Perl5 problem yesterday. The code in
: question looked roughly like this (indented 4 spaces, but otherwise
: unchanged):
:
: #!perl -w
: use strict;
:
: print END;
: The next line contains a space at the end.
: END
-Original Message-
From: Ed Mills [mailto:[EMAIL PROTECTED]]
Excellent idea- anything to get to production faster!
But don't {} or {1} sort of do the same thing?
I think the point here is readability, not unique functionality.
There more then one way to do it :)
-Corwin
From: Damian Conway [mailto:[EMAIL PROTECTED]]
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what
"Bryan C. Warnock" wrote:
On Fri, 18 Aug 2000, David L. Nicol wrote:
There will Be No Perl7
Of course not. Odd numbers are the development releases. The next
Perl after 6 will be 8.
So maybe the reference implementation should be written in perl 4. Did
perl 4 have references? Doing
Randal L. Schwartz writes:
: if ($a == $b) { ... } # should this be string or number comparison?
Actually, it's a syntax error, because of the ... there. :-)
But that reminds me of something I wanted a few months ago.
I'd entertain a proposal that ... be made a valid term that happens
(thread intentionally broken)
Nathan Torkington wrote:
Steve Fink writes:
True. Would anyone mourn @$scalar_containing_variable_name if it died?
I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
notice $x="var"; print @$x either -- it'll complain if you mention @var
Tom Christiansen writes:
: I've very rarely found cases where ?? was useful and // didn't work, and
: never in regular code.
:
: From the Camel:
:
: The C?? operator is most useful when an ordinary pattern match
: would find the last rather than the first occurrence:
:
: open
Excellent idea- anything to get to production faster!
But don't {} or {1} sort of do the same thing?
From: Larry Wall [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ... as a term
Date: Mon, 21 Aug 2000 09:09:01 -0700 (PDT)
Randal L. Schwartz writes:
: if ($a == $b) { ... } #
Today around 11:48am, Tom Christiansen hammered out this masterpiece:
: So basically, it would be nice if each, keys, values, etc. could all deal
: with being handed a hash from a code block or subroutine...
:
: In the current Perl World, a function can only return as output to
: its caller a
It would be nice if a human readable dump were possible. So please don't
completely dump the idea of Data::Dumper functionality in the core.
These are different things. And the bytecodes can always be B::Deparse'd, or
whatever we come up with for uncompilation.
Not that proper marshalling
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Hmm, what about CHECK blocks?
--tom
title: study a list of regexes
David Nicol.
Aug 21
version 1
[EMAIL PROTECTED]
Sometimes I have a group of regexen, and I would like to know
which ones will match.
Current practice is to "study" $situation and then grep them:
example a:
study $situation;
@matches = @rules{
: I would like to see a compiler warning for this:
: "Spaces detected after apparent here document terminator", but
: preferably phrased better.
:
: Are there any objections?
I object, vaguely. I think it should just Do The Right Thing.
(I suspect it should
Steve Fink writes:
My code for doing what I thought Exporter did is:
sub import {
my $p = caller(1);
*{"${p}::E"} = \%{"${p}::E"};
}
but that doesn't run afoul of use strict 'refs'. Can you point me to the
passage in Exporter.pm that uses this?
It does run afoul of use strict
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what dump was always meant to do.
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Not much :-)
Maybe:
dump "FILE:"
but not just a
On Mon, Aug 21, 2000 at 05:49:39PM -0700, Larry Wall wrote:
[EMAIL PROTECTED] writes:
: I take it the existing C... operator would be unaffected?
Essentially. The lexer is (and will continue to be) quite aware of the
difference between terms and operators.
Oops, just read this. Ignore my
[EMAIL PROTECTED] writes:
: How about this then:
:
: In a void context, Cdump dumps the program's current opcode representation
: to its filehandle argument (or STDOUT, by default).
It's not clear to me that reusing a lame keyword for this is the
highest design goal. Let's come up with a real
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
TO 2. Multiple conditional catch clauses now work like a switch,
TO instead of like a bunch of sequential ifs.
TO This always bugged me too, but I couldn't nail it down
TO until the debate about using else/switch instead of catch.
On 22 Aug 2000, Chaim Frenkel wrote:
Could you tell me why you would want two finallys?
Why not put them into one?
TO my ($p, $q);
TO try { $p = P-new; $q = Q-new; ... }
TO finally { $p and $p-Done; }
TO finally { $q and $q-Done; }
Presumably because all finally blocks
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
As for legacy. I strongly urge that Modules _never_ die.
It is extremely rude.
TO The contract between a module and its client is beyond the scope
TO of RFC 88. However, I take it from your strong stance that you
TO wrap every ++$i in an eval
Executive Summary:
We should go to a pure return-based mechanism for error signalling,
or a pure exception-based one. We can't do the former. Therefore
we should do the latter.
Author's Note:
I'm a pragmatist. I'll keep using return-based error signalling
for some purposes, just
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
TO Perl's behaviour after a Cdie starts call-stack unwinding, as
TO envisioned by this RFC, is as described by the following rules.
TO 1. Whenever an exception is raised Perl looks for an enclosing
TO try/catch/finally clause.
TO If
Could you tell me why you would want two finallys?
Why not put them into one?
chaim
"TO" == Tony Olekshy [EMAIL PROTECTED] writes:
TO Non-shared:
TO my ($p, $q);
TO try { $p = P-new; $q = Q-new; ... }
TO finally { $p and $p-Done; }
TO finally { $q and $q-Done; }
TO Shared:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS However, my memory as to what the current perl behavior is was faulty;
PS continue blocks do *not* share the lexical scope of their attached loop
PS blocks. I was misremembering the caveat at the end of this part of perlsyn
PS (which says the
--On 18.08.2000 14:36 Uhr -0700 David L. Nicol wrote:
How about backslash, after the type-qualifier?
use %record{
$\interest_earned += $\balance * $\rate_daily;
};
I don't really like having backslashes in front of ordinary characters
anywhere except when I mean them :-) (\n, \t
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what dump was always meant to do.
I was
Larry Wall wrote:
Ed Mills writes:
: But don't {} or {1} sort of do the same thing?
Well, { warn "Encountered stub"; (); } would be more like it. But the
biggest problem with {} or {1} is that they don't resemble an ellipsis.
Larry
dot operator selection:
The token clarifier sees
Today around 11:48am, Tom Christiansen hammered out this masterpiece:
: So basically, it would be nice if each, keys, values, etc. could all deal
: with being handed a hash from a code block or subroutine...
:
: In the current Perl World, a function can only return as output to
: its caller a
Larry Wall writes:
I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks. Or better, make it an official "stub" for rapid
prototyping, with some way of getting a warning whenever you execute
subscribe by sending mail to [EMAIL PROTECTED]
more details at http://dev.perl.org/lists
LIST: [EMAIL PROTECTED]
CHAIR: Mark-Jason Dominus [EMAIL PROTECTED]
MISSION:Draft and discuss RFCs related to regexp language
issues in Perl 6. Report weekly to
Larry Wall writes:
I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks. Or better, make it an official "stub" for rapid
prototyping, with some way of getting a warning
Thanks! Ok, from a type inferencing perspective...
Nathan Torkington wrote:
Symbolic references are used for dynamic function generation:
foreach my $func (qw(red green blue)) {
*$func = sub { "FONT COLOR=$func@_/FONT" }
}
Probably have to punt on checking user code in a main
I'd like to see a new builtin named "in" which does the same as
"in" in SQL. Basically,
print "OK!" if $val in ("foo","bar","bla");
Wait for the superpositions RFC:
print "OK!" if $val eq any("foo","bar","bla");
print "OK!" if $val =~ any(qr/fo+/,qr/bl?ar?/);
On Mon, 21 Aug 2000 06:11:02 -0600, Tom Christiansen wrote:
$first = $1 if ?(^neur.*)?;
$first ||= $1 if /(^neur.*)/;
Now if only we had a shortcut operator which would continue only if the
LHS was not defined...
--
Bart.
65 matches
Mail list logo
