RFC 120 (v4) Implicit counter in for statements, possibly $#.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implicit counter in for statements, possibly $#.
=head1 VERSION
Maintainer: John McNamara [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 120
Version: 4
Status: Frozen
Frozen since: v3
=head1 ABSTRACT
The syntax of the Perl style Cfor statement could be augmented by the
introduction of an implicit counter variable. The deprecated variable C$#
could be used for this purpose due to its mnemonic association with C$#array.
Other alternatives are also proposed: an explicit counter returned by a
function; an explicit counter defined after foreach; an explicit counter
defined by a scoping statement.
=head1 DESCRIPTION
The use of Cfor and Cforeach statements in conjunction with the range
operator, C.., are generally seen as good idiomatic Perl:
@array = qw(sun moon stars rain);
foreach $item (@array) {
print $item, "\n";
}
as opposed to the "endearing attachment to C" style:
for ($i = 0; $i = $#array; $i++) {
print $array[$i], "\n";
}
In particular, the foreach statement provides a useful level of abstraction
when iterating over an array of objects:
foreach $object (@array) {
$object-getline;
$object-parseline;
$object-printline;
}
However, the abstraction breaks down as soon as there is a need to access the
index as well as the variable:
for ($i = 0; $i = $#array; $i++) { # Note
$array[$i]-index = $i;
$array[$i]-getline;
$array[$i]-parseline;
$array[$i]-printline;
}
# Note - same applies to: foreach $i (0..$#array)
Here we are dealing with array variables and indexes instead of objects.
The addition of an implicit counter variable in Cfor statements would lead to
a more elegant syntax. It is proposed the deprecated variable C$# should be
used for this purpose due to its mnemonic association with C$#array. For
example:
foreach $item (@array) {
print $item, " is at index ", $#, "\n";
}
=head1 ALTERNATIVE METHODS
Following discussion of this proposal on perl6-language-flow the following
suggestions were made:
=head2 Alternative 1 : Explicit counter returned by a function
This was proposed by Mike Pastore who suggested reusing pos() and by Hildo
Biersma who suggested using position():
foreach $item (@array) {
print $item, " is at index ", pos(@array), "\n";
}
# or:
foreach $item (@array) {
$index = some_counter_function();
print $item, " is at index ", $index, "\n";
}
=head2 Alternative 2 : Explicit counter defined after foreach
This was proposed by Chris Madsen and Tim Jenness, Jonathan Scott Duff made a
similar pythonesque suggestion:
foreach $item, $index (@array) {
print $item, " is at index ", $index, "\n";
}
Glenn Linderman added this could also be used for hashes:
foreach $item $key ( %hash ) {
print "$item is indexed by $key\n";
}
Ariel Scolnicov suggested a variation on this through an extension of the
Ceach():
foreach (($item, $index) = each(@array)) {
print $item, " is at index ", $index, "\n";
}
With this in mind Johan Vromans suggested the use of Ckeys() and Cvalues()
on arrays.
A variation on this is an explicit counter after C@array. This was alluded to
by Jonathan Scott Duff:
foreach $item (@array) $index {
print $item, " is at index ", $index, "\n";
}
=head2 Alternative 3 : Explicit counter defined by a scoping statement
This was proposed by Nathan Torkington. This behaves somewhat similarly to
Tie::Counter.
foreach $item (@array) {
my $index : static = 0; # initialized each time foreach loop starts
print "$item is at index $index\n";
$index++;
}
# or:
foreach $item (@array) {
my $index : counter = 0; # initialized to 0 first time
# incremented by 1 subsequently
print "$item is at index $index\n";
}
=head1 IMPLEMENTATION
There was no discussion about how this might be implemented. It was pointed out
by more than one person it would inevitably incur an overhead.
=head1 REFERENCES
perlvar
Alex Rhomberg proposed an implicit counter variable on clpm:
http://x53.deja.com/getdoc.xp?AN=557218804fmt=text and
http://x52.deja.com/threadmsg_ct.xp?AN=580369190.1fmt=text
Craig Berry suggested C$#:
http://x52.deja.com/threadmsg_ct.xp?AN=580403316.1fmt=text
RFC 321 (v1) Common Callback API for all AIO calls.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Common Callback API for all AIO calls.
=head1 VERSION
Maintainer: Uri Guttman [EMAIL PROTECTED]
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 321
Version: 1
Status: Developing
=head1 ABSTRACT
This RFC addresses the way callbacks are requested in the Advanced I/O
(AIO) system and how they get called. The goal is to have a common
callback style across the board.
=head1 DESCRIPTION
There are several places in Perl where callbacks are needed. These
include socket I/O events, asynchonous file I/O, signals, timers, plain
events, etc. This RFC proposes a common API for requesting those
callbacks in order to keep this consistant in all those places.
=head1 IMPLEMENTATION
A callback currently can be registered in %SIG with a code ref as do Perl/Tk
and Event.pm. But there are time you want to have an object oriented
callback and that requires an object and a method. Event.pm handles this
with a anon list instead of the code ref. Its first element is the
object and the second is the method.
A solution which simplifies this and make calback code more consistant
is to allow either a code ref or an object as the single primary
argument to the call back API. The method called with the object is
defaulted to a name that is appropriate for the type of callback. That
method can be overridden with an optional argument.
For example, a read event would default to a method named 'readable',
and a socket connect event would default to 'connected'.
Here are two possible APIs, the first based on I/O handle objects
from RFC 14 and the second on the AIO syntax:
$obj = bless {}, 'Foo' ;
# these are I/O handle object based calls
$fh-read_event( 'cb' = $obj ) ;
$fh-write_event( 'cb' = $obj, 'method' = 'my_write_method' ) ;
# this is an AIO class call
AIO::read_event( 'fh' = $fh, 'cb' = \my_callback ) ;
sub my_callback {
my ( $fh ) = @_ ;
print "i can read $fh from package main::\n" ;
}
package Foo ;
sub readable {
my ( $self, $fh ) = @_ ;
print "i can read $fh\n" ;
}
sub my_write_method {
my ( $self, $fh ) = @_ ;
print "i can write $fh\n" ;
}
Most callbacks will also allow an optional timeout which would use the
the 'timed_out' method by default. You can override that method name
with the 'timeout_method' argument.
# 10 second timeout
AIO::read_event( 'fh' = $fh, 'cb' = $obj, 'timeout' = 10 ) ;
package Foo ;
sub readable {
my ( $self, $fh ) = @_ ;
print "i can read $fh\n" ;
}
sub timed_out {
my ( $self, $fh ) = @_ ;
print "$fh has had no data in a while\n" ;
}
=head1 IMPACT
None.
=head1 UNKNOWNS
None.
=head1 REFERENCES
Event.pm: XS based event loop module.
RFC 14: Modify open() to support FileObjects and Extensibility
RFC 47: Universal Asynchronous I/O
RFC 60: Safe Signals
RFC 86: IPC Mailboxes for Threads and Signals
RFC 87: Timers and Timeouts
RFC 101 (v3) Apache-like Event and Dispatch Handlers
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Apache-like Event and Dispatch Handlers
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 14 Aug 2000
Last Modified: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 101
Version: 3
Status: Frozen
=head1 ABSTRACT
A complete Perl 5 implementation of this can be found as Class::Handler
http://www.perl.com/CPAN/authors/id/N/NW/NWIGER/Class-Handler-1.03.tar.gz
Currently, there is no way to have multiple methods or modules for
dealing with events without significant contortions:
$data = $r1-get_data || $r2-stuff || $r3-func;
$r1-do_stuff(@vals) or $r1-do_this(@vals);
These simple cases can actually be tolerated. However, there are many
more complex cases which cannot be handled at all in Perl. These include
opening files only in certain directories, having methods decline or
partially handle requests, and so on.
This RFC proposes the idea of a Chandler, which is a special type of
class that is actually composed of one or more classes. Their operation
is very similar to Apache handlers: requests can be handled, declined,
or partially handled, without the top-level program having to know about
it.
=head1 NOTES ON FREEZE
The only concern ever raised was on why this should be core-worthy. One
word: speed. Currently, it can be implemented via CAUTOLOAD, but this
is slow. Also, other RFCs such as BRFC 14 rely on the notion of
handlers to gain important functionality (such as the ability to
transparently open URLs and different file types).
Damian has a separate RFC on pre and post sub handlers. It may be
possible to integrate the two into a common handler
framework/methodology. Unfortunately, I don't think either of us has the
time to do this at this point because of the upcoming RFC deadline.
However, this is something that should definitely be looked into in the
future.
=head1 DESCRIPTION
=head2 Overview
The concept of a Chandler is actually not that complex. In the
simplest case, it can be thought of as a type of abstraction:
sub open_it {
my $file = shift;
return open $file ||
HTTP::open $file ||
FTP::open $file;
}
Then, in your script, you would simply say:
$fileobject = open_it " $filename";
This gives you several benefits:
1. The internal handling of open_it can be changed
without having to update all your programs
2. Each operation can actually partially process
the request, if appropriate
2. Your program is easier to read and understand
From a Perl standpoint, these handlers work just like normal functions
and classes: they have methods, properties, inheritance, and so forth.
The only difference is that these handlers do not live in an external
file, but rather are assembled internally by Perl.
=head2 Adding and Using Handlers
First, the examples assume that the reader is somewhat familiar with RFC
14. If not, it is recommended that you give it a quick read at
http://dev.perl.org/rfc/14.pod
There are several competing syntaxes that I have for this proposal. I've
provided the one that I think is the best, but this is open to
discussion.
The proposed syntax is to use a pragmatic style:
use handler 'http' = 'MyHTTP';
use handler 'http' = 'LWP::UserAgent';
This would assemble a Chandler called 'http' which could then be used
in functions in your program. This handler would be a pseudo-class that
inherits methods from CMyHTTP and CLWP::UserAgent, in that order.
So:
$fo = open http "http://www.yahoo.com" or die;
would call Chttp-open, consistent with the current Perl
implementation. The only difference would be that Chttp now tries to
call the Copen() method from CMyHTTP and CLWP::UserAgent. As such,
the above call would result in the following flow chart:
$fo http-openundef
^ | ^
| | |
| Does MyHTTP::open exist?|
|YES/ \NO |
| / \ |
| Try it Does LWP::UserAgent::open exist? |
| / \^ YES/ \NO |
|OK/ \UNDEF / /
--- -- Try it|
| / \ |
| OK/\UNDEF |
- -
Some highlights:
1. Each class's open() method is tried in turn.
2. If undef is returned, the next one in sequence
is tried.
3. If 'OK' (simply meaning 1 or some other true
value, like $fo) is returned, that is propagated
out and returned by the top-level handler.
4. All classes are tried until 'OK' is returned
or the last one is reached.
This allows you to easily chain classes
RFC 308 (v1) Ban Perl hooks into regexes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Ban Perl hooks into regexes
=head1 VERSION
Maintainer: Simon Cozens [EMAIL PROTECTED]
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 308
Version: 1
Status: Developing
=head1 ABSTRACT
Remove C?{ code }, C??{ code } and friends.
=head1 DESCRIPTION
The regular expression engine may well be rewritten from scratch or
borrowed from somewhere else. One of the scarier things we've seen
recently is that Perl's engine casts back its Krakken tentacles into Perl
and executes Perl code. This is spooky, tangled, and incestuous.
(Although admittedly fun.)
It would be preferable to keep the regular expression engine as
self-contained as possible, if nothing else to enable it to be used
either outside Perl or inside standalone translated Perl programs
without a Perl runtime.
To do this, we'll have to remove the bits of the engine that call
Perl code. In short: C?{ code } and C??{ code } must die.
=head1 IMPLEMENTATION
It's more of an unimplementation really.
=head1 REFERENCES
None.
Re: RFC 308 (v1) Ban Perl hooks into regexes
Ban Perl hooks into regexes
=head1 ABSTRACT
Remove C?{ code }, C??{ code } and friends.
At first, I thought you were crazy, then I read
It would be preferable to keep the regular expression engine as
self-contained as possible, if nothing else to enable it to be used
either outside Perl or inside standalone translated Perl programs
without a Perl runtime.
Which makes a lot of sence in the development field.
Tom has mentioned that the reg-ex engine is getting really out of hand;
it's hard enough to document clearly, much less be understandible to the
maintainer (or even the debugger).
A lot of what is trying to happen in (?{..}) and friends is parsing. To
quote Star Trek Undiscovered Country, "Just because we can do a thing,
doesn't mean we should." Tom and I have commented that parsing should be
done in a PARSER, not a lexer (like our beloved reg-ex engine). RecDescent
and Yacc do a wonderful job of providing parsing power within perl.
I'd suggest you modify your RFC to summarize the above; that (?{}) and
friends are parsers, and we already have RecDescent / etc. which are much
easier to understand, and don't require too much additional overhead.
Other than the inherent coolness of having hooks into the reg-ex code, I
don't really see much real use from it other than debugging; eg (?{ print
"Still here\n" }). I could go either way on the topic, but I'm definately
of the opinion that we shouldn't continue down this dark path any further.
-Michael
Re: RFC 308 (v1) Ban Perl hooks into regexes
I think the proposal that Joe McMahon and I are finishing up now will make these obsolete anyway.
Re: RFC 308 (v1) Ban Perl hooks into regexes
In [EMAIL PROTECTED], Perl6 RFC Librarian writes:
:It would be preferable to keep the regular expression engine as
:self-contained as possible, if nothing else to enable it to be used
:either outside Perl or inside standalone translated Perl programs
:without a Perl runtime.
:
:To do this, we'll have to remove the bits of the engine that call
:Perl code. In short: C?{ code } and C??{ code } must die.
I would have thought it more reasonable, if you wish to create
standalone translated Perl programs without a Perl runtime, to fail
with a helpful error if you encounter a construct that won't permit
it. You'll need to remove chunks of eval() and do() as well,
otherwise, and probably more besides.
In the context of a more shareable regexp engine, I would like to
see (? and (?? stay, but they need to be implemented more cleanly.
You could handle them quite nicely, I think, with just three
well-defined external hooks: one to find the matching brace at the
end of the code, one to parse the code, and one to run the code.
Anyone wishing to re-use the regexp library could then choose either
to keep the default drop-in replacements for those hooks (that die)
or provide their own equivalents to the perl usage.
I consider recursive regexps very useful:
$a = qr{ (? [^()]+ ) | \( (??{ $a }) \) };
.. and I class re-eval in general in the arena of 'making hard
things possible'. But whether or not they stay, it would probably
also be useful to have a more direct way of expressing simple
recursive regexps such as the above without resorting to a costly
eval. When I've tried to come up with an appropriate restriction,
however, I find it very difficult to pick a dividing line.
Hugo
Re: RFC 308 (v1) Ban Perl hooks into regexes
In [EMAIL PROTECTED], Perl6 RFC Librarian writes:
:=head1 ABSTRACT
:
:Remove C?{ code }, C??{ code } and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Hugo
Re: RFC 308 (v1) Ban Perl hooks into regexes
On Mon, Sep 25, 2000 at 11:31:08PM +0100, Hugo wrote:
In [EMAIL PROTECTED], Perl6 RFC Librarian writes:
:=head1 ABSTRACT
:
:Remove C?{ code }, C??{ code } and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Whatever even more bizarre extensions people will have suggested by now...
--
DEC diagnostics would run on a dead whale.
-- Mel Ferentz
Re: RFC 308 (v1) Ban Perl hooks into regexes
On Mon, Sep 25, 2000 at 08:56:47PM +, Mark-Jason Dominus wrote: I think the proposal that Joe McMahon and I are finishing up now will make these obsolete anyway. Good! The less I have to maintain the better... -- Keep the number of passes in a compiler to a minimum. -- D. Gries
Re: RFC 308 (v1) Ban Perl hooks into regexes
On Mon, Sep 25, 2000 at 04:55:18PM -0400, Michael Maraist wrote:
A lot of what is trying to happen in (?{..}) and friends is parsing.
That's not the problem that I'm trying to solve. The problem I'm trying
to solve is interdependence. Parsing is neither here nor there.
--
Intel engineering seem to have misheard Intel marketing strategy. The phrase
was "Divide and conquer" not "Divide and cock up"
(By [EMAIL PROTECTED], Alan Cox)
Re: RFC 308 (v1) Ban Perl hooks into regexes
On Mon, Sep 25, 2000 at 08:56:47PM +, Mark-Jason Dominus wrote:
I think the proposal that Joe McMahon and I are finishing up now will
make these obsolete anyway.
Good! The less I have to maintain the better...
Sorry, I meant that it would make (??...) and (?{...}) obsolete, not
that it will make your RFC obsolete. Our proposal is agnostic about
whether (??...) and (?{...}) should be eliminated.
RFC 317 (v1) Access to optimisation information for regular expressions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Access to optimisation information for regular expressions
=head1 VERSION
Maintainer: Hugo van der Sanden ([EMAIL PROTECTED])
Date: 25 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 317
Version: 1
Status: Developing
=head1 ABSTRACT
Currently you can see optimisation information for a regexp only
by running with -Dr in a debugging perl and looking at STDERR.
There should be an interface that allows us to read this information
programmatically and possibly to alter it.
=head1 DESCRIPTION
At its core, the regular expression matcher knows how to check
whether a pattern matches a string starting at a particular location.
When the regular expression is compiled, perl may also look for
optimisation information that can be used to rule out some or all
of the possible starting locations in advance.
Currently you can find out about the optimisation information
captured for a particular regexp only in a perl built with
DEBUGGING, by turning on -Dr:
% perl -Dr -e 'qr{test.*pattern}'
Compiling REx `test.*pattern'
size 8 first at 1
rarest char p at 0
rarest char s at 2
1: EXACT test(3)
3: STAR(5)
4: REG_ANY(0)
5: EXACT pattern(8)
8: END(0)
anchored `test' at 0 floating `pattern' at 4..2147483647 (checking floating) minlen
11
Omitting $` $ $' support.
EXECUTING...
Freeing REx: `test.*pattern'
%
For some purposes it would help to be able to get at this information
programmatically: the test suite could take advantage of this (to test
that optimisations occur as expected), and it could also be useful for
enhanced development tools, such as a graphical regexp debugger.
Additionally there are times that the programmer is able to supply
optimisation that the regexp engine cannot discover for itself. While
we could consider making it possible to modify these values, it is
important to remember that these are only hints: the regexp engine
is free to ignore them. So there is a danger that people will misuse
writable optimisation information to move part of the logic out of
the regexp, and then blame us when it breaks.
Suggested example usage:
% perl -wl
use re;
$a = qr{test.*pattern};
print join ':', $a-fixed_string, $a-floating_string, $a-minlen;
__END__
test:pattern:11
%
.. but perhaps a single new method returning a hashref would be
cleaner and more extensible:
$opt = $a-optimisation;
print join ':', @$opt{qw/ fixed_string floating_string minlen /};
=head1 IMPLEMENTATION
Straightforward: add interface functions within the perl core to give
access to read and/or write the optimisation values; add methods in
re.pm that use XS code to reach the internal functions.
=head1 REFERENCES
Prompted by discussion of RFC 72:
RFC 72: Variable-length lookbehind: the regexp engine should also go backward.
Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching
Wouldn't this interact rather badly with the /gc option (which also leaves
Cpos set on failure)?
This question arose because I was trying to work out how one would write a
lexer with the new /z option, and it made my head ache ;-)
As you can see from the example code, the program flow stays very close
to what people would ordinarily program under normal circumstances.
By contrast, RFC 93 proposes another solution to the same problem, but
using callbacks. Since the same sub must do one of several things, the
first thing that needs to be done is to channel different kinds of
requests to their own handler. As a result, you need a complete rewrite
from what you'd use in the ordinary case.
I think that a lot of people will find my approach far less
intimidating.
I'm not sure I see that this:
my $chunksize = 1024;
while(read FH, my $buffer, $chunksize) {
while(/(abcd|bc)/gz) {
# do something boring with the matched string:
print "$1\n";
}
if(defined pos) { # end-of-buffer exception
# append the next chunk to the current one
read FH, $buffer, $chunksize, length $buffer;
# retry matching
redo;
}
}
is less intimidating or closer to the "ordinary program flow" than:
\*FH =~ /(abcd|bc)/g;
(as proposed in RFC 93).
=head2 Match prefix
It can be useful to be able to recognize if a string could possibly be a
prefix for a potential match. For example in an interactive program,
you want to allow a user to enter a number into an input field, but
nothing else. After every single keystroke, you can test what he just
entered against a regex matching the valid format for a number, so that
C1234E can be recognized as a prefix for the regex
/^\d+\.?\d*(?:E[+-]?\d+)$/
Isn't this just:
\*STDIN =~ /^\d+\.?\d*(?:E[+-]?\d+)$/
or die "Not a number";
???
Damian
Re: RFC 308 (v1) Ban Perl hooks into regexes
From: "Hugo" [EMAIL PROTECTED]
:Remove C?{ code }, C??{ code } and friends.
Whoops, I missed this bit - what 'friends' do you mean?
Going by the topic, I would assume it involves (?(cond) true-exp |
false-exp).
There's also the $^R or what-ever it was that is the result of (?{ }).
Basically the code-like operations found in perl 5.005 and 5.6's perlre.
-Michael
Re: RFC 308 (v1) Ban Perl hooks into regexes
From: "Simon Cozens" [EMAIL PROTECTED]
A lot of what is trying to happen in (?{..}) and friends is parsing.
That's not the problem that I'm trying to solve. The problem I'm trying
to solve is interdependence. Parsing is neither here nor there.
Well, I recognize that your focus was not on parsing. However, I don't feel
that perl-abstractness is a key deliverable of perl. My comment was
primarly on how the world might be a better place with reg-ex's not getting
into algorithms that are better solved elsewhere. I just thought it might
help your cause if you expanded your rationale.
-Michael
RFC 160 (v2) Function-call named parameters (with compiler optimizations)
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Function-call named parameters (with compiler optimizations)
=head1 VERSION
Maintainer: Michael Maraist [EMAIL PROTECTED]
Date: 25 Aug 2000
Last Modified: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 160
Version: 2
Status: Developing
=head1 CHANGES
Finialized various features by removing many of the options( grealy simplified
the RFC). Unified the goals with that of RFC 176 and RFC 273.
=head1 ABSTRACT
Function parameters and their positions can be ambiguous in
function-oriented programming. Hashes offer tremendous help in this
realm, except that error checking can be very tedious. Also, hashes,
in general, take a performance hit.
The goal is to enhance functionality / convinience / performance where
possible in regards to named-parameters, with a minimal of changes.
And, at the same time, allow this to be a completely optional and
virtually transparent process. The following is an in-depth analysis
of various ways of accomplishing these goals.
=head1 DESCRIPTION
The current method of parameter proto-types only fulfills a tiny
niche, which is mainly to offer compile-type checking and to
disambiguate context ( as in sub foo($) { }, or sub foo($) { } ).
No support, however, is given to hashes, even though they are one of
perl's greatest strengths. We see them pop up in parameterized
function calls all over the place (CGI, tk, SQL wrapper functions,
etc). As above, however, it is left to the coder to check the
existance of required parameters, since in this realm, the current
proto-types are of no help. It should not be much additional work to
provide an extension to prototypes that allow the definition of
hashes.
The following is a complex example of robust code:
#/usr/bin/perl -w
use strict
# IN: hash:
# a = '...' # req
# b = '...' # req, defined
# c = '...' # req, 0 = c = MAX_C
# d = '..' # opt
# e = '..' # opt
# f = '..' # opt
# OUT: xxx
sub foo {
my $self = shift;
my %args = @_;
# Requires $a
my $a;
die "No a provided"
unless exists $args{a};
$a = $args{a};
# Requires non-null $b
my $b;
die "invalid b"
unless exists $args{b} defined ($b = $args{b});
# Requires non-null and bounded $c
my $c;
die "Invalid c"
unless exists $args{c} defined ($b = $args{b}) ($c = 0 $c $MAX_C);
my ( $d, $e, $f ) = @args{ qw( d e f ) };
...
} # end foo
Becomes:
sub foo($%) : method required_fields(a b c) fields(d e f) doc(EOS) {
# IN: hash:
# a = '...' # req; Do some A
# b = '...' # req, defined; Do some B
# c = '...' # req, 0 = c = MAX_C; Do some C
# d = '..' # opt; Do some D
# e = '..' # opt; Do some E
# f = '..' # opt; Do some F
# OUT: xxx
EOS
my $self = shift;
my %args : fields(a b c d e f) = @_; # produce optimized hash
that is already pre-allocated at compile-time.
# Requires non-null $args{b}
die "invalid b"
unless defined $args{b};
# Requires non-null and bounded $args{c}
die "invalid c"
unless defined $args{c} ($args{c} = 0 $args{c} $MAX_C);
...
} # end foo
$obj-foo( c = 3, b = 2, f= 8, a = 1 );
# Note the out-of order, and the mixture of optional fields
foo( $obj, a = 1, b = 2, c = 3 ); # still totally legal
foo( a = 1, b = 2 ); # compiler-error (invalid num-args)
foo( 1,2,3,4,5,6,7); # compiler-error, missing args a, b and c
foo(a,1,b,2,c,3,$obj); # compiler-error, missing args a, b and c
# (since they're offset by one)
my @args = ( a = 1, b = 2, c = 3);
$obj-foo( @args ); # checking-deffered to run-time. Will be ok.
my @bad_args = ( b = 8, e = 4 );
$obj-foo( @bad_args ); # checking-deffered to run-time. Will fail.
Essentially, perl's compiler can be put to use for hashed-function
calls in much the same way as pseudo hashes work for structs/objects.
Making this a compile-time check would drastically reduce run-time
errors in code (that used hash-based parameters). It would also make
the code both more readible AND more efficient.
For readibility, perl can be quiried for the list of allowable options as
well as general documentation. In the above, the listing of Input options
would have been redundant, for both the code-reader, and the run-time query,
but was provided for completeness.
Note also that the above is compatible with the existing structure. In fact,
foo required the old-style prototype to distinguish the "self" variable from
the general-hash arguments. The use of the attribute "method" was optional, and
could be used in the auto-generation of a $SELF variable. At the very least, it
allows a run-time description of what the first argument really-is.
An important thing to note is that we're not changing the functionality of execution.
Perl sub's still look and feel like old-style subs to the user. They simply act as if
Re: RFC 285 (v1) Lazy Input
=head1 IMPLEMENTATION Tricky. Perl needs to know about scalar context, list context, and "finite list" context. Presumably, if I/O routines behave this way, user subs should be able to behave this way as well. Might use the same machinery as lazy subs. RFC 21 provides just the mechanism you (ahem) want in order to implement a "finite list" context behaviour for the diamond operator. Damian
Re: RFC 290 (v1) Remove -X
File tests (-r/-w/-x/...) made sense when Perl's shellness was an attribute. Most new Perl programmers are not coming from a shell programming background, and the -X syntax is opaque and bizarre. It should be removed. Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Blech. I certainly think that long functions are fine and dandy, but I'd loathe the day that I'd have to give up my -X stuff. I *love* it. I'm a shell-head! Many Perlers are. I would not classify giving this up as an improvement. Alternative functions are fine, but I think removing -X would definitely fit into the realm of causing existing Perl hackers to run away screaming. -Nate
Re: RFC 255 (v2) Fix iteration of nested hashes
Dear all, Since no-one has put their hand up to take this RFC over, I am now intending to retract it. I simply don't have the time to try and find a solution to the many (valid) problems that have been pointed out. I would heartily encourage anyone who wants to take on this monster to steal whatever they feel is worthwhile from this now-defunct proposal. Damian
Re: RFC 288 (v1) First-Class CGI Support
Perl is frequently used in CGI environments. It should be as easy to write
CGI programs with perl as it is to write commandline text filters.
First off, good idea, I do like this. Critiques:
Parse the CGI context, returning CGI variables into %CGI
Which variables are you talking about? Everything you need is already in
%ENV, as I'm sure you're aware.
If you're talking about splitting up the query string, then this should
be stated explicitly. And I think %CGI is a fine place for this. Will it
be quotemeta'ed?
Offer simple functions to set HTTP headers (e.g. content type, result codes)
How about %HTTP, which is just flushed on the first line of output?
use cgi;
$HTTP{'Content-type'} = 'text/html';
print "Hello!"; # flushes %HTTP first
Just one idea. Another is to just take the functions out of CGI.pm, but
then perhaps just using CGI_Lite is a better alternative.
All of the other features offered by Lincoln Stein's CGI.pm should remain,
but should not be deeply integrated into Perl6.
The RFC should just be a little more specific on what's being included
and not included. Are any of the functions like header(), h2(),
footer()? What about %ENV manipulation functions? What do people think?
-Nate
Re: IDEA: my() extensions and attribute declarations
On Wed, 20 Sep 2000, Nathan Wiger wrote:
Camel-3 shows some interesting hints of what's been proposed for my
declarations:
my type $var :attribute = $value;
And we all know that you can use my to declare a group of variables:
my($x, $y, $z);
Here's the issues:
1. How do the two jive together?
They don't.
And, of course, the ultimate spaghetti:
my (int ($x :unsign, $y) :big, char $z :long) :64bit;
Meaning is left as an exercise for the reader. :-)
Show mercy Nate. What did the reader ever do to you?
I am hoping that I won't have to concern myself with signedness and size
of numerical values in perl6. It doesn't belong in a scripting language.
But there all sorts of modifications to my floating around that will
probably make the cut: the dubious laccess and raccess, public and
private, const, and shared.
Rather than loose the ability to say ($a, $b, $c) = (qw/a b c/) why not
just use some new keywords?
our ($count, $message) = (1, 'Mars needs coffee');
const (PI, HTTP_OK) = (3.14159, 200);
sub new {
my ($class) = @_;
my $self = bless ref $class || $class;
public (@$self{qw/ first_name last_name /}) = qw/Alan Gutierrez/;
private (@$self{qw/ weight salary /}) = qw/Err.. *Ahem*/;
laccess (@$self{qw/ age favorite_color /}) = qw/ 28 blue /;
raccess (@$self{qw/ gender eye_color /}) qw / male brown /;
}
As long as we don't have too many attributes (like int, 64bit, EBCDIC,
etc.) this is plausible.
Alan Gutierrez
RE: RFC 288 (v1) First-Class CGI Support
Parse the CGI context, returning CGI variables into %CGI
Which variables are you talking about? Everything you need is already in
%ENV, as I'm sure you're aware.
Yeah, but its encoded... %CGI in an unencoded form would be a nice
thing. :)
If you're talking about splitting up the query string, then this should
be stated explicitly. And I think %CGI is a fine place for this. Will it
be quotemeta'ed?
It should theoretically do the full decode of the CGI environment...
Quotes, etc. included.
Offer simple functions to set HTTP headers (e.g. content type,
result codes)
How about %HTTP, which is just flushed on the first line of output?
use cgi;
$HTTP{'Content-type'} = 'text/html';
print "Hello!"; # flushes %HTTP first
Ooo... I like this :) The number of times I've had to construct 3 copies
of the header to cope with bizarre error conditions... Wouldn't it be nice
to:
use cgi;
$HTTP('Content-type') = 'text/html';
#
# other code here including a dup of STDERR to STDOUT
# or perhaps the die can be made to go to STDOUT for CGI
# apps... Hell, its better than a Error 500... ;)
#
open FH, "/etc/imafile" or die "Unable to open file";
prints to STDOUT:
Content-Type: text/html
Unable to open file
or something like that... It would be a nice thing ;)
Just one idea. Another is to just take the functions out of CGI.pm, but
then perhaps just using CGI_Lite is a better alternative.
Never used CGI_Lite... Why would a cut down version be better?
The RFC should just be a little more specific on what's being included
and not included. Are any of the functions like header(), h2(),
footer()? What about %ENV manipulation functions? What do people think?
I think that the current CGI module functionality should perhaps be
maintained, though not necessarily in its current form... Certainly
looking towards providing a nice and neat interface to the data submitted
is a good thing(tm)... But I don't think that reducing its functionality
is a particularly useful thing to do... At least not without considering
where said functionality can be placed so that people who do rely on it
can access it :)
Greg
Re: RFC 288 (v1) First-Class CGI Support
On 25 Sep 2000, Perl6 RFC Librarian wrote:
=head1 TITLE
First-Class CGI Support
First-class CGI to me means HTML::Embperl. It include a templating
lanaguage for creating HTML/XML pages and support for session management
via cookies.
Are we talking about having cookes close to the core? %COOKIE is there
just like %ENV?
$COOKIE{example} = ['Hello, ', 'World!'];
Could perl6 have features for embeded Perl in the tarball?
Could embedded perl become part of the perl langauge?
#!/usr/bin/perl -cgi
# Set defaults.
$FDAT{first_name} ||= 'Enter first name';
$FDAT{last_name} ||= 'Enter last name';
if ($FDAT{sent}) {
# Process form data.
}
while (EMBED) { print }
__EMBED__
html
body
form method="POST"
[+ 'Hello, World!' +]br
input name="first_name"br
input name="last_name"br
input name="sent" type="submit"
/form
/body
/html
In the above the hash FDAT is the form data form the POST. The embedding
language does neat things like add value attributes to inputs based on
the contents of %FDAT.
HTML::Embperl is my favorite embedded perl language, but maybe this
could be pluggable.
Alan Gutierrez
Re: RFC 282 (v1) Open-ended slices
=head1 TITLE
Open-ended slices
...
@thingy = function()
for (@thingy[3..$#thingy]) { ... }
Horrible, isn't it? People want something better.
I thought about it last year or so, and produced a couple of patches. It
seemed then that the right syntax was not, for instance:
(function())[3...-1]
because sometimes you want C$x..$y to return the empty list, but
actually:
(function())[3...]
(Or C[3..]. It doesn't matter.)
The same syntax is proposed in RFC 205 to allow getting a whole slice of an
array. It also appeared in RFC 24 which suggested allowing (0..) anywhere
that C.. is used. RFC 24 was withdrawn after it became clear that there
were too many cases where this behaviour was bizarre. By restricting this
behaviour to within an index, I think that we avoid the problem.
Can we extend RFC 282 so that it allows the right operand of C.. to be
omitted in any index, since the upper-bound can be implied? Or does it
already propose this? (...in which case please give an example of an
open-ended slice on an array rather than directly on a function returning a
list.)
Re: RFC 288 (v1) First-Class CGI Support
* Greg Boug ([EMAIL PROTECTED]) [25 Sep 2000 17:46]: [...] The RFC should just be a little more specific on what's being included and not included. Are any of the functions like header(), h2(), footer()? What about %ENV manipulation functions? What do people think? I think that the current CGI module functionality should perhaps be maintained, though not necessarily in its current form... Yes. It'd be far better having the XML stuff working in a more 'first class' fashion than assorted h2() etc functions. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ "Debugging involves backwards reasoning ... Something impossible occurred, and the only solid information is that it really did occur." --- Kernighan and Pike, "The Practice of Programming"
Re: RFC 282 (v1) Open-ended slices
On Mon, Sep 25, 2000 at 06:33:07PM +1100, Jeremy Howard wrote: Can we extend RFC 282 so that it allows the right operand of C.. to be omitted in any index, since the upper-bound can be implied? Or does it already propose this? Yes, I wanted this to apply to all slices. (...in which case please give an example of an open-ended slice on an array rather than directly on a function returning a list.) Well, there's "C@array[$foo...]" in the abstract; does that count? In any case, I think my meaning is sufficiently clear. -- `After all, we're not all freaky perverts' - Thorfinn
Re: RFC 255 (v2) Fix iteration of nested hashes
On Mon, 25 Sep 2000 17:18:56 +1100 (EST), Damian Conway wrote:
Since no-one has put their hand up to take this RFC over, I am now
intending to retract it. I simply don't have the time to try and
find a solution to the many (valid) problems that have been pointed out.
I would heartily encourage anyone who wants to take on this monster
to steal whatever they feel is worthwhile from this now-defunct proposal.
I am not porposing to take this over. Frankly, I don't care enough,
because I don't ever use "each". But I had written a reply, of which I'm
not use if I ever sent it. In this, I proposed to give each a lexical
scope, possibly optional. That way, even if you do recursion in a
function that uses each, you'd get a *different* iterator for every time
you come across it. Would that solve your problem? I think it could.
As for the "possibly optional" lexical scoping: the next syntax is a bit
ugly, but it shows some potential:
while(my($key, $value) = my each %hash) { ... }
^^
--
Bart.
Re: RFC 283 (v1) Ctr/// in array context should return a histogram
Simon, This has been on the Perl 5 to-do list for ages and ages. The idea is that when you're transliterating a bunch of things, you want to know how many of each of them matched in your original string. While this may be a fun thing to do - why? what is the application? Richard
Re: RFC 283 (v1) Ctr/// in array context should return a histogram
On Mon, Sep 25, 2000 at 09:55:38AM +0100, Richard Proctor wrote: While this may be a fun thing to do - why? what is the application? I think I said in the RFC, didn't I? It's extending the counting use of tr/// to allow you to count several different letters at once. For instance, letter frequencies in text is an important metric for linguists, codebreakers and others; think about how you'd get letter frequency from a string: $as = $string =~ tr/a//; $bs = $string =~ tr/b//; $cs = $string =~ tr/c//; ... $zs = $string =~ tr/z//; Ugh. (%alphabet) = $string =~ tr/a-z//; Yum. And it's on the Perl 5 wishlist, so it ain't just me that thinks its a worthy idea. -- Putting heated bricks close to the news.admin.net-abuse.* groups. -- Megahal (trained on asr), 1998-11-06
Re: RFC 283 (v1) Ctr/// in array context should return a histogram
On Mon, 25 Sep 2000 10:19:05 +0100, Simon Cozens wrote:
(%alphabet) = $string =~ tr/a-z//;
Yum.
You want it in a hash? Ooff. Well, maybe that's ok for Perl6.
For Perl5, it would seem to make more sense, to me, to return a list.
Simply a matter of consistency with the spirit of the rest of the
language.
@frequency = tr/a-z//;
would stuff the results in:
'a' - $frequency[0]
'b' - $frequency[1]
...
'z' - $frequency[25]
If you want a hash, you can use the hash slice trick to build one
yourself:
@frequency{'a' .. 'z'} = tr/a-z//;
And finally, you can get all the histograms you want, by doing:
while(/([a-z])/g) {
$count{$1}++;
}
or
s/([a-z])/$count{$1}++, $1/ge;
--
Bart.
Re: RFC 288 (v1) First-Class CGI Support
Perl6 RFC Librarian wrote: =head1 ABSTRACT Perl is frequently used in CGI environments. It should be as easy to write CGI programs with perl as it is to write commandline text filters. =head1 DESCRIPTION Tom Christiansen proposed this in his perl6storm message: =item perl6storm #0025 Make -T the default when operating in a CGI env. That is, taintmode. Will this kill us? Close to it. Tough. Insecurity through idiocy is a problem. Make them *add* a switch to make it insecure, like -U, if that's what they mean, to disable tainting instead. and this: =item perl6storm #0026 Make CGI programming easier. Make as first class as @ARGV and %ENV for CGI progging. For input variables, this would have the not-so-pleasant effect that we'd have to upgrade perl to support changes of, or custom implementations of, the CGI protocol (say, a different form encoding). This may be survivable. For output generation, it becomes worse. Support for new/different output is quite common (witness the support for XHTML in current CGI.pm), which is one reason which CGI.pm goes thorugh so many revisions. I'd hate to upgrade the perl interpreter for such cases. Now, implementing a more efficient version of CGI.pm is another matter. I would hope that more efficient method calls, dropping some backwards compatibility routines, and splitting the module into on-demand loaded pieces would help. Hildo
RE: RFC 283 (v1) Ctr/// in array context should return a histogram
From: Bart Lateur [mailto:[EMAIL PROTECTED]] On Mon, 25 Sep 2000 10:19:05 +0100, Simon Cozens wrote: (%alphabet) = $string =~ tr/a-z//; Yum. You want it in a hash? Ooff. Well, maybe that's ok for Perl6. For Perl5, it would seem to make more sense, to me, to return a list. Simply a matter of consistency with the spirit of the rest of the language. @frequency = tr/a-z//; would stuff the results in: 'a' - $frequency[0] 'b' - $frequency[1] ... 'z' - $frequency[25] That does'nt scale. how about @frequency = tr/a-z0-9//; or (for those of us who have more than 25 letters in the alfabeth): @frequency = tr/a-zæøå//; or how about CAPITALS? not to mention Unicode - ooomph.. Are the counts stuffed in the array in the order they appear in the tr-string? or in ascii-order? or whatever? That just won't work. The original proposal will however (or at least I can't find any obvious blunders)! regards Henrik Tougaard, FOA, Denmark.
proposed RFC. lindex() function...
Anyone want to pick up this? I just don't have the time, but I would like to see it in Perl6. = =head1 TITLE Builtin list context lindex() function =head1 VERSION Maintainer: NA [EMAIL PROTECTED] Date: 09 SEP 2000 Version: 0 Mailing List: perl6-language Number: 1 =head1 ABSTRACT Offer a simpler way to iterate through a list/array for matching purposes by adding the function Clindex. =head1 DESCRIPTION RFCs 207 and 262 offer suggestions regarding loop iterators and array indices, but still require a loop to parse through the entries of the list. This RFC proposes a Clindex function for finding list entries that match the expression. The builtin would return the index of the list entry that matched the expression passed. =head1 IMPLEMENTATION I can think of two options for implementation: =head2 Similar to Cindex Clist_index = lindex @list, EXPR, [offset]. =head2 Similar to Csubstr Clist_index = lindex @list, EXPR, [offset, replacement] In both cases, Coffset should be Inull of Iundef for subsequent calls to the function if an incremental search is desired. The function should also return Iundef for a null list or if the end-of-list is reached. A negative number passed to offset, could also indicate a reverse search, or a starting-point from the end-of-list. =head1 REFERENCES
Re: RFC 283 (v1) Ctr/// in array context should return a histog ram
On Mon, 25 Sep 2000 13:00:58 +0200, Henrik Tougaard wrote:
Are the counts stuffed in the array in the order they appear in the
tr-string? or in ascii-order? or whatever?
In the same order as they are in the tr/// string, of course.
@freq{'a' .. 'z', '0' .. '9'} = tr/a-z0-9//;
That just won't work. The original proposal will however (or at least I
can't find any obvious blunders)!
The hidden flaw is that it will be FAR slower than the original tr///,
because it needs to search for the hash key for every single matching
character it finds. Plus, in Perl 5, NO core function returns a hash.
None at all.
--
Bart.
Re: RFC 283 (v1) Ctr/// in array context should return a histog ram
On Mon, Sep 25, 2000 at 06:07:01AM -0700, Randal L. Schwartz wrote: Bart character it finds. Plus, in Perl 5, NO core function returns a hash. Bart None at all. It's not returning a hash. Precisely. There ain't no such thing as "hash context". It simply returns a list with an even number of elements. Now, when you put that into a hash, the Right Thing happens. And it isn't *that* slow; it uses a table, just like the ordinary way tr/a/b/ operates. That doesn't use a hash! Besides, you pay for what you get: if you want to use this, it'll do all the work for you at *perhaps* a slight speed expense. But it's sure faster than doing n different counts and assigns... -- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" -- Lewis Carroll, "Through the Looking Glass"
Re: RFC 283 (v1) Ctr/// in array context should return a histog ram
On 25 Sep 2000 06:07:01 -0700, Randal L. Schwartz wrote: Bart Plus, in Perl 5, NO core function returns a hash. Bart None at all. It's not returning a hash. I like the proposal that has it return a paired list, similar to the semi-paired list we get with a capturing split, or a list-context m/()()/g match. If you can garantee that it's also not using a hash internally to keep count, but instead a table parallel to the table that's being used to hold the conversion values, you've won me over. A hash would be very inefficient. The conversion from table to a paired list would only happen as a final step. -- Bart.
Re: RFC 287 (v1) Improve Perl Persistance
Many mechanisms exist to make perl code and data persistant. They should be cleaned up, unified, and documented widely within the core documentation. But doesn't this go against TMTOWTDI. :) Different people might have different requirements. Portability would want all ASCII, large apps might want compacted (if not compressed) storage, while others might want highly-efficient storage. Ideally it's a perl module, but for efficiency, it has to be a c-module. And that's just for the pickle. Shelving has a multitude of possibilities; most of which rely on OS installed libraries. Essentially, what would have to happen would be that perl has a built in DB package (or at least include the C-source for it's own implementation). This might not be a small feat. I'm not sure which DB package Python uses. Just about every language now has a form of serialization (with versioning). If any of the above would be accomplished, this would be it. Pick one of the many 'freeze/thaw'-type modules, then apply a linear and versions serialization routine. You might want to extend this RFC to include information about existing serialization techniques (which tend to be more sophisticated than raw dumping of a data-structure). Essentially in an OO design, each class needs a way of appending it's persistent data to the stream; this would have to avoid anything like a file-handle, or cached/tmp information. It's non trivial to do currently (to my knowledge). -Michael
Re: RFC 283 (v1) Ctr/// in array context should return a histog ram
On Mon, Sep 25, 2000 at 03:30:47PM +0200, Bart Lateur wrote: If you can garantee that it's also not using a hash internally to keep count, but instead a table parallel to the table that's being used to hold the conversion values, you've won me over. Naturally, it's hard to guarantee anything since this isn't implemented yet, tr/// hasn't happened yet, and not a single line of Perl 6 code has been written. It's a SMOP; "use an array instead of a hash". This changes nothing about the design. It seems I was wrong - when I did implement this before, I did use a hash: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-02/msg01192.html but a parallel table could have been possible and very easy. Incidentally, so what if a hash is slow? You pay for what you get. It's still quicker than doing it by hand. -- "I will make no bargains with terrorist hardware." -- Peter da Silva
Re: Perl6Storm: Intent to RFC #0004
Adam Turoff wrote: I plan to offer a more formal RFC of this idea. =item perl6storm #0004 Need perl to spit out pod/non-pod, like cc -E. Pod is too hard to parse. This would make catpod trivially implemented as a compiler filter. Note that this functionality is trivial if RFC79 is implemented. -- John Porter
Re: Perl6Storm: Intent to RFC #0101
Nathan Wiger wrote:
In fact, I'd much rather still a more generic function like 'want' that
takes a list of things to check:
file($file, 'd'); # is it a directory?
file($file, 'wd'); # is it a writable directory?
if ( all { $_-($file) } \writable, \directory ) { ...
:-)
--
John Porter
Re: RFC 283 (v1) Ctr/// in array context should return a histog ram
On Mon, 25 Sep 2000 14:44:16 +0100, Simon Cozens wrote: Incidentally, so what if a hash is slow? You pay for what you get. It's still quicker than doing it by hand. This is for the cases where epeople forget that they are "asking" for it. I don't want comp.lang.perl.misc or any other support center flooded with FAQs like "Why is tr/// so slow?";-) -- Bart.
Re: RFC 288 (v1) First-Class CGI Support
=head1 TITLE First-Class CGI Support Perl6 should be *easier* to write CGI programs than Perl5. One way to accomplish this is to add a C-cgi option to Perl, so that all of the mechanical setup is done automatically. That setup could also be done through a Cuse cgi; pragma. To make CGI programming easier, this option/pragma should: Should the option/pragma also do "something" with regards to files opened for writing? They (nearly?) always require locking in a CGI environment... That is, should this feature do anything with regards to file locking? -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
Re: RFC 290 (v1) Remove -X
On 25 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Remove -X The prefered mechanism for file tests should be more legible, using terms like 'readable(FOO)' and 'writeable(FOO)' instead of the =head1 MIGRATION ISSUES Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Why can't both remain in place? Have the short forms so that those of us who are used to them and don't find them confusing can use them (and so p526 does not need to address this issue), and have the new readability-enhanced ( : ) versions as well, for them's as want those. This seems like an excellent place to TIMTOWTDI. Dave
Re: RFC 290 (v1) Remove -X
Perl6 RFC Librarian wrote:
=head1 ABSTRACT
File tests (-r/-w/-x/...) made sense when Perl's shellness was an
attribute. Most new Perl programmers are not coming from a shell
programming background, and the -X syntax is opaque and bizarre.
It should be removed.
is_readable(file) is really -r(file)
If you are proposing complete removal of -X tests (as the RFC title
suggests) then I think the syntax definately needs more discussion.
I liked Nathan's suggestion (quoted below) and I've listed why I
think it's the better syntax.
It:
+ stacks multiple tests quite cleanly without excess verbiage
(if (-e -T -s -x){...} gets a little tedious especially
if you don't use $_)
+ introduces only 1 new keyword ("file" seems bad, but maybe not)
+ does not break the brains of the -X loving crowd (as much)
+ introduce long names for -X haters
e.g. file($file, 'readable,writable,directory');
Nathan Wiger wrote:
In fact, I'd much rather still a more generic function like 'want' that
takes a list of things to check:
file($file); # does it exist?
file($file, 'r'); # is it readable?
file($file, 'w'); # is it writable?
file($file, 'd'); # is it a directory?
file($file, 'wd'); # is it a writable directory?
file($file, 'dw'); # same thing
Otherwise we run the risk of 200 builtins just to check file types and
modes on all the different platforms
Clayton
Re: RFC 290 (v1) Remove -X
On Sun, 24 Sep 2000 23:05:45 -0700, Nathan Wiger wrote: Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Blech. I certainly think that long functions are fine and dandy, but I'd loathe the day that I'd have to give up my -X stuff. I *love* it. I'm a shell-head! Many Perlers are. I would not classify giving this up as an improvement. I am not a shellhead. In fact, I never do any shell programming. But I do feel that readable() innstead of -r is not an improvement. What's next, replacing abs() with absolute()? -r takes a *bit* of getting used to, but not much. For the rest, -X stands out as "this is a file test", and it's short. I love short. -- Bart.
Re: RFC 290 (v1) Remove -X
On Mon, 25 Sep 2000, Clayton Scott wrote:
It:
+ stacks multiple tests quite cleanly without excess verbiage
(if (-e -T -s -x){...} gets a little tedious especially
if you don't use $_)
+ introduces only 1 new keyword ("file" seems bad, but maybe not)
+ does not break the brains of the -X loving crowd (as much)
+ introduce long names for -X haters
e.g. file($file, 'readable,writable,directory');
Nathan Wiger wrote:
In fact, I'd much rather still a more generic function like 'want' that
takes a list of things to check:
file($file); # does it exist?
file($file, 'r'); # is it readable?
file($file, 'w'); # is it writable?
file($file, 'd'); # is it a directory?
file($file, 'wd'); # is it a writable directory?
file($file, 'dw'); # same thing
I'd even go so far as to say that the current -X syntax should be
_extended_, to allow for multiple tests at once, maybe by way of a
leading caret (mnemonic "all"):
-^rwx; # $_ is readable, writable and executable
($size, $mod, $acc, $ichange) = -^sMAC;
And, as the filetest operators currently rely solely on the unix-ish mode
and uid/gid of the file, there should be a pragma that you can use to
force the interpretation to be "true", i.e., modulo ACLs, readonly
filesystems, etc., maybe
use filetest true;
John.
Re: RFC 290 (v1) Remove -X
I'd even go so far as to say that the current -X syntax should be
_extended_, to allow for multiple tests at once, maybe by way of a
leading caret (mnemonic "all"):
-^rwx; # $_ is readable, writable and executable
($size, $mod, $acc, $ichange) = -^sMAC;
In fact, you wouldn't even need a caret, since all file tests are a
single letter. Just like grouping s/// flags, we should make file tests
groupable as well:
if ( -drwx /usr/local and ! -h /usr/local ) {
# directory exists and has correct perms
}
And, as the filetest operators currently rely solely on the unix-ish mode
and uid/gid of the file, there should be a pragma that you can use to
force the interpretation to be "true", i.e., modulo ACLs, readonly
filesystems, etc., maybe
use filetest true;
This is a good idea, I think.
The more I look at the RFC, the less enamoured I am with the original
suggestion, which came from Tom's perl6storm email. "Learn Perl" comes
to mind. As Bart notes, short is good, and -r makes just as much/little
sense as s/// for non shell-people. We shouldn't be trying to make Perl
into Pascal - beginner-friendly but shitty.
-Nate
Re: RFC 290 (v1) Remove -X
"John L. Allen" wrote: The use of a caret was to prevent decimation of the user's namespace, vis: perl -e 'print -rwx $_' Can't call method "rwx" on an undefined value at -e line 1. Yeah, but read the error - Perl's parsing that as: [nwiger@matrix:~]$ perl -MO=Deparse -e 'print -rwx $_'; print -$_-rwx; -e syntax OK This is a really, really, really strange use of indirect object syntax. I doubt anyone is doing that currently (and if they are, they really shouldn't be! :). And, as Damian notes, ^ is already taken as a general-purpose prefix for Perl 6. -Nate
Re: RFC 288 (v1) First-Class CGI Support
On Sun, 24 Sep 2000, Nathan Wiger wrote:
Offer simple functions to set HTTP headers (e.g. content type, result codes)
How about %HTTP, which is just flushed on the first line of output?
use cgi;
$HTTP{'Content-type'} = 'text/html';
print "Hello!"; # flushes %HTTP first
I like this a lot, but you need to make sure that it flushes the
hash in the right order if multiple keys are present.
Dave
Re: RFC 284 (v1) Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
On Mon, Sep 25, 2000 at 11:10:04AM -0700, Nathan Wiger wrote: Indeed. It is also worth noting that people on -flow have been hashing out safe signals through a "use signal" pragma, which would remove %SIG altogether. Oh, well, OK. Then this RFC's necessary, dammit! :) I like it! But I'm not so sure these are like BEGIN and END - which are really non-sub blocks - as much as DESTROY, perhaps. But that's a very subtle nitpick. Blast. Yeah, well. People know what I mean. -- "You can have my Unix system when you pry it from my cold, dead fingers."
RFC 255 (v3) Fix iteration of nested hashes
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix iteration of nested hashes
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 18 Sep 2000
Last Modified: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 255
Version: 3
Status: Retracted
=head1 NOTE ON RETRACTION
The thread:
http://www.mail-archive.com/perl6-language@perl.org/index.html#04190
points out some serious problems that the proposal did
not address. As I do not have time to find/invent good solutions, I
am forced to withdraw the proposal.
Anyone wishing to take up the cudgels against this annoying problem
has my encouragement to pick whatever they like from the bones of this
document.
=head1 ABSTRACT
This RFC proposes that the internal cursor iterated by the Ceach function
be stored in the pad of the block containing the Ceach, rather than
being stored within the hash being iterated.
=head1 DESCRIPTION
Currently, nesting two Ceach iterations on the same hash leads to
unexpected behaviour, because both Ceachs advance the same internal
cursor within the hash. For example:
%desc = ( blue = "moon",
green = "egg",
red = "Baron" );
while ( my ($key1,$value1) = each %desc )
{
while ( my ($key2,$value2) = each %desc )
{
print "$value2 is not $key1\n"
unless $key1 eq $key2;
}
}
print "(finished)\n";
It is proposed that each Ceach maintain its own cursor (stored in the pad
of the block containing it) so that the above example DWIMs.
=head1 MIGRATION ISSUES
Minimal. No-one nests iterators now because it doesn't work.
Usages such as:
$x = each %hash;
$y = each %hash;
@z = each %hash;
would change their behaviour, but could be translated if p52p6 defined:
sub p5_each(\%) { each %{$_[0]} }
and globally replaced each Perl 5 Ceach by Cp5_each.
There would not (necessarily) be any effect on the use of FIRSTKEY and NEXTKEY
in tied hashes, since the compiler could still determine which should be
called. However, tied hashes that use an internal cursor might behave
differently, if nested.
=head1 IMPLEMENTATION
Store the cursor in the pad of the block in which the Ceach is defined,
rather than within hash.
=head1 REFERENCES
RFC 136: (Implementation of hash iterators) suggests separate iterators for Ceach
and Ckeys/Cvalues.
Re: RFC 264 (v2) Provide a standard module to simplify the creation of source filters
On Mon, Sep 25, 2000 at 06:37:58PM -, Perl6 RFC Librarian wrote: This RFC proposes that the interface to Perl's source filtering facilities be made much easier to use. Hm. I've just sent in the "line disciplines" RFC, which probably will end up obsoleting a reasonable chunk of this. -- The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: RFC 284 (v1) Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
"NW" == Nathan Wiger [EMAIL PROTECTED] writes:
It sounds really stoopid to say C$SIG{__WARN__} on a machine which
doesn't have signals.
NW Indeed. It is also worth noting that people on -flow have been hashing
NW out safe signals through a "use signal" pragma, which would remove %SIG
NW altogether.
Instead, let's implement them as magic subroutines CWARN and CDIE
like CBEGIN and CEND. This seems more consistent anyway. Well, to
me.
and how do they nest or get localized? with use signal you can install a
lexically scoped handler or a package level handler. with WARN it looks
like a global handler to me.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 284 (v1) Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
On Mon, Sep 25, 2000 at 02:49:29PM -0400, Uri Guttman wrote: and how do they nest or get localized? with use signal you can install a lexically scoped handler or a package level handler. with WARN it looks like a global handler to me. They're special subs. They nest and get localized like subs. -- Twofish Pokemon seems an evil concept. Kid hunts animals, and takes them from the wild into captivity, where he trains them to fight, and then fights them to the death against other people's pokemon. Doesn't this remind you of say, cock fighting?
Re: RFC 284 (v1) Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
On Mon, Sep 25, 2000 at 03:10:47PM -0400, Uri Guttman wrote: in what order? like BEGIN and END? Whatever, yes. what if you wanted a block scoped warn handler? What about it? (Or did someone eat the "local" keyword already?) i think it would be better to have some explicit way of setting the handlers at runtime (better than %SIG) to give more control. Are you talking about signals or warn/die now? maybe instead of use signal, an extension to use warnings. you can pass it a code ref and/or a list of warnings to enable. Could do that, yeah. -- It's difficult to see the picture when you are inside the frame.
Re: RFC 290 (v1) Remove -X
On Mon, 25 Sep 2000, Nathan Wiger wrote:
perl -e 'print -rwx $_'
Can't call method "rwx" on an undefined value at -e line 1.
Yeah, but read the error - Perl's parsing that as:
[nwiger@matrix:~]$ perl -MO=Deparse -e 'print -rwx $_';
print -$_-rwx;
-e syntax OK
Ok, so that's pathological, but this isn't
perl -e 'print -rwx($_)'
Undefined subroutine main::rwx called at -e line 1.
Just think about all the possible subroutine names you can make out of
the set of chars [rwxoRWXOezsfdlpSbctugkTBMAC]. I don't think we want to
prevent the use of those names by allowing the -XXX syntax without some
special char used as a prefix. But as the ^ is already taken by the
cool RFC 23, my idea have hit a dead end:
-{rwx}
-~rwx
have ambiguity problems.
Hmmm, does
-^{rwx}
have a currying interpretation?
John.
Re: RFC 284 (v1) Change C$SIG{__WARN__} and C$SIG{__DIE__} to magic subs
"SC" == Simon Cozens [EMAIL PROTECTED] writes: SC On Mon, Sep 25, 2000 at 03:10:47PM -0400, Uri Guttman wrote: in what order? like BEGIN and END? SC Whatever, yes. what if you wanted a block scoped warn handler? SC What about it? (Or did someone eat the "local" keyword already?) well, if you have a sub thingy (what do you call a BEGIN type sub? i know there is an rfc to amke it a real sub) WARN, then how would you use local on it? that was my point. the syntax you proposed doesn't fit there, hence my counter proposal for a pragma. i think it would be better to have some explicit way of setting the handlers at runtime (better than %SIG) to give more control. SC Are you talking about signals or warn/die now? well, the current %SIG merges the two. my safe signals pragma could support both or the use warnings pragma could support warn and die handlers. but the %SIG mechanism is too weak as it only lets you pass a code ref. it needs some sort of key/value api to pass in other arguments like the warnings to enable, object level callbacks, etc. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
Michael Fowler wrote: This RFC makes no mention of what happens to the following constructs: use Foo; require Foo; I don't mind a very few special cases. I would imagine that these might have to remain special: use Foo; require Foo; import Foo; package Foo; But notice the disconnect here: package Foo; use base 'Bar'; Seems almost that: package 'Foo'; use base 'Bar'; Would be more consistent. The only real problem with this approach is require() which, as Schwern has to keep reminding me, can work on either files or packages: require Foo; # package Foo require 'Foo'; # file Foo But this already seems fragile to me. Why not have a separate keyword that always assumes it's a file? Decreased bloat; require could always be UNIVERSAL::require then: require 'Foo'; # package Foo include 'Foo'; # file Foo This would get rid of having to eval stuff for variable-based package names as well. %foo = (bar = "baz"); This would remain as-is, since = auto-quotes the LH operand. -Nate
Re: RFC 292 (v1) Extensions to the perl debugger
On Mon, Sep 25, 2000 at 07:34:04PM -, Perl6 RFC Librarian wrote:
Mailing List: [EMAIL PROTECTED]
Most of this RFC would probably be better off in perl6-stdlib; the debugger
isn't really part of the language. That being said, however...
The ability to easily retrieve and edit your N most recent commands to the
debugger (much like a bash_history).
Dosn't the default debugger do this if you've got ReadLine?
A better default pager.
I think it would be better for this to be a nonperl thing (possibly written
in perl, but not a part of the debugger proper).
The ability to provide a function name (preferably just the first unique
section of its name) and
You can do the unique prefix part by looking in the symbol table.
jump to where that function is defined,
This, I think, would be a quite useful and simple thing to acatualy put in
the language. Just have two implicit attributes on a sub: :line and :file,
that recive the value of __LINE__ and __FILE__ at the sub {} statement.
Note that the AutoLoader and such things that use evals to define subs would
probably want to change these attributes -- otherwise they'd probably get
the location of the AUTOLOADER sub and not where the sub being autoloaded
was acatualy written.
Most of the rest would require siginificant overhead on all programs that
might get debugged (the debugger is a module; you don't necessarly have to
start it from the commandline). Use a tags program. G
-=- James Mastros
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: RFC 290 (v1) Remove -X
"John L. Allen" wrote:
Ok, so that's pathological, but this isn't
perl -e 'print -rwx($_)'
Undefined subroutine main::rwx called at -e line 1.
Well, it is still a little weird. You're still negating a subroutine
call. And remember, if you have a sub called "r" this doesn't work right
currently:
sub r {
return 41 + $_[0];
}
$file = '1';
unless ( -r $1 ) {
print 'our total was: ', -r $1, "\n";
}
If you want to do what you're proposing, why not just put parens around
it?
perl -e 'print -( rwx $_ )'
Or not even that, how about just a space?
perl -e 'print - rwx $_'
This is needed to fix the above 'r' example currently. And how often do
you have to directly negate sub calls??
I'm not trying to turn a deaf ear to your concerns, but I do think
they're not showstoppers. Negating sub calls with no space is weird, and
so is negating strings, which are the only two things making a leading -
special in the given context could conflict with. And there's already
plenty of places currently (as shown above) where this conflict exists
and doesn't seem to be causing any problems.
Hmmm, does
-^{rwx}
have a currying interpretation?
Yes, it does, see Damian's RFC on higher-order functions.
-Nate
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 02:17:38PM -0700, Nathan Wiger wrote:
import Foo;
You're beginning to blur your own fine line here. import is a class method
call using indirect object syntax.
But notice the disconnect here:
package Foo;
use base 'Bar';
Seems almost that:
package 'Foo';
use base 'Bar';
Would be more consistent.
Using 'Foo' with package implies $foo, or foo(), or "f" . "oo", or any
scalar, would work.
This whole idea reminds me of the quote:
A foolish consistency is the hobgoblin of little minds.
-- Ralph Waldo Emerson
Not to say you have a little mind, but is this a foolish consistency?
Most of Perl's bareword handling is what I mean, with the exception of class
method calls, which we already have a proposal for fixing. You are also
already proposing we keep certain exceptions to your 'no barewords' rule.
So what's left?
print STDERR "Foo";
We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
through.
$time = time;
print;
If use strict 'subs' is in effect you're guaranteed these are subroutine
calls, or compile-time errors. If it isn't you get a nice little warning.
Perhaps the stringification should be removed entirely, and the syntax
always be a subroutine call.
Class-foo()
shift-bar()
new Foo;
Class method calls, regardless of the existence of a subroutine in scope,
under the new proposal. I'm not sure of the last one, but it seems natural:
force the user to disambiguate with parens if they truly meant Foo() to be a
subroutine call.
stat-{'mode'}
No ambiguity here.
use Foo;
require Foo;
package Foo;
%foo = (bar = "baz");
All exceptions to the rule.
$foo{bar}
There's one you didn't mention. Currently it's unambiguous, you have to use
$foo{+bar} or $foo{bar()} to get a subroutine call.
Did I miss anything?
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 143 (v2) Case ignoring eq and cmp operators
Perl currently only has Ceq and Ccmp operators which work case-sensitively.
It would be a useful addition to add case-insensitive equivalents.
As I recall, the consensus the last time this came up was that Ccmpi and
Ceqi would be perfect examples w/in a RFC proposing a way to declare
a function to take it's arguments in infix instead of prefix manner.
sub cmpi($cmpi$){ # or something like this
uc(shift) cmp uc(shift)
}
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"The most powerful force in the universe is gossip"
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
Michael Fowler wrote:
You're beginning to blur your own fine line here. import is a class method
call using indirect object syntax.
And, actually, per Schwern's RFC 253, require() would be too. Sometimes.
stat-{'mode'}
No ambiguity here.
So I assume you're suggesting that this:
stat-{'mode'}
be a call to stat(), which returns a hashref, but this:
stat-mode
would be a call to the method mode() in the class 'stat'
That's not how I read RFC 244. If it is, I like it even worse. You
expect a beginner or even intermediate user to wrap their heads around
that?
The goal of my RFC was to point out the problems with barewords vs.
functions, and I'm glad this discussion is taking place. My main point
is that this ambiguity does *not* occur often enough to warrant
special-casing - as RFC 244 and others propose. If people want to, they
can "use strict 'words'", which I suggest in RFC 278, as a way to fix
this problem.
Auto-quoting - is a Bad Idea. Let's not forget there's plenty of ways
to disambiguate this already!
$stuff = stat::-mode; # class 'stat'
$stuff = stat()-mode; # function 'stat'
Why should we make Perl any less flexible by default? I just don't get
it. I've personally never had any problems with this:
$q = CGI-new
Accidentally calling CGI()-new. Has anyone else really? Or is this a
theoretical concern?
-Nate
Re: RFC 290 (v1) Remove -X
On Mon, 25 Sep 2000 10:22:46 -0400, Clayton Scott wrote:
It:
+ stacks multiple tests quite cleanly without excess verbiage
(if (-e -T -s -x){...} gets a little tedious especially
if you don't use $_)
Perhaps you want is to use $_. A "with" statement, or is it an
expression, sounds like it could do the job:
if(with($file){-e -T -s -x}) { ... }
Note that currently you can use for(SCALAR) BLOCK in a similar function,
except that it's a statement and not an expression, and it doesn't
return anything.
This works in perl5:
if(grep {-e -T -s -x} $file) { ... }
but the syntax doesn't match the purpose.
--
Bart.
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 03:50:20PM -0700, Nathan Wiger wrote:
So I assume you're suggesting that this:
stat-{'mode'}
be a call to stat(), which returns a hashref, but this:
stat-mode
would be a call to the method mode() in the class 'stat'
That's not how I read RFC 244. If it is, I like it even worse.
I quote:
Currently,
foo-bar($baz)
can be parsed either as C'foo'-bar($baz), or as
Cfoo()-bar($baz) depending on how the symbol Cfoo was used on
other places. The proposal is to always choose the first meaning: make
C - autoquote the bareword on the left.
You expect a beginner or even intermediate user to wrap their heads around
that?
I don't see many beginners trying for such shortcuts. I've called methods
on shift, but I don't expect a beginner to try that, and by the time they
do, I expect them to know enough Perl to understand the source of their
errors. This behaviour should be documented. Enough code will be in place
to drive it home.
Auto-quoting - is a Bad Idea. Let's not forget there's plenty of ways
to disambiguate this already!
$stuff = stat::-mode; # class 'stat'
$stuff = stat()-mode; # function 'stat'
The point is not that it's easy to disambiguate, the point is it's easy for
the construct to be ambiguous. I'm willing to live with stat()-mode if it
means stat-mode always means "call the method mode in the class 'stat'".
Why should we make Perl any less flexible by default? I just don't get
it. I've personally never had any problems with this:
$q = CGI-new
Accidentally calling CGI()-new. Has anyone else really? Or is this a
theoretical concern?
This is not a theoretical concern. If someone, at some point, defines sub
CGI {} your constructor suddenly fails. If you're using something along the
lines of Animal::Bear-new(), and the author of Animal.pm defines a Bear()
method, your constructor suddenly fails. This is action at a distance.
It's a pain.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 04:50:32PM -0700, Nathan Wiger wrote:
Is just as much of a pain because of action-at-a-distance. Solving this
problem with highly-specific solutions gains us nothing but more
syntactic inconsistencies and ambiguities, like these:
stat-{'mode'}
stat-mode
working massively differently. That's confusing!! It is!!! Really.
Then say stat()-{'mode'} and stat::-mode, if it makes you feel better. Or
better yet, always say stat()-anything when you mean the function call.
Honestly, if you're using both a stat class and a stat function in your
code it's up to you to keep it straight; Perl should make the easy thing
(calling a class method, for certain) easy.
The solutions are:
use bareword 'literals';
# ... lots of intervening code ...
stat-mode; # call the mode method in the class 'stat'
stat-{'mode'}; # you can't dereference a scalar, silly
or
use bareword 'functions';
# ... lots of intervening code ...
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call stat(), die when it's discovered it isn't an object
or
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call the mode method in the class 'stat'
The last seems more DWIMish to me.
We need to step back and fix the *problem*: barewords vs. functions are
ambiguous. In *all* contexts. Always. You can screw yourself with any of
these equally:
$SIG{TERM} = IGNORE;# "IGNORE" or IGNORE()?
print output @stuff;# print(output(@stuff))
# or output-print(@stuff)?
$r = new CGI; # new(CGI) or CGI-new?
$q = CGI-new; # "CGI"-new or CGI()-new?
$name = first . middle; # "firstmiddle" or
# first() . middle()?
$total = number + 42; # number() + 42 or
# "number" + 42?
I only see two action-at-a-distance potentials in the above, the two class
method calls. I addressed everything else, I'm not going to repeat the
list.
The problem is this: barewords and functions are ambiguous. Always.
*ALL* contexts.
You keep uttering these absolutes as if the more times you utter them the
more true they'll get. From all of the examples shown the only ambiguity
I've seen is when it comes to class methods.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
Michael Fowler wrote:
Then say stat()-{'mode'} and stat::-mode, if it makes you feel better. Or
better yet, always say stat()-anything when you mean the function call.
Either way is fine by me, but making Perl do one one place and the other
the other place makes no sense.
Honestly, if you're using both a stat class and a stat function in your
code it's up to you to keep it straight
Exactly my point. So why is this
stat-mode
Any different? It's not.
The solutions are:
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call the mode method in the class 'stat'
The last seems more DWIMish to me.
I like DWIM. DWIM is good. But if - is going to be two distinct,
completely different operators in two separate contexts, then we need a
new operator. It is confusing and misleading otherwise.
We need to step back and fix the *problem*: barewords vs. functions are
ambiguous. In *all* contexts. Always. You can screw yourself with any of
these equally:
$SIG{TERM} = IGNORE;# "IGNORE" or IGNORE()?
print output @stuff;# print(output(@stuff))
# or output-print(@stuff)?
$r = new CGI; # new(CGI) or CGI-new?
$q = CGI-new; # "CGI"-new or CGI()-new?
$name = first . middle; # "firstmiddle" or
# first() . middle()?
$total = number + 42; # number() + 42 or
# "number" + 42?
I only see two action-at-a-distance potentials in the above, the two class
method calls.
WHAT???!!
Try this code:
print header . "\n";
use CGI qw/:standard/;
print header . "\n";
So you're claiming that's not action at a distance? You're completely
wrong. The same exact mechanism causes 'Class' to become Class() -
modules exporting functions into your namespace.
-Nate
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, Sep 25, 2000 at 05:49:21PM -0700, Nathan Wiger wrote:
Michael Fowler wrote:
Honestly, if you're using both a stat class and a stat function in your
code it's up to you to keep it straight
Exactly my point. So why is this
stat-mode
Any different? It's not.
Yes, it is, because you are not necessarily the only one who has control
over whether or not there is a stat function in the current namespace. Or,
on a more complex level, whether or not your parent class has subroutines by
the same name as you.
stat-{'mode'}; # call stat(), access the mode key
stat-mode; # call the mode method in the class 'stat'
Actually, under RFC244 stat-{'mode'} should be stat()-{'mode'}, so this
issue is moot, and that last example would have problems. You are forced to
disambiguate.
Try this code:
print header . "\n";
use CGI qw/:standard/;
print header . "\n";
So you're claiming that's not action at a distance? You're completely
wrong. The same exact mechanism causes 'Class' to become Class() -
modules exporting functions into your namespace.
I guess I will repeat myself, and I quote:
$time = time;
print;
If use strict 'subs' is in effect you're guaranteed these are subroutine
calls, or compile-time errors. If it isn't you get a nice little
warning. Perhaps the stringification should be removed entirely, and
the syntax always be a subroutine call.
Notice the last sentence.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, 25 Sep 2000, Michael Fowler wrote: This RFC makes no mention of what happens to the following constructs: %foo = (bar = "baz"); This actually isn't a bareword (as I understand it), since the = operator quotes its LHS.
Re: RFC 287 (v1) Improve Perl Persistance
On Mon, Sep 25, 2000 at 09:40:52AM -0400, Michael Maraist wrote: Many mechanisms exist to make perl code and data persistant. They should be cleaned up, unified, and documented widely within the core documentation. But doesn't this go against TMTOWTDI. :) On the one hand, there's TMTOWTDI. On the other hand, there's overly complicating things with a maze of twisty, turny modules, mostly alike. I'm not arguing against TMTOWTDI. I'm arguing that what we have isn't making easy things easy, but actually inadvertantly making easy things harder than they should be. Different people might have different requirements. Portability would want all ASCII, large apps might want compacted (if not compressed) storage, while others might want highly-efficient storage. No complaints. Why do they need to be provided by mutually exclusive sets of modules? You might want to extend this RFC to include information about existing serialization techniques (which tend to be more sophisticated than raw dumping of a data-structure). Actually, I don't. The *DBM_File modules work, as do Data::Dumper and its kin. This RFC is a request to improve the interoperability of those modules, not implement any of them from scratch. Z.
Re: RFC 288 (v1) First-Class CGI Support
On Mon, Sep 25, 2000 at 07:50:28AM +0100, Richard Proctor wrote:
On Mon 25 Sep, Perl6 RFC Librarian wrote:
Turn on tainting
What would it do on a platform that does not support Tainting?
Is this a real issue? Is there a platform where tainting isn't
supported?
Parse the CGI context, returning CGI variables into %CGI
This is a little vague, will it parse $ENV{'QUERY_STRING'}, look for
content on STDIN controlled by $ENV{'CONTENT_LENGTH'}, Cookies, the command
line? Or all of them.
All of them. Update forthcoming.
Will it handle multipart input? How will it
handle multiple inputs of the same name? etc etc.
CGI.pm has solved these problems already. I don't see these as major
issues in the feature request, just the poor wording of the RFC. ;-)
Offer simple functions to set HTTP headers (e.g. content type, result
codes)
Will there be access to do more - eg to control caching, cookies etc, will
it be optional?
All of these are handled through HTTP headers. I'll leave the
syntactical sugar to the designers and implementers of this interface.
Z.
Re: RFC 288 (v1) First-Class CGI Support
On Mon, Sep 25, 2000 at 10:09:03AM -0500, [EMAIL PROTECTED] wrote: =head1 TITLE First-Class CGI Support [...] To make CGI programming easier, this option/pragma should: Should the option/pragma also do "something" with regards to files opened for writing? They (nearly?) always require locking in a CGI environment... That is, should this feature do anything with regards to file locking? My first instinct is to say no. There is nothing inherent about file locking and CGI. CGI is a dain-bread interface for running insecure^Wremote programs. If, however, there was some sort of 'use autolock' or 'use writelock' pragma, then I suppose it would be sensible turn that on with 'use cgi' or 'perl -cgi'. Make sense? Z.
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
I personally have never had problems with these issues and would just as soon that this RFC didn't do through. However, I don't feel particularly strongly about most of it. Specifically: As to autoquoting the lefthand side of - (thereby making it a class name), I don't particularly care. The only place I use the indirect object syntax if for calls to 'new', where they read very cleanly, so I won't particularly miss them if they go away. There are certain places that I would like to see auto quoting happen. These include: 1) In a 'use' statement. 2) Inside the braces of a hash access or hash slice These places are not ambiguous, and it's a pain to have to put quotes around them every time. Dave
Re: RFC 288 (v1) First-Class CGI Support
On Mon, Sep 25, 2000 at 11:43:53AM +0100, Hildo Biersma wrote: For output generation, it becomes worse. Output generation is a separate problem space altogether. Related, but separate. Should embperl be turned on simply because I have a CGI program returning text, images or HTTP redirects? Should I get an autoformatter configured for my (unicode) locale? What about CGI.pm style table() and br() functions? Text::Template? Template Toolkit? HTML::Mason? That's a bigger problem to solve and unrelated to making Perl bind tighter to CGI invocation. Z.
Re: RFC 288 (v1) First-Class CGI Support
On Mon, Sep 25, 2000 at 03:17:33AM -0400, Alan Gutierrez wrote: On 25 Sep 2000, Perl6 RFC Librarian wrote: First-Class CGI Support First-class CGI to me means HTML::Embperl. It means a hundred different things to a hundred different Perl programmers. Especially those writing mod_perl, HTML::Mason, etc. First class CGI support means binding Perl as tighly to CGI invocation as it is to commandline invocation. Z.
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
Currently,
foo-bar($baz)
can be parsed either as C'foo'-bar($baz), or as Cfoo()-bar($baz)
depending on how the symbol Cfoo was used on other places. The proposal
is to always choose the first meaning: make C - autoquote the bareword
on the left.
Here is a question: How does this relate to getting hashrefs and
arrayrefs from functions?
if ( want-{count} 2 ) { return $one, $two }
Will that be interpreted as:
'want'-{count}
want()-{count}
To be consistent, it should mean the first one. That is, the infix
operator - should always autoquote the bareword to the left. Am I
correct in assuming that's what you meant?
-Nate
Re: RFC 288 (v1) First-Class CGI Support
Adam Turoff wrote:
I'm thinking that whether the request came from a GET or a POST,
the un(HTTP)-escaped values will be in %CGI, just as CGI::params()
does.
Like this?
$CGI{fullname} = 'Nathan Wiger';
$CGI{creditcard} = '1234-1234-1234-1234';
I'm 99% sure that's what you're saying. And I like it. :-)
HTTP headers is tricky. It's reasonably easy to figure out when
there are multiple form values in a request. It's less easy to
figure out when a program has finished emitting values for a
specific header type.
One thing that %HTTP could be used for is _incoming_ headers - for
example, 'If-Modified-Since', 'Set-Cookie', and others that a browser
throws at you. These don't go in %ENV and wouldn't belong in %CGI.
I think I'd prefer an exported function like:
http_header("Content-type" = "text/html");
http_header("Expires" = "+3 Days");
or whatever. Then it's an implementation issue to figure out
which headers are overridable, and which headers should appear
multiple times.
For output, that's probably better. However, this is treading a line
between a pragma and a lightweight module. :-{
If it imports a function, then it's a module. Perhaps what we should
look at doing is providing a lightweight CGI module instead?
The more I think about it, I actually think we could ditch outgoing HTTP
headers altogether as "not our problem", at least not in core. After
all, outgoing data content is not our issue. Data parsing and formatting
is. If people need extensive header control, they can either write a
simple function, use Format, CGI, CGI_Lite, or any of the other
bizillion modules out there, or just say:
print "Content-type: text/html\n\n";
Which works just fine and is all you need for 90+% of applications.
The idea of flushing on the first print call isn't too difficult
and kinda cool. That way, http_header() could flag a warning if
the user is trying to set a header after the header is done.
Yeah, I think that would be cool, *if* we take care of this. But I think
it's a slippery slope. After all, there are no builtins for providing
/etc/passwd formatting. I think we should provide robust input parsing,
but just general purpose output formatting tools.
-Nate
RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow grouping of -X file tests and add Cfiletest builtin
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number:
320
Status: Developing
=head1 ABSTRACT
Currently, file tests cannot be grouped, resulting in very long
expressions when one wants to check to make sure some thing is a
readable, writeable, executable directory:
if ( -d $file -r $file -w $file -x $file ) { ... }
It would be really nice if these could be grouped instead:
if ( -drwx $file ) { ... }
Notice how much easier this is to read and write.
=head1 DESCRIPTION
=head2 File Test Grouping
See above. Multiple file tests, when grouped, should be ANDed together.
This RFC does not propose a way to OR them, since usage like this:
if ( -d $file || -r $file || -w $file || -x $file ) { ... }
Is highly uncommon, to say the least.
Notice this has the nice side effect of eliminating the need for C_ in
many cases, since this:
if ( -d $file -r _ -w _ -x _ ) { ... }
Can simply be written as a single grouped file test, as shown above. If
you need to check for more complex logic, you still have to do that
separately:
if ( -drwx $file and ! -h $file ) { ... }
This is the simplest and also probably the clearest way to implement
this.
=head2 New Cfiletest Builtin
This RFC also proposes a new Cfiletest builtin that is actually what
is used for these tests. The C-[a-zA-Z]+ form is simply a shortcut to
this builtin, just like is a shortcut to Creadline. So:
if ( -rwdx $file ) { ... }
Is really just a shortcut to the Cfiletest builtin:
if ( filetest $file, 'rwdx' ) { ... }
Either form could be used, depending on the user's preferences (just
like Creadline).
=head1 IMPLEMENTATION
This would involve making C-[a-zA-Z]+ a special token in all contexts,
serving as a shortcut for the Cfiletest builtin.
=head1 MIGRATION
There is a subtle trap if you are negating subroutines:
$result = -drwx $file;
And expect this to be parsed like this:
$result = - drwx($file);
However, usage such as this is exceedingly unlikely, and can simply be
resolved by the p52p6 translator looking for C-([a-zA-Z]{2,}) and
replacing it with C- $1, since injecting a single space will break up
the token.
=head1 REFERENCES
This grew out of a discussion on RFC 290 between myself, John Allen,
Clayton Scott, Bart Lateur, and others
Re: RFC 269 (v1) Perl should not abort when a required file yields a false value
Perl6 RFC Librarian [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl should not abort when a required file yields a false value We had this RFC from Damian already didn't we? -- Piers
Re: RFC 288 (v1) First-Class CGI Support
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL All of the other features offered by Lincoln Stein's CGI.pm PRL should remain, but should not be deeply integrated into Perl6. PRL Write a very small cgi.pm module that does as little as possible, PRL probably based on Lincoln's code. on the geek cruise, lincoln told me he had almost completed a total rewrite of CGI.pm. i have not heard anything about it since then. we should find out what he has done and possibly integrate it into perl6. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
