Damian Conway <[EMAIL PROTECTED]> writes:
>> : And whilst you're in a mood to ignore whitespace, how about C<$/ = "">
>> : terminating on C?
>>
>> I'm more inclined to ignore $/ these days. :-)
>
> Well, just give me a regex getline terminator or pattern matches against
> fileh
> 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?/
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");
is the same as
print "OK!" if grep { $_ eq $val } ("foo","bar","bla");
or
print "OK!" if $val eq "foo" or $val eq
except it's a lot more compact, intuit
> > 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
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:
> : 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
Today around 7:11pm, 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 it's first
: >argument to begin with a %? Why should it c
[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
:
: print "foo";
: for @list {}
: print "bar";
Yes, we do, and I'm trying to figure out how to write a prototype for
one of those. :-) / 2
: I'd have expected:
:
: print (1, 2,
> : In a void context, C dumps the program's current opcode
> : representation to its filehandle argument (or STDOUT, by
> : default).
>
> It's not clear to me that reusing a lame keyword for this is the
> highest design goal. Let's come up with a real interface, and then if
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() exp
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
David L. Nicol writes:
: What if there were a faster way to do this, a way to C a
: group of regexes and have the computer determine which ones had
: parts in common, so that if $situation =~ m/^foo/ is true, the
: fifty rules that start ^bar don't waste any time. At all.
Perl 4 did this sort of
> 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 {}
>: 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?
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...
: >:
[EMAIL PROTECTED] writes:
: How about this then:
:
: In a void context, C dumps the program's current opcode representation
: to its filehandle argument (or STDOUT, by default).
It's not clear to me that reusing a lame keyword for this is the
highest design goal. Let's come up with a real inter
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. Ign
On Mon, Aug 21, 2000 at 09:09:01AM -0700, Larry Wall wrote:
> 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 ag
[EMAIL PROTECTED] writes:
: I take it the existing C<...> operator would be unaffected?
Essentially. The lexer is (and will continue to be) quite aware of the
difference between terms and operators.
The interesting thing about ... is that you have to be able to
deal with it a statement with an
Some have been frustrated at the fact that after
@ott = (1,2,3);
$x = @ott
$x == 3.
What if one of the things that lazy arrays did differently from
normal arrays was shifting on assignment, instead of counting
themselves?
This would solve several problems at once, including:
In reply to your message from the not too distant future: next Monday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Mon, 21 Aug 2000 19:04:27 EDT
From: Jerrad Pierce
>No. ke
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 { "@_" }
>}
Probably have to punt on checking user code in a main routine that does
> : And whilst you're in a mood to ignore whitespace, how about C<$/ = "">
> : terminating on C?
>
> I'm more inclined to ignore $/ these days. :-)
Well, just give me a regex getline terminator or pattern matches against
filehandles (a la RFC 93) and I'll never mention $/ again ;-)
> 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 warni
Ken Fox wrote:
> IMHO, curries have nothing to do with this. All "with" really does is
> create a dynamic scope from the contents of the hash and evaluate its
> block in that scope.
Right, the "with" people are using ^hats because its an available
operator, just the same way the "curry" people
On Mon, Aug 21, 2000 at 03:43:44PM -0600, Tom Christiansen wrote:
> > 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?
I
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{
> 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
>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 isn
>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 cal
Damian Conway writes:
> If domeone is putting this RFC together, please remember to propose
> that C and C should handle opcodes as well as source:
>
> host-a:foo.pl: dump SOCKET;
>
> host-b:bar.pl: { local $/; eval };
>
> Or:
>
> sub suspend { open $fh, ">$_[0]" or die; d
> Instant program migration:
>
> host-a:foo.pl: print SOCKET dump;
>
> host-b:bar.pl: { local $/; eval };
If domeone is putting this RFC together, please remember to propose
that C and C should handle opcodes as well as source:
host-a:foo.pl: dump SOCKET;
> In a void context, C dumps the program's current opcode representation
> to its filehandle argument (or STDOUT, by default).
>
> In a scalar or list context, C dumps nothing, but rather returns the
> I of its arguments (or of the current state of the entire
> program, by default).
Instant prog
[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
> > > 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
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
> : 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 shou
> 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
> I've always wished it was the famous "do what I mean" operator:
>
> if ($a eq "input") {
> ... # let perl figure out what to do here
> } else {
> print "I need more input!\n";
> }
>
> That'd make "rapid application developm
> 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 cont
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.
> Still,
>
>sort { $_[0] <=> $_[1] } @list
>
> is very ugly.
Hence:
sort ^a <=> ^b, @list;
Damian
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 whenever you execute
>
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 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 clarifie
>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 LIST, not a HASH nor an ARRAY. Likewise, it can only
receive a LIST, not those o
(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 mentio
Why is it that in perl 5 I can do:
use English::Dereference; #Or equivalent, relevant section included below
sub ARRAY {
return @{ shift() };
}
sub HASH {
return %{ shift() };
}
print join(' ', ARRAY [1,2,3,4]), "\n";
And the seemingly parallel:
print join(' ', HASH {1,2,3,4}), "\n";
"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?
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
-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
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 <
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) { ... }
> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
Larry> Randal L. Schwartz writes:
Larry> : if ($a == $b) { ... } # should this be string or number comparison?
Larry> Actually, it's a syntax error, because of the ... there. :-)
Larry> But that reminds me of something I wanted a
Tom Christiansen writes:
: >I've very rarely found cases where ?? was useful and // didn't work, and
: >never in regular code.
:
: >From the Camel:
:
: The C operator is most useful when an ordinary pattern match
: would find the last rather than the first occurrence:
:
: open DIC
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
[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.
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
>
> i
Ken Fox wrote:
> Dave Storrs wrote:
> > On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> > > BTW, if we define C 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, "
>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 w
>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 #
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
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].
Even if you succeed in making access to @_ as fast as access to $a
64 matches
Mail list logo
