Re: Things to remove
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 often do you clear variables wholesale? dump study # never been a win for me. ?pattern? # one-time match split ?pat? # implicit split to @_ What's everyone's feeling on removing these from perl6? How often are they used? 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. --tom
Re: Things to remove
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 words: $!\n";
while (DICT) {
$first = $1 if ?(^neur.*)?;
$last = $1 if /(^neur.*)/;
}
print $first,"\n"; # prints "neurad"
print $last,"\n"; # prints "neurypnology"
Nothing a SMOP can't address, but for one liners at the least, the
S part would seem to preclude the P part. (Same for the -l line-mode
flag.)
--tom
Re: implied pascal-like with or express
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;
}
# becomes
sub {
print "Howdy, ", $person{$_[0]}, " ", $person{$_[1]};
}-('firstname', 'lastname');
You're breaking the halting rules for figuring out the bounds of
a curried expression.
Your original code should have become:
with %person {
print "Howdy, ", sub { $_[0] }, " ", sub { $_[0] };
}
I don't believe so. The rule at issue here is probably:
quote
=item Sub called in void context
Currying halts in the argument list of a subroutine (or method) that is
called in a void context. The tree traversal example given above shows a
method in a void context (any return value from $root-traverse is being
ignored). Therefore just its argument is curried, rather than the whole
call expression.
/quote
I say 'probably' because it depends how 'with' is defined. Assuming that
there are no explicit curry prototypes or sub prototypes floating around in
the declaration of 'with', the commas do not limit the currying context.
It gets worse with longer examples because each line is a separate
statement that defines a boundary for the curry.
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.
my %person = { name = 'John Doe', age = 47 };
with %person {
print "$name is $age years old\n";
}
becomes
{
my $env = $CORE::CURRENT_SCOPE;
while (my($k, $v) = each(%person)) {
$env-bind_scalar($k, $v);
}
print "$name is $age years old\n";
}
The thing I don't like about either of these suggestions is that the local
scope is hidden. In cough VB, you can say:
dim height as double
dim ws as new Excel.worksheet // 'worksheet' has a 'height' property
with ws
print .height // Accesses ws.height
print height// Accesses me.height
end with
In Pascal, this is not possible. As a result, I find myself rarely using
'with' in Pascal, since it's rare that you do not need to access any of the
local variables within a block.
Re: RFC 76 (v1) Builtin: reduce
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 *like* the syntax of
sort { $a = $b } @list
My original post actually said that the reason for this is that you can then
write:
sort { ^0 = ^1 } @list;
...which is pretty Perlish.
Re: Things to remove
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 DICT, "/usr/dict/words" or die "Can't open words: $!\n";
: while (DICT) {
: $first = $1 if ?(^neur.*)?;
: $last = $1 if /(^neur.*)/;
: }
: print $first,"\n"; # prints "neurad"
: print $last,"\n"; # prints "neurypnology"
:
: Nothing a SMOP can't address, but for one liners at the least, the
: S part would seem to preclude the P part.
I don't think the S and the P are that preclusive. For the example above
you can just say:
/(^neur.*)/ .. ""
If you want to be able to reset, then say
/(^neur.*)/ .. !$x++# reset with $x = 0;
Larry
Re: ... as a term
"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 few months ago.
Larry I'd entertain a proposal that ... be made a valid term that happens
Larry to do nothing, so that you can run your examples through perl -c for
Larry syntax checks. Or better, make it an official "stub" for rapid
Larry prototyping, with some way of getting a warning whenever you execute
Larry such a stub.
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 development" truly possible.
perl -e '...' # all programs here
Maybe we can code it up with "Quantum::Superpositions::any"?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: ... as a term
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) { ... } # 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
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
such a stub.
Larry
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Pre-RFC: Require a warning on spaces after here-document terminator
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 : This is still a here document : END : : This can be very hard to discover. I find it hard to see myself doing : this on purpose. 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 ignore spaces on the left to.) Larry
RE: ... as a term
-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
Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%
(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
once.
These are symbolic references. You can forbid them with the strict
pragma. Yes, I'd miss them. So would the Exporter.
Damn, learn something new every day... perl really is incestuous with
its symbol table, isn't it?
Yes. That's what makes it useful.
Ouch. I need to know more. I'm looking at what a type inference engine
for perl would look like, and these symbolic references would incur some
massive pollution. Clearly, the inferencer will at least depend on
people using strict 'refs' to prevent every $$x="bleck" from trashing
the type of every scalar variable in the program. So can someone explain
to me what the actual uses are, so I can dream up some form of manual
annotation that will limit the scope of their effects? (If the
functionality of Exporter becomes more 'core', its usage should no
longer matter.)
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?
Re: RFC 76 (v1) Builtin: reduce
Still,
sort { $_[0] = $_[1] } @list
is very ugly.
Hence:
sort ^a = ^b, @list;
Damian
Re: Things to remove
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.
Re: ... as a term
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 development" truly possible.
Maybe we can code it up with "Quantum::Superpositions::any"?
Easy. I'll just add a Cthing operator to Q::S. It would take no
arguments and return a (lazy?) list of every possible Perl subroutine.
use Quantum::Superpositions '@thing';
if ($a eq "input") {
(any thing)-(@_);
}
else {
print "I need more input!\n";
}
Damian
PS: Can you tell whether I'm joking?
RE: Things to remove
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 dump was always meant to do. I was contemplating suggesting that Data::Dumper be rolled into the core and take over Cdump. But I think I like this idea even more. 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. Garrett
Re: Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 'refs'. That's the kind of thing that
the Exporter does.
Symbolic references are used for dynamic function generation:
foreach my $func (qw(red green blue)) {
*$func = sub { "FONT COLOR=$func@_/FONT" }
}
Also lazy function generation (similar thing but from within an
AUTOLOAD).
Class::Struct does it to mechanically create the subroutines for a
class.
Any object code that gets a class name (package) as an argument and
uses it to inspect variables in the package does it.
(off the top of my head)
Nat
RE: Things to remove
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 contemplating suggesting that Data::Dumper be rolled into the core and take over Cdump. But I think I like this idea even more. 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. How about this then: 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). Thus: dump FILE; # dump program state as opcodes print FILE dump;# dump program state as source code print dump \%data; # dump contents of hash as source code print dump \@data; # dump contents of array as source code print dump \data; # dump subroutine as source code # etc. If people like this, would someone please RFC it. Damian
Re: Pre-RFC: Require a warning on spaces after here-document terminator
[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 Right Thing. : (I suspect it should ignore spaces on the left to.) : : Hear, hear. : : And whilst you're in a mood to ignore whitespace, how about C$/ = "" : terminating on C/\n(\s*\n)+/? I'm more inclined to ignore $/ these days. :-) Larry
Re: Things to remove
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 SOCKET;
host-b:bar.pl: { local $/; eval SOCKET };
Or:
sub suspend { open $fh, "$_[0]" or die; dump $fh }
sub resume { do $_[0] }
Damian
Re: Things to remove
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; dump $fh }
sub resume { do $_[0] }
This is trickier than it first apperas, as the existing bytecode
shows. A Perl program is opcode + variables. Are you dumping symbol
tables? When recreated, will the variables have the same values they
currently do?
Just a pointer for the eventual RFCer to address.
Nat
Re: functions that deal with hash should be more liberal
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 LIST, not a HASH nor an ARRAY. Likewise, it can only
: receive a LIST, not those other two.
So, this is really a bug?
#!/usr/local/bin/perl -w
use strict;
$|++;
sub func {
return qw/KeyOne Value1 KeyTwo Value2/;
}
print "$_\n" foreach keys func();
No. keys() expects something that starts with a %, not
something that starts with a .
--tom
Re: Things to remove
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't seriously desirable as part of the standard distribtion. It's the basis for several important technologies, including data persistence and interprocess communication of the same. --tom
Re: Things to remove
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
RFC: extend study to produce a fast grep through many regexes
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{ grep {$situation =~ m/$_/} keys %rules};
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.
example b:
$matchcode = study @regexen;
will generate an anonymous subroutine (it's called $matchcode in
the example line) with a tree based on required parts of the
regexes, to minimize the number of match attempts to determine
which regexes will match. The subroutine will take an array
argument and will return the subset of the rules (as stated in
the original array, either string or compiled qr// references)
that match on all the arguments.
The code in example a could then be replaced
$matchcode = study keys %rules;
@matches = @rules{ $matchcode $situation }
This ability could speed "dirty matching" which currently cannot
take advantage of constant-time hash lookups without standardizing
the dirty parts.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Does despair.com sell a discordian calendar?
Re: Things to remove
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? Isn't that kinda lika yield; (the proposed coroutine "return") at the top level? Hmm, what about CHECK blocks? --tom -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: implied pascal-like with or express
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 are. May have shifted
over the weekend I do not know.
my %person = { name = 'John Doe', age = 47 };
with %person {
print "$name is $age years old\n";
}
How about changing it to
print "$\name is $\age years old\n";
That's clear as long as we can't name variables except w/in [\w]
becomes
{
my $env = $CORE::CURRENT_SCOPE;
while (my($k, $v) = each(%person)) {
$env-bind_scalar($k, $v);
}
print "$name is $age years old\n";
}
Where $CORE::CURRENT_SCOPE is some sort of magical variable that provides
access to the symbol table for the current scope. The bind_scalar() method
creates a new value binding. The code block of the "with" is evaluated
with these new bindings in effect.
The simplest way of doing this is to turn off warnings inside the "with"
block and force those variable names into the local scope at compile time.
Then at run-time the bind_scalar() can re-bind the variables to the values
in the hash.
- Ken
But that doesn't give us the speed win we want from compiling offset lookups
into a static record structure, at the cost of some funny "in -the-record"
syntax, as in other languages that support this (pascal, VB, C)
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Re: ... as a term
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 such a stub. This is the coolest suggestion made so far for perl6. I love it. And it's backwards compatible with a huge volume of "handwaving" code ;-) Runtime behaviour of '...' is to warn "unimplemented behaviour". With use strict 'development', it dies "unimplemented behaviour" at compile-time. I take it the existing C... operator would be unaffected? Damian
Re: Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%
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 routine that does
this. But if it's in a module, the inferencer should just get fired up
after all use's and other BEGIN's have been processed so the names and
code for all of those are known.
If you want user code to still get some inference, then you can have no
strict 'refs' everywhere but right here and have a pragma
assume_sub_in_source_is_never_overridden, so that $x = unknown_sub()
pollutes all package vars and all lexical vars captured anywhere by
anything. Though that's tough to verify. But subs would be okay. And
eval"", as usual, would kill pretty much everything.
Also lazy function generation (similar thing but from within an
AUTOLOAD).
Same, except known subs will never be overridden.
Class::Struct does it to mechanically create the subroutines for a
class.
Same.
Any object code that gets a class name (package) as an argument and
uses it to inspect variables in the package does it.
"Inspect", as in, read-only access? Then it's not bad. Does accessing
$p=;$x=${"${p}::foo"} activate $foo's tied FETCH? I suppose so. Then
it's bad.
(off the top of my head)
That's a nasty set of things that I was planning on looking at later to
see what can be salvaged (probably not much), but I was wondering more
about uses of $$x as a symbolic ref access as opposed to scalar
dereferencing. General symbol table manipulation is probably just going
to make the inferencer assume that any function call can rewrite all
other subroutines and piss on all visible variables, file descriptors,
etc., but scalar and array symbol table manipulation may be more
survivable.
I guess it doesn't matter that much, you just don't get any type
inferencing if you don't use strict 'refs' or you do use runtime eval""
or require. But maybe
my $Bob : might_be_accessed_symbolically
would be convenient enough to enable the type inferencer for more
programs.
Re: functions that deal with hash should be more libera
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 belg4mit
No. keys() expects something that starts with a %, not
something that starts with a .
That's lame though because I can do stuff like:
print join(' ', splice(@{[1,2,3,4,5,6,7,8,9,0]}, 3, 3));
Unless perl is internally checking that splice is a CORE
function and thusly deemed magical, (seems unlikely, bad and un-perl like),
join will allow me to give it something that "starts with "
And
sub foo { return (1,2,3,4); };
print join(' ', foo);
certainly seems to work.
So bascially my point is:
If a hash array function is handed a list, it should treat that list
as though it is the hash or array it would like it to be.
You know, that inherrent sense of Doing The Right Thing.
--
* __* .
\ | / .. . . . ((_
_ . . .
-- / \ -- .. . +. . _/\
oo. | * . . . * / ;M\_ .
..oo. . .. . /\. / :IMM\
....oo. Jerrad Pierce /\ / \ / ;IIWMM
..oo... 209 North Street +/ \ / \ . / ;WM
...o... Randolph, MA 02368/ \ \ ___/ :;IWM
oooo.../\\ / :: ;;IIIMI
.ooo.http://www.pthbb.org /\ \ : :::;IIIM
..ooo __ || || ::.::
MOTD on Pungenday, the 14th of Bureaucracy, in the YOLD 3166:
``How did it get so late so soon? It's night before it's afternoon. December is here
before it's June. My goodness how the time has flewn. How did it get so late so
soon?'' -Dr. Seuss
RFC: LAZY in scalar context resolves to ...
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: possible infinite loops from countint infinite arrays "lazy array" would be a suitable type for an lvalue subroutine to return, since an assignment of an array to it would fill the first n positions. -- David Nicol 816.235.1187 [EMAIL PROTECTED]
Re: ... as a term
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 ago.
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
such a stub.
Just to clarify, you're proposing that ellipsis do this in void
context only, right? I kind of like the existing ... operator just
the way it is (unless it has changed behind my back).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: functions that deal with hash should be more liberal
: 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 functions recieve their arguments in a LIST via @_. Since func, in the above example, returns a LIST, that LIST should just be passed on. I have to say, caring about what the argument looks like is bad news. So, you're saying to dispense with prototypes, even in the core, and leave us with the slowest language known to man? I don't see that flying. --tom
Re: ... as a term
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 {}
print "bar";
Either that, or it's a funny unary operator that can take 0 or 1 argument.
That might let you parse these too:
print (1, 2, 3, ...) or die;
I think this is fraught with peril. I'd have expected:
print (1, 2, 3, ...) or die;
to print
12345678910111213141516171819202122232425262728etc
rather than:
123Executed stubbed code at demo.pl, line 123
BTW, I propose the this new operator be pronounced "yadda yadda yadda". :-)
Damian
Re: RFC: extend study to produce a fast grep through many regexes
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 sort of thing automatically without a study, at least with respect to the first character that could match. Of course, it didn't do it with regular expressions in an array, but rather in a "switch" structure. And you had to bunch your tests right. If your regular expressions were in an array, you had to use eval. So certainly there's room for an interface that can take multiple regex objects and turn them into a single super regex. I don't think the code to do it necessarily belongs in the core, but it would certainly have to be somewhat incestuous with regex innards. Larry
Re: functions that deal with hash should be more liberal
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 for these functions). All functions recieve their arguments in a LIST via @_. The hash functions are prototyped as \%, meaning they are passed a reference to the hash named as an argument. The reference-taking: * permits them to change the data structures * is faster (one value, not all the key/value pairs) This isn't strictly needed for keys (if you don't mind it getting slower), but is needed for each() which maintains an iterator in the hash. There's also the fact that a list isn't a hash, the same way a list isn't an array. You are on a slippery slope that ends in: push( split(/,/), "foo" ); Because "push() just takes a list, right?" (hint: wrong). Nat
Re: functions that deal with hash should be more liberal
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 it's first
argument to begin with a %? Why should it care what it's argumen begins with?
It cares because it is only defined to operate on hashes. A list is
not a hash.
All functions recieve their arguments in a LIST via @_. Since func, in the
above example, returns a LIST, that LIST should just be passed on.
Exactly. This is what happens. keys() doesn't operate on lists.
keys( @array );
So this would "convert" @array to a hash and take the keys of that?
Or does it (as some have proposed) return the keyable indices of
sparse array?
Otherwise, work something like this:
sub keys {
my %hash = @_;
return keys %hash;
}
Ah, convert is argument to a hash then grab the keys of that hash.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Things to remove
: 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 we want to reuse the (the presumably missing) dump keyword for some method name or other, that's fine. But we're currently designing it from the wrong end. You're not a Sapir-Whorfist then? ;-) Actually, I wasn't proposing we design it at all. Sarathy has already done rather a good job of that, I think. Tom's opcode dumping functionality could, in principle, be added to Data::Dumper as it stands. My proposal was merely that CData::Dumper::Dumper body-snatch Cdump. Damian
Re: ... as a term
[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, 3, ...) or die;
:
: to print
:
: 12345678910111213141516171819202122232425262728etc
If you're into dwimmery, you could make all of these work, too:
print (1, 2, 4, ...)
print (1, 4, 9, 16, 25, ...)
print (1, 1, 2, 3, 5, ...)
print ('a', 'b', 'c', ...)
print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
: BTW, I propose the this new operator be pronounced "yadda yadda yadda". :-)
If you want to save the world, come up with a better way to say "www".
(And make it stick...)
Larry
Re: functions that deal with hash should be more liberal
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 care what it's argumen begins with?
:
: You're just now figuring this out? Really?
Actually, yes. I haven't hacked the core, yet. ;-)
: All functions recieve their arguments in a LIST via @_. Since func, in the
: above example, returns a LIST, that LIST should just be passed on. I have to
: say, caring about what the argument looks like is bad news.
:
: So, you're saying to dispense with prototypes, even in the core, and leave
: us with the slowest language known to man?
If it's really that bad, if it really has to be, then no. Why on earth would
anyone suggest such a thing? How obsurd!
: I don't see that flying.
No, in that case, I don't either.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[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'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: ... as a term
[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 forthcoming multimethods RFC:
sub for (\$iterator, @list, block) : multi;
sub for (@list, block) : multi;
I.e. collectively.
If you're into dwimmery, you could make all of these work, too:
print (1, 2, 4, ...)
print (1, 4, 9, 16, 25, ...)
print (1, 1, 2, 3, 5, ...)
print ('a', 'b', 'c', ...)
print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
You're an evil, evil man, Larry Wall.
You realize someone's probably revising the lazy lists RFC even as we type!
: BTW, I propose the this new operator be pronounced "yadda yadda yadda".
If you want to save the world, come up with a better way to say "www".
(And make it stick...)
I thought your US political satirists had solved this one.
Isn't it now pronounced "Dubya, Dubya, Dubya"?
Damian
Re: ... as a term
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 prototyping, with some way of getting a warning whenever you execute such a stub. This is the coolest suggestion made so far for perl6. I love it. Runtime behaviour of '...' is to warn "unimplemented behaviour". With use strict 'development', it dies "unimplemented behaviour" at compile-time. Hear hear! Great idea. Who'll RFC it? Or shall I? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: Things to remove
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 bareword :-( Hmm, what about CHECK blocks? Sorry, I'm a little slow today. You lost me. What about them? Damian
New syntactic sugar builtin: in
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, intuitive to use and readable...
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
Re: New syntactic sugar builtin: in
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?/);
print "OK!" if any(\foo,\bar,\bla)-($val);
print "OK!" if all(@vars) any(@threshold);
Damian
new list: perl6-language-regex
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 Language WG. DEADLINE: September 30th (semi-permanent sublist) - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
