Re: RFC 328 (v1) Single quotes don't interpolate \' and \\
On Fri, Sep 29, 2000 at 09:58:45AM +0100, Hildo Biersma wrote: =head1 ABSTRACT Remove all interpolation within single quotes and the Cq() operator, to make single quotes 100% shell-like. C\ rather than C\\ gives a single backslash; use double quotes or Cq() if you need a single quote in your string. Single-quoted strings need to be able to contain single quotes, which means some escape mechanism is required. What do you mean by "need"? Strings need to be able to contain single quotes, but single quotes are not the only way to build a string. Single and double quotes don't generate a different fundamental type; a double quoted string with no variable interpolation also generates a string constant. Having an escape system for single quotes makes it easy to embed a ' inside a string without worrying about what else would mean something special to double quote interpolation. But makes it necessary to remember the escape system, which does differ from the "" system. $ perl -lw print "\z" Unrecognized escape \z passed through at - line 1. z $ perl -lw print '\z' \z So, $line = 'This string contains both single \' and double " quotes'; needs an escape. It would be silly to have an escape character different from the backslash that everything else uses. I'm proposing *no* escape character. Not a different escape character, but a lack of escape character. It doesn't change how strings are stored internally, just how the language parser sees one particular construction that generates a string. We also need to be able to do: $line = 'This single-quoted string ends on a backslash \'; Oops. Which is why that is spelled: $line = 'This single-quoted string ends on a backslash \\'; Again, the same escape mechanism is used. Conceivably, we could say that \\ in the middle of a single-quoted string is not escaped, i.e. it means two backslashes, that that way lies madness. Agree So, I'd say, leave single quotes as they are. The two escapes are useful and required, as I've demonstrated above. They are required to build a string from single quotes. But I can write the above as $line = "This string contains both single \' and double \" quotes'; $line = "This single-quoted string ends on a backlash \\"; I don't agree that the escape is absolutely required (because there are other ways to build the string) I agree that the escapes are useful, but I also feel that they are confusing and inconsistent w.r.t. how backslashes work in double quoted strings, because backslash followed by non-special-character differs. The precise behaviour of backslash in single quote string syntax in perl is unique to perl. Double quote backslash behaviour is very close to C, double quote interpolation behaviour is close to unix shells. An alternative to either of the above could be to borrow SQL or BASIC's syntax: $line = 'This string contains both single '' and double " quotes'; $line = 'This single-quoted string ends on a backslash \'; but I don't think that this is a good idea. It might be an idea to allow the perl5 behaviour or the strict no-escape switched by a pragma. But this also is confusing, unless it's part of a more general use perl5; I've also discovered that I missed a reference - rfc226 "Selective interpolation in single quotish context." Nicholas Clark
RFC 350 (v1) Advanced I/O (AIO)
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Advanced I/O (AIO)
=head1 VERSION
Maintainer: Uri Guttman [EMAIL PROTECTED]
Date: 29 Sept 2000
Mailing List: [EMAIL PROTECTED]
Number: 350
Version: 1
Status: Developing
=head1 ABSTRACT
This RFC describes a pragma and module which support an advanced I/O
subsystem. It is meant to be a centralized subsystem that supports a
wide range of I/O requirements, many of which are covered in other
RFCs. It doesn't add any new syntax or break any existing code.
=head1 DESCRIPTION
There are many way that coders want to do I/O in Perl and many I/O
sources as well. RFC 14 discusses ways to make open smarter and to have
handlers for each flavor. The goal is good, but it requires new syntax
and semantics for open. You have effectively multiple versions of open,
each with their own argument order. It also doesn't address asynchronous
I/O or events and callbacks. I don't see how to make a socket or http
connect and not block on the request.
This RFC addresses those issues in a Perl5 way by creating a new class
with attribute based methods. This allows use to add new ways to do open
and I/O and not have to learn specialized argument formats. The style is
very similar to IO:: now but more generalized and tightly integrated in
the core. This is why I choose to call it Advanced I/O (AIO).
The main pragma will be 'use aio' and it will allow the coder to control
and load various components. I won't have the time to specify all of
them but think along the lines of RFC 14, LWP, libnet, IO::*,
LWP::Parallel, etc. Supporting them all under this single pardigm is
simple as you don't need to know more then the minimum attributes to get
your job done. Also as I have coverd some in RFC 47, many of the
attributes will have well chosen defaults which allow for shorter
argument lists for common situations. For example, instead of
$sock = IO::Socket::INET-new(PeerAddr = 'www.perl.org',
PeerPort = 'http(80)',
Proto= 'tcp');
you would do:
$sock = AIO::Open( Host = 'www.perl.org',
Port = 80 ) ;
TCP would be the default protocol as it is much more common than UDP,
and it would know it is a socket connection because of the Host/Port
attributes.
Similarly for LWP you would just do:
$sock = AIO::Open( Url = 'http://www.perl.org' ) ;
If you refer to a special attribute, it can cause the appropriate
module to be loaded at runtime. In the above case the AIO::LWP (or
whatever it is called) would get loaded and then it would be passed the
open call.
One critical feature of AIO is direct support of asynchronous I/O
(including connections, server accepts, and real asynchronous file
I/O). There is no special interface required, you just specify a
callback attribute. That makes the request automatically non-blocking
and registers the event for you. You have to had previously specified an
event dispatch method (with use event or use aio) or it is a runtime
error.
Assuming an object $foo in package Foo, the above calls can be done with
asynchronous callbacks (see RFC 321 for more on callbacks) like this:
$event = AIO::Open( Host = 'www.perl.org',
Port = 80
Callback = $obj ) ;
$event = AIO::Open( Url = 'http://www.perl.org/index.html',
Callback = $obj ) ;
Package Foo ;
sub Connected {
my( $self, $socket ) = @_ ;
print "i am connected to perl.org\n" ;
}
sub Url_gotten {
my( $self, $socket ) = @_ ;
print $socket-read( 8096 ) ;
}
Here is an asynchronous file read :
$event = AIO::Read( Fd = $fh,
Count = 1000,
Callback = \read_handler ) ;
sub read_handler {
my( $read_data ) = @_ ;
print "i read [$read_data]\n" ;
}
The callback method names are the default ones (we can pick better ones
but I am under deadline pressure!) or you can choose your own. Timeouts
can also be set with their own method names or defualt ones:
$event = AIO::Open( Url = 'http://www.perl.org/index.html',
Callback= $obj,
Method = 'Url_Ready'
Timeout = 10
Timeout_Method = 'URL_timeout' ) ;
So you see, the same simple syntax and a consistant API lets you do
blocking and non-blocking connect, I/O and timers. No need to learn
IO::, LWP and LWP::Parallel and IO::Select. All of them are covered in
under this approach and adding new attributes is easy and won't conflict
with other code written to this specification.
There is much more than can be desribed and I hope to have a
Re: RFC 350 (v1) Advanced I/O (AIO)
you would do: $sock = AIO::Open( Host = 'www.perl.org', Port = 80 ) ; Similarly for LWP you would just do: $sock = AIO::Open( Url = 'http://www.perl.org' ) ; $event = AIO::Open( Host = 'www.perl.org', Port = 80 Callback = $obj ) ; $event = AIO::Open( Url = 'http://www.perl.org/index.html', Callback = $obj ) ; I like this overall. Very nice. One of the goals in RFC 14, and the reason why I chose to go the "handler" route, is to make it look like open() had just been beefed up: $file = open "/etc/motd"; $dir = open dir "/usr/local"; $http = open "http://www.yahoo.com"; However, the under-the-hood implementation of dir-open and http-open is not explored; I was trying to create a consistent user-level interface that does not require the complex syntax shown above. And from this angle, I think RFC 14 has a lot to offer. But, one thing that I think is worth exploring is how we could merge this ideas, since I think the AIO system could well be a very viable implementation. One thing I could see is ditching the handler idea and instead just having people use URL's: $file = open "/etc/motd"; $dir = open "dir:/usr/local"; $dir = opendir "/usr/local"; # legacy shortcut $http = open "http://www.yahoo.com"; The CORE::open would be smart enough to then dispatch to the underlying AIO-open (or whatever) and do something akin what you've listed above. I like the AIO idea; if we could stick it under the hood (but still accessible, like IO::, if you really want to use it directly), I could see it implementing Perl 6 IO. One last thing: I could see a class hierarchy as being potentially most effective for something like this; perhaps you could have AIO::HTTP, AIO::File, AIO::Dir, and so on, with the main AIO class serving as the base/dispatch class. -Nate
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Thu, Sep 28, 2000 at 08:57:39PM -, Perl6 RFC Librarian wrote:
${P1} means what $1 currently means (first match in last regex)
I'm sorry that I don't have anything more constructive to say than
"ick", but ... Ick.
I'm with the 'Ick' camp too. And possibly with the 'Leave it the hell
alone! If you're that bloody stupid you deserve to lose' camp too.
--
Piers
Re: RFC 112 (v3) Asignment within a regex
On Fri, 29 Sep 2000 01:02:40 +0100, Hugo wrote:
It also isn't clear what parts of the expression are interpolated at
compile time; what should the following leave in %foo?
%foo = ();
$bar = "one";
"twothree" =~ / (?$bar=two) (?$foo{$bar}=three) /x;
It's not just that. You act as if this is assignment takes place
whenever a submatch succeeds. So:
"twofour" =~ /(?$bar=two)($foo=three)/;
Will $bar be set to "two", and $foo undef? I think not. Assignment
should be postponed to till the very end, when the match finally
succeeds, as a whole.
In general all assignments should wait to the very end, and then assign
them all. However before code callouts (?{...}) and enemies, the named
assignments that are currently defined should be made (localised) so that
the code can refer to them by name. If the expression finally fails the
localised values would unroll.
Therefore, I think that allowing just any l-value on the left of the "="
sign, is not practical. Or is it?
I think any simple scalar value is reasonable.
OTOH I would rather have that all submatches would be assigned to a
hash, not to global or lexical variables. I have no clue about what
syntax that would need.
That is in RFC 150, I think there is a case for both.
Richard
Re: RFC 112 (v3) Asignment within a regex
In [EMAIL PROTECTED], "Richard Proctor" writes: :In general all assignments should wait to the very end, and then assign :them all. [...] If the expression finally fails the localised values :would unroll. Ah, I hadn't anticipated that - I had assumed you would get whatever was the last value set. Please can you make sure this is clearly explained in the next version of the RFC? Hugo
Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching
On Fri, 29 Sep 2000 13:19:47 +0100, Hugo wrote:
I think that involves
rewriting your /p example something like:
if (/^$pat$/z) {
print "found a complete match";
} elsif (defined pos) {
print "found a prefix match";
} else {
print "not a match";
}
Except that this isn't exactly what would happen. Look, "1234E+2" is a
complete string matching the regex, but it could be that it's just a
prefix for "1234E+21". So, /^$pat$/z should fail. No? This doesn't seem
too intuitive, but that's a result from a minimal interface.
--
Bart.
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
On Thu, 28 Sep 2000, Hugo wrote:
:=item *
:/(foo)_C\1_bar/
Please don't do this: write C/(foo)_\1_bar/ or /(foo)_\1_bar/, but
don't insert C in the middle: that makes it much more difficult to
read.
Sorry; that was a global-replace error that I missed on
proofreading.
:mean different things: the second will match 'foo_foo_bar', while the
:first will match 'foo[SOMETHING]bar' where [SOMETHING] is whatever was
should be: foo_[SOMETHING]_bar
Um, yeah, it should...(jeez...I proofed this like three times,
honest!) *blush*
:captured in the Bprevious match...which could be a long, long way away,
This seems a bit unfair. It is just another variable. Any variable
you include in a pattern, you are assumed to know that it contains
the intended value - there is nothing special about $1 in this regard.
Fair enough; the point I was trying to make was that \1 was
captured right here, while $1 was capturd long, long ago in a pattern
match far, far away. The visual/cognitive difference is small, but the
programming difference is huge.
:=item *
:${P1} means what $1 currently means (first match in last regex)
Do you understand that this is the same variable as $P1? Traditionally,
perl very rarely coopts variable names that start with alphanumerics,
and (off the top of my head) all the ones it does so coopt are letters
only (ARGV, AUTOLOAD, STDOUT etc). I think we need better reasons to
extend that to all $P1-style variables.
I do understand that, and I agree with your concern. Actually, I
didn't think that ${P1} was a particularly good notation even as I was
suggesting it...I just wanted to get the RFC up there before the deadline
so that people could discuss it.
Having now thought about it more, I think that (?P1) is
better...in other words, make references to the previous pattern match be
a regex _extension_, not a core feature (if that's a valid way to phrase
the distinction).
What is the migration path for existing uses of $P1-style variables?
Wherever p526 sees a pattern that contains a $1, it should replace
it with (?P1).
:=item *
:s/(bar)(bell)/${P1}$2/ # changes "barbell" to "foobell"
Note that in the current regexp engine, ${P1} has disappeared by the
time matching starts. Can you explain why we need to change this?
Note also that if you are sticking with ${P1} either we need to
rename all existing user variables of this form, or we can no longer
use the existing 'interpolate this string' (or eval, double-eval etc)
routines, and have to roll our own for this (these) as well.
I'm a bit confused by the way this came out but, if I understand
what you're asking, then I believe your concerns are solved by the new
proposed syntax. Am I right?
:This may require significant changes to the regex engine, which is a topic
:on which I am not qualified to speak. Could someone with more
:knowledge/experience please chime in?
Currently the regexp compiler is handed a string in which $variables
have already interpolated. [...]
I know there are certain exceptions to this...my Camel III says
(something to the effect of--I don't have it in front of me) "if there is
any doubt as to whether something should be interpolated or left for the
Engine, it will be left for the Engine."
In any case, I don't think this needs to change. I'm simply
changing what the names of the variables and backreferences are...\1
becomes (the new) $1, and (the current) $1 becomes (?P1)
Changing the lifetime of backreferences feels likely to be difficult,
but it isn't clear to me what you are trying to achieve here. I think
you at least need to add an example of how it would act under s///g
and s///ge.
Good point. I'll do that.
:RFC 276: Localising Paren Counts in qr()s.
I didn't see a mention of these in the body of the proposal.
276 is rather tangentially related, I grant. However, I felt that
if my proposal went forward, it could impact on how 276 was implemented,
so I crossreferenced to it.
Dave
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
On Fri, 29 Sep 2000, Hildo Biersma wrote: Currently, C\1 and $1 have only slightly different meanings within a regex. Let's consolidate them together, eliminate the differences, and settle on $1 as the standard. Sigh. That would remove functionality from the language. The reason why you need \1 in a regular expression is that $1, $2, ... are interpolated from the previous regular expression. This allows me to do a pattern match that captures variables, then use the results of that to create a second regular expression. (Remember: A regexp interpolates first, then compiles the pattern). Umm...with all due respect, did you read the RFC? Because what I proposed does not eliminate any functionality. Dave
Re: RFC 348 (v1) Regex assertions in plain Perl code
In [EMAIL PROTECTED], Perl6 RFC Librarian writes:
:=item assertion in Perl5
:
: (?(?{not COND})(?!))
: (?(?{not do { COND }})(?!))
Or (?(?{COND})|(?!)).
Migration could consider replacing detectable equivalents of such
constructs with the favoured new construct.
:"local" inside embedded code will no longer be supported, nor will
:consitional regexes. The Perl5 - Perl6 translator should warn if it
:ever encounters one of these.
I'm not convinced that removing either of these are necessary to the
main thrust of the proposal. They may both still be useful in their
own right, and you seem to offer little evidence against them other
than that you don't like them.
I do like the idea of making (?{...}) an assertion, all the more
because we have a simple migration path that avoids unnecessarily
breaking existing scripts: wrap $code as '$^R = do { $code }; 1'.
If you want to remove support for 'local' in embedded code, it is
worth a full proposal in its own right that will explain what will
happen if people try to do that. (I think it will make perl
unnecessarily more complex to detect and disable it in this case.)
Similarly if you want to remove support for (?(...)) completely,
you need to address the utility and options for migration for all
the available uses of it, not just the one addressed by the new
handling of (?{...}).
Hugo
Re: Murdering @ISA considered cruel and unusual
Simon Cozens [EMAIL PROTECTED] writes: On Thu, Sep 28, 2000 at 02:40:04PM -0400, John Porter wrote: Tom Christiansen wrote: Perl's use of @ISA is beautiful. use base is, or can be, pretty silly -- think pseudohashes, just for one. I suppose you diddle @INC directly, Tom, instead of use'ing lib? I call "non sequitur"! I like pizza. -- Piers
Re: RFC 329 (v1) Cuse syntax
Perl6 RFC Librarian [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Cuse syntax [ ... ] =head1 ABSTRACT A pragma to modify the syntax of Perl 6 at run time. Oh yes. [...] =head1 IMPLEMENTATION First, implement 314. Then construct grammars for what we want to parse, and ensure that the parser is flexible enough to allow them as alternate grammars. =head1 REFERENCES RFC 314 Hmm... maybe this belongs in perl6-stdlib since it's talking about a library. Other than that I like it. (For "Oh my ghod that's sick yet strangely cute" values of 'like') -- Piers
Re: RFC 325 (v1) POD and comments handling in perl
It really is not feasible to relax the pod requirement that pod diretives begin with an equals to allow them to begin with a pound sign as well, for to do so would expose an untold number of programs to unpredictable effects. I also don't really see any advantage. And yes, I'm sure I'm days behind. I have no choice. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: Cya dudes
On Fri, Sep 29, 2000 at 02:34:55AM +, Ed Mills wrote: I tried to contribute on this list bu -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Term::ReadKey inclusion
It is unreasonably complicated to do single-character input in a portable fashion. We should therefore include the Term::ReadKey module in the standard distribution. Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: Cya dudes
On Fri, Sep 29, 2000 at 09:39:20AM +0100, Simon Cozens wrote: On Fri, Sep 29, 2000 at 02:34:55AM +, Ed Mills wrote: I tried to contribute on this list bu [You know, I think something went wrong there. Let's try again.] The RFC process gets you a hotline to Larry on an equal footing with all the other RFC authors. What more of a voice did you want? Sure, people play at politics; ignore them, they're not important. While people play at politics, that *by no means* implies that Perl does. -- The debate rages on: Is Perl Bachtrian or Dromedary?
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote:
The Cheader function would work very similarly to CCGI.pm's:
@HEADERS = header(content_type = 'text/html',
author = 'Nathan Wiger',
last_modified = $date,
accept = [qw(text/html text/plain)]);
This would produce an array of the following:
@HEADERS = ("Content-Type: text/html\n",
"Author: Nathan Wiger\n",
"Last-Modified: Wed Sep 27 13:31:06 PDT 2000\n",
"Accept: text/html, text/plain\n",
"\n");
Notice that the last element is a "\n" by itself, providing the
necessary blank line separating headers and content.
Hm. This makes it difficult to construct a header incrementally -- for
example, @HEADERS=(); push @HEADERS, header(content_type='a',
author='b'); # 75 lines later; push @HEADERS, header(last_modified='c',
accept='d');
Since in this case, there would be two "blank" head lines instead of just
one.
The Cheader function would simply:
1. uc the first letter of each tag token and lc the rest
Du you want to use the word "ucfirst" here?
That is, the process that Cheader does is exactly reversed, including
stripping of trailing newlines, conversion to lowercase, and so forth.
So, this call:
@out = header unheader @in;
Should result in C@out being exactly equivalent to C@in.
It cannot, of course, since the order of hash keys obtained by flattening
the hash is not necessarily the same as when you built the hash. So you
might feed in an @in with "Foo: bar" and "Hello: world", unheader it into
a hash, header it back into an array, and get "Hello: world" followed by
"Foo: bar". This may or may not be a problem.
Cheers,
Philip
--
Philip Newton [EMAIL PROTECTED]
RE: RFC 329 (v1) Cuse syntax
I briefly considered
{
use syntax "python";
}
and nearly lost my lunch.
And if you want to lose your breakfast too, consider:
use "lisp";
use "apl";
(Although if the array-processing and currying RFCs are accepted, Perl will
finally have powers beyond those of APL without having to relearn that
annoying (lack of) syntax...)
===
Mark Leighton Fisher[EMAIL PROTECTED]
Thomson Consumer ElectronicsIndianapolis IN
"Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 229 (v2) Variable interpolation on demand.
On 29 Sep 2000, Perl6 RFC Librarian wrote:
Make Perl's powerful string interpolation facilities are available to
variables, in addition to literals.
=head1 DESCRIPTION
Given:
$foo = 'def';
$bar = 'ghi';
$x = "abc$foo$bar";
$y = 'abc$foo$bar';
There is no way to turn obtain the value of $x from the value of $y.
In other words, while $foo and $bar were interpolated into $x, they
were not interpolated into $y. It would be nice to get Success! from:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
John.
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
Hm. This makes it difficult to construct a header incrementally -- for example, @HEADERS=(); push @HEADERS, header(content_type='a', author='b'); # 75 lines later; push @HEADERS, header(last_modified='c', accept='d'); Since in this case, there would be two "blank" head lines instead of just one. Yeah, Ziggy already mentioned that offlist. The Cheader function would simply: 1. uc the first letter of each tag token and lc the rest Du you want to use the word "ucfirst" here? Probably; that's what the Text::Header module I wrote as a prototype does. ;-) Should result in C@out being exactly equivalent to C@in. It cannot, of course, since the order of hash keys obtained by flattening the hash is not necessarily the same as when you built the hash. Actually, it does. Remember, a hash is just a list. unheader just returns an ordered list of the headers. So this: @out = header unheader @in; Will always result in identity because it's actually the same as: @temp = unheader @in; @out = header @temp; It's only once you assign to a hash explicitly that everything gets out of whack. -Nate
goof - RFC 328 (v1) Single quotes don't interpolate \' and \\
I goofed. (EWRONGLIST) I realise now that I should have said that RFC 328 (and 327) should have been on this list, not perl-language-data I had what I thought was a good look at previous RFCs but managed to miss RFC226 (Selective interpolation in single quotish context.) What I wanted comments about (I'm not sure if I favour it and so far 2 people have said they don't) is whether to be very strict on q// == '' == *NO* interpolation [Nathan Wiger, http://www.mail-archive.com/perl6-language@perl.org/msg04005.html ] and hence "cure" Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'? [Steve Fink, http://www.mail-archive.com/perl6-language@perl.org/msg04008.html ] by removing all \ escapes from '' and q(), to make perl's use of '' just like /bin/sh, and identical to how perl treats 'HERE' I've asked the librarian what I should do, but as there's little time left to demolish this idea, I've sent this mail here now. Nicholas Clark
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On Fri, 29 Sep 2000, Nathan Wiger wrote: Should result in C@out being exactly equivalent to C@in. It cannot, of course, since the order of hash keys obtained by flattening the hash is not necessarily the same as when you built the hash. Actually, it does. Remember, a hash is just a list. unheader just returns an ordered list of the headers. So this: @out = header unheader @in; Will always result in identity because it's actually the same as: @temp = unheader @in; @out = header @temp; It's only once you assign to a hash explicitly that everything gets out of whack. D'oh! Yes, of course. For some reason I got carried away with the hash thing. You were doing @out = header (@temp = unheader @in); and I thought you were doing @out = header (%temp = unheader @in); If you just take unheader's output and feed it to header, the order will be the same. Thanks for bearing with me ;) Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes
=head1 TITLE
Common attribute system to allow user-defined, extensible attributes
Err... have you read perldoc attributes? There's already a mechanism
for doing this (see my japh), though it is a complete PITA to use and
I'd like to see it tidied up (and possibly have attributes.pm
reimplemented, I've got a few ideas, bear with me I may have code
later that does what you want...)
--
Piers
sub MODIFY_CODE_ATTRIBUTES {print "@_[2..$#_].\n";()}
sub MODIFY_CODE_ATTRIBUTES : Just another Perl hacker
Yeah, I've gotta start clarifying my RFC's. I wrote that as a
brainstorm; with 40 to keep track of my head is spinning.
I have seen 'use attributes'. The syntax I used in the RFC was
intentionally not following 'use attributes' because I was dealing with
implementation, not declaration. And by implementation, I mean messing
with internals.
I mentioned it in an email, but neglected to say so here, but the idea
was through XS or Inline or whatever is used to extend Perl 6, there
should be some way of declaring inheritable attributes that can actually
mess with Perl's internals and twist them into obscene "we wish we were
Java" semantics.
Beyond that, I don't have much concrete. Code that could do this would
obviously be cool. ;-)
-Nate
IDEA: lexically scoped subs anyone
Did anyone suggest the following yet?
package Foo;
my sub _helper_function { ... }
sub public_function {
...
helper_function(...);
...
}
# Some other file:
use Foo;
Foo::public_function(@args); # Okay
Foo::_helper_function(@args); # Throws an exception/dies
Is it possible? Advisable?
--
Piers
Re: IDEA: lexically scoped subs anyone
On Fri, Sep 29, 2000 at 04:13:46PM +0100, Piers Cawley wrote:
Did anyone suggest the following yet?
package Foo;
my sub _helper_function { ... }
Todo:
lexically scoped functions: my sub foo { ... }
the basic concept is easy and sound,
the difficulties begin with self-referential
and mutually referential lexical subs: how to
declare the subs?
--
Um. There is no David conspiracy. Definitely not. No Kate conspiracy either.
No. No, there is definitely not any sort of David conspiracy, and we are
definitely *not* in league with the Kate conspiracy. Who doesn't exist. And
nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR
Why - cannot autoquote the LHS (was Re: RFC 244 (v1) Method calls should not suffer...)
=head1 TITLE
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.
Before I forget to mention this again, here is why - *cannot* autoquote
the LHS:
package Foo;
use overload q("") = STRING;
sub new { bless {@_}, shift; }
sub STRING {
return "Hello World!";
}
sub getdata {
# do stuff
}
package main;
my $foo = new Foo;
@data = $foo-getdata; # !!!
Unless we want that last line to fail - essentially rendering use
overload and polymorphic objects useless - then the - operator must not
autoquote the LHS.
(And if the RFC is proposing autoquoting only barewords, then I think
that's _really_ inconsistent and should not be done.)
-Nate
Re: RFC 229 (v2) Variable interpolation on demand.
"John L. Allen" wrote:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
$y = '};system "rm -rf *";qq{';
--
Robert Mathews
Software Engineer
Excite@Home
Re: RFC 288 (v2) First-Class CGI Support
Alan Gutierrez wrote: HTML::Embperl stuffs form input into a hash just as proposed here. For multiple values it creates a tab-delimited string. This will not present the above trouble with commas, since when the user, for some odd reason, enters "Ann Arbor\tMI", in most browsers the input focus will jump to the next input on tab, and the tab does not get entered into a field. Netscape on Solaris has this tabbing behavior for text fields, but allows you to enter tabs in text areas. I guess your solution would be workable, though. -- Robert Mathews Software Engineer Excite@Home
Re: RFC 229 (v2) Variable interpolation on demand.
On Fri, 29 Sep 2000, Robert Mathews wrote:
"John L. Allen" wrote:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
$y = '};system "rm -rf *";qq{';
Hmmm, hold on a second while I test that... NOT! :-)
John.
Re: Attribute access
From: "Nathan Wiger" [EMAIL PROTECTED]
Sent: Friday, September 29, 2000 12:51 AM
James Mastros wrote:
As far as setting|getting, I'd like to make a simple proposal. Consider
it
an idea for whoever writes the RFC (I'm looking at you, Nate)
Oh, jeez, as if I didn't have enough already! ;-)
Well, you did rather say you did.
The idea is this: every variable should have a psudohash of attributes.
Idea is good, implementation I think should be different. Especially
since Schwern has professed "pseudohashes must die!".
Oh, sorry. By psudohash I meant a hash that doesn't really exist as a hash
of it's own, not a hash that's really an array.
my $subsline = $sub:{line};
However, overall I think this should be hidden. The internal magic of
attributes will likely not map 1:1 to hash keys, so requiring what is
essentially an accessor function for these is probably a good thing.
The internal magic I don't know, but attributes, to me, seem close
enough to hashes that throwing away all the power of hashes seems
silly and unperlish. (After all, an object is a ref, and a stack is an
array.)
Anyway, how do you do a foreach (keys attrib $scalar)?
Best of both worlds: Have attrib return a magicly lvalueable hash
(list) in one-arg form.
That way, attributes can be applied to objects, packages, subs, and
other things that don't have variable representations:
Hmm... I thought that a sub was a variable with a funny-char (with
some oddities, such as sub calling sub and giving that value, rather
then sub itself), and "An object is simply a reference that happens
to know which class it belongs to".
As to packages, I'd set the attributes on their namespace hash --
%%package::name:::{'fluffy'}++; (Three colons on the end.)
OK, that's pretty ugly, I'll admit, which is why the alternate syntax is
there.
The declaration of attrs is proposed vaguely in RFC 337. I'll add access
before the freeze.
Gah, I forgot that one.
Hmm, in 279, you propose a syntax like this:
LVALUE : ATTRIBUTE;
However, this syntax would make this:
$a[0] :32bit = get_val; # 32-bit
reasonably mean
Get the current value of $a[0], set the 32bit attribute on it,
and then replace that value with the return of the get_val
function.
This would end up making $a[0] = get_val with no attributes,
since the return of the get_val function (assumedly) has no
attributes.
-=- James Mastros
Accessing perl's command line switches
In a perl program I found the need to determine the command line swithches passed to perl to be used to invoke the program. But I couldn't find anything that gave this. There is $^X but that's limited. I needed to reinvoke perl with all the -S and -I etc. commands. (I needed a daemon that could reload itself, but without the -S and -I commands the runtime environment is not fully reflected. And if running under -T the enviornment is not trusted.) Is there something there already? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 288 (v2) First-Class CGI Support
* Philip Newton ([EMAIL PROTECTED]) [30 Sep 2000 02:47]: On 28 Sep 2000, at 21:36, iain truskett wrote: [] It's a case of: if you're going to have the output order, then you should provide for the input to be ordered. *As well as* unordered. Sorry, I don't follow your line of reasoning. Why should having the output ordered influence what I want to see the input as? They're two different things; the output is aimed for the HTTP user agent, and the input is aimed (at the web server and then) for me. Two different sets of requirements. You accepted that output should be ordered, in case of new HTTP protocol versions that may have a particular order requirement for headers. Surely such a requirement of output headers would also be a requirement for input headers? The order of them is just as important as the output headers. [...] However, the protocol on incoming headers is mainly significant between the HTTP user agent and the web server; once it gets to me, I don't care about the protocol any more -- the web server took care of that already. So the input headers can be unordered for all I care. For all your care, yes. Others may have different requirements, and those requirements may change with new HTTP revisions. Again, I don't do CGI much -- there may be people who want the exact headers in the exact order. For me, knowing what the "User-Agent:" header and what the "Accept-Charset:" header (or whatever) say is sufficient, and I don't care whether one is before or after the other. Again --- that's you. This RFC is for all of us. At the very least, include the opposing arguments so that Larry can see that there were multiple factions. I'm thinking a $headers_in and a $headers_out type thing is needed No comment on this one. Might be good, might not be; don't want to evaluate it right now. I just didn't want to snip it. =) Objects are good (in some respects). Having a %HTTP and a @HEADERS is rather simplistic and not really that accommodating for potential modifications to the protocols for HTTP and CGI. Possibly true. However, I believe that headers will still follow the "Key: Value" style, so @HEADERS should not be affected (if the programmer has to specify the order, that is -- then she can still do so in the future). And %HTTP may not need to be ordered. So you're saying that @HEADERS (the output one) can quite happily be ordered (which it is by default) or unordered, erring on the side of ordered; while on the other hand you're saying that %HTTP (input) may not need to be ordered (just as it may need to be ordered), erring on the side of unordered. Don't take this the wrong way, but you are being hypocritical in your treatment of input and output headers. In other words, the input has an order (the order in which the user- agent sent the headers), but I'm not necessarily interested in it (frequent CGI programmers may have different needs); Precisely. So theoretically, we should provide for both situations. Well, if you provide it ordered, you *are* providing for both situations -- those who want it ordered have it ordered, and those who don't care about the order will be happy, too. After all, I didn't say "I explicitly want it unordered" or "ordered according to the hash of each header field". But a %HTTP is the only variable you're giving us, which (by its nature) is unordered. I still free that objects are the way to go. At the very least both array and hash variables should be exposed; ideally two scalars that are object references. cheers, -- iain truskett, aka Koschei. http://eh.org/~koschei/ You know you are addicted to coffee if: 12 You don't sweat, you percolate.
Re: IDEA: lexically scoped subs anyone
On 29 Sep 2000, Piers Cawley wrote: Is it possible? Advisable? I haven't seen it yet, but that doesn't mean it's not in there somewhere...there's a bunch of RFCs I haven't had time to read. If it isn't there, it should be. I think this is definitely a cool idea. Dave
RFC 328 (v2) Single quotes don't interpolate \' and \\
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Single quotes don't interpolate \' and \\ =head1 VERSION Maintainer: Nicholas Clark [EMAIL PROTECTED] Date: 28 Sep 2000 Last Updated: 29 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 328 Version: 2 Status: Developing =head1 CHANGES Reissued on [EMAIL PROTECTED] - I goofed the list. Added discussion section Clarified the description slightly; by single quoted string I mean '' and q() =head1 DISCUSSION Limited discussion so far because I wrongly issued the RFC to [EMAIL PROTECTED] The only responses were from two people both of whom valued their ability to use single quotes to make strings including making strings containing single quotes. Here docs already provide a means to get "quote nothing, everything is literal". One argued that Single-quoted strings need to be able to contain single quotes, which means some escape mechanism is required. which I did not agree with. My view is that single quotes are a means to an end, a way to create string constants. String constants need to contain C' (and every other character). There's more than just '' to make a string. Although consensus so far is against the change, views were from Bexisting perl users [who do you expect as the majority on perl6 lists? :-)]. The change would penalise existing perl users, but benefit new perl users (and presumably people teaching perl). =head1 ABSTRACT Remove all interpolation within single quotes and the Cq() operator, to make single quotes 100% shell-like. C\ rather than C\\ gives a single backslash; use double quotes or Cq() if you need a single quote in your string. =head1 DESCRIPTION Camel III (page 7) says "Double quotation marks (double quotes) do Ivariable interpolation and Ibackslash interpolation while single quotes suppress interpolation." Page 60 qualifies this with "except for C\' and C\\". In perl single quotes are used to generate strings. Double quotes also generate strings. In C single quotes are used to make character constants. Double quotes are used to make string constants. Backslash interpretation is performed in single quotes in C. While multi-character constants are allowed by C, they are strongly discouraged as they are non-portable, and a character constant in C is a type distinct from a string constant. Hence double quotes and single quotes signify different things. In shell, single quotes are used to make strings. Double quotes also make strings. Within single quotes backslashes are ordinary characters, and do not quote anything. As one can't quote a C' with a C\ there is no way to interpolate a single quote within a single quoted string, but a workaround such as C'don'\''t' relying on the concatenation of C'don' C\' and C't' achieves the desired results. Hence perl's single quoted strings are analogous to shell's single quoted strings, not C's. However, they're not identical, as perl allows C\\ to mean an embedded C\, C\' to mean an embedded C'. This RFC argues that the exception is confusing and proposes to remove it. This makes perl more regular in shell terms, and slightly more easy to learn for the shell programmer. It also makes perl internally simpler more regular. Currently the behaviour for Cq() strings is that C\( C\) and C\\ map to 1 character, C\I? for all other I? maps to 2 characters. Cqq() differs as C\I? maps to 1 character both when I? is recognised as a backslash escapes, Band when it is unrecognised. A further irregularity is that currently single quoted here docs don't interpolate C\\ or C\'. The consequence of this is that currently 'foo\\bar' eq 'foo\bar' which sure looks odd. With this RFC it is proposed that in a single quoted string and the q() operator C\ is not special. Hence C\I? always maps to 2 characters (C\ then I?) unless I? is the closing terminator, in which case the string terminates with that C\ . Single quoted strings behave like single quoted here docs, and like shell single quoted strings. You don't lose any functionality, as 'don\'t implement this RFC, the benefits don\'t outweigh the confusion' can still be written q(don't implement this RFC, the benefits don't outweigh the confusion) which is actually less typing. =head1 IMPLEMENTATION Modify the tokeniser/lexer not to treat C\ as special, hence the first end delimiter ends the string. For 5.7's toke.c this doesn't appear that simple. it looks like modifications would be needed to CS_tokeq, Cscan_str and CPerl_yylex (for a quoted string at the start of curlies). There are probably more; the code that makes single quoted strings interpolate C\' and C\\ appear to be deeply ingrained into the core. The perl5 to perl6 convertor would need to convert single quoted strings and Cq() operators containing C\' to the shortest (clearest?) equivalent of: =over 4 =item * double quoted string with C\Q...C\E or C\ escapes =item * single quoted
RFC 259 (v1) Builtins : Make use of hashref context for garrulous builtins
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins : Make use of hashref context for garrulous builtins
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 19 Sep 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 259
Version: 1
Status: Frozen
Frozen since: v3
=head1 ABSTRACT
This RFC proposes the builtin functions that return a large number of
values in an array context should also detect hashref contexts (see RFC
21) and return their data in a kinder, gentler format.
=head1 DESCRIPTION
It's hard to remember the sequence of values that the following
builtins return:
stat/lstat
caller
localtime/gmtime
get*
and though it's easy to look them up, it's a pain to look them up
Every Single Time.
Moreover, code like this is far from self-documenting:
if ((stat $filename)[7] 1000) {...}
if ((lstat $filename)[10] time()-1000) {...}
if ((localtime(time))[3] 5) {...}
if ($usage (getpwent)[4]) {...}
@host{qw(name aliases addrtype length addrs)} = gethostbyname $name;
warn "Problem at " . join(":", @{[caller(0)]}[3,1,2]) . "\n";
It is proposed that, when one of these subroutines is called in the new
HASHREF context (RFC 21), it should return a reference to a hash of values,
with standardized keys. For example:
if (stat($filename)-{size} 1000) {...}
if (lstat($filename)-{ctime} time()-1000) {...}
if (localtime(time)-{mday} 5) {...}
if ($usage getpwent()-{quota}) {...}
%host = %{gethostbyname($name)};
warn "Problem at " . join(":", @{caller(0)}{qw(sub file line)} . "\n";
=head2 Standardized keys
The standardized keys for these functions would be:
=over 4
=item Cstat/Clstat
'dev' Device number of filesystem
'ino' Inode number
'mode' File mode (type and permissions)
'nlink' Number of (hard) links to the file
'uid' Numeric user ID of file's owner
'gid' Numeric group ID of file's owner
'rdev' The device identifier (special files only)
'size' Total size of file, in bytes
'atime' Last access time in seconds since the epoch
'mtime' Last modify time in seconds since the epoch
'ctime' Inode change time in seconds since the epoch
'blksize' Preferred block size for file system I/O
'blocks'Actual number of blocks allocated
=item Clocaltime/Cgmtime
'sec' Second
'min' Minute
'hour' Hour
'mon' Month
'year' Year
'mday' Day of the month
'wday' Day of the week
'yday' Day of the year
'isdst' Is daylight savings time in effect
(localtime only)
=item Ccaller
'package' Name of the package from which sub was called
'file' Name of the file from which sub was called
'line' Line in the file from which sub was called
'sub' Name by which sub was called
'args' Was sub called with args?
'want' Hash of values returned by want()
'eval' Text of EXPR within eval EXPR
'req' Was sub called from a Crequire (or Cuse)?
'hints' Pragmatic hints with which sub was compiled
'bitmask' Bitmask with which sub was compiled
=item Cgetpw*
'name' Username
'passwd'Crypted password
'uid' User ID
'gid' Group ID
'quota' Disk quota
'comment' Administrative comments
'gcos' User information
'dir' Home directory
'shell' Native shell
'expire'Expiry date of account of password
=item Cgetgr*
'name' Group name
'passwd'Group password
'gid' Group id
'members' Group members
=item Cgethost*
'name' Official host name
'aliases' Other host names
'addrtype' Host address type
'length'Length of address
'addrs' Anonymous array of raw addresses in 'C4' format
=item Cgetnet*
'name' Official name of netwwork
'aliases'
RFC 264 (v3) Provide a standard module to simplify the creation of source filters
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Provide a standard module to simplify the creation of source filters
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 20 Sep 2000
Last Modified: 29 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 264
Version: 3
Status: Frozen
Frozen since: v2
=head1 ABSTRACT
This RFC proposes that the interface to Perl's source filtering facilities
be made much easier to use.
=head1 DESCRIPTION
Source filtering is an immensely powerful feature of recent versions of Perl.
It allows one to extend the language itself (e.g. the Switch module), to
simplify the language (e.g. Language::Pythonesque), or to completely recast the
language (e.g. Lingua::Romana::Perligata). Effectively, it allows one to use
the full power of Perl as its own, recursively applied, macro language.
The Filter::Util::Call module (by Paul Marquess) provides a usable Perl
interface to source filtering, but it is not nearly as simple as it could be.
To use the module it is necessary to do the following:
=over 4
=item 1.
Download, build, and install the Filter::Util::Call module.
=item 2.
Set up a module that does a Cuse Filter::Util::Call.
=item 3.
Within that module, create an Cimport subroutine.
=item 4.
Within the Cimport subroutine do a call to Cfilter_add, passing
it either a subroutine reference.
=item 5.
Within the subroutine reference, call Cfilter_read or Cfilter_read_exact
to "prime" $_ with source code data from the source file that will
Cuse your module. Check the status value returned to see if any
source code was actually read in.
=item 6.
Process the contents of $_ to change the source code in the desired manner.
=item 7.
Return the status value.
=item 8.
If the act of unimporting your module (via a Cno) should cause source
code filtering to cease, create an Cunimport subroutine, and have it call
Cfilter_del. Make sure that the call to Cfilter_read or
Cfilter_read_exact in step 5 will not accidentally read past the
Cno. Effectively this limits source code filters to line-by-line
operation, unless the Cimport subroutine does some fancy
pre-pre-parsing of the source code it's filtering.
=back
This last requirement is often the stumbling block. Line-by-line
source filters are not difficult to set up using Filter::Util::Call,
but line-by-line filtering is the exception, rather than the norm.
Since a newline is just whitespace throughout much of a Perl program,
most useful source filters have to make allowance for components that
may span two or more newlines. And that complicates the filtering code
enormously.
For example, here is a minimal source code filter in a module named
BANG.pm. It simply converts every occurrence of the sequence CBANG\s+BANG
(which may include newlines) to the sequence Cdie 'BANG' if $BANG in
any piece of code following a Cuse BANG; statement (until the next
Cno BANG; statement, if any):
package BANG;
use Filter::Util::Call ;
sub import {
filter_add( sub {
my $caller = caller;
my ($status, $no_seen, $data);
while ($status = filter_read()) {
if (/^\s*no\s+$caller\s*;\s*$/) {
$no_seen=1;
last;
}
$data .= $_;
$_ = "";
}
$_ = $data;
s/BANG\s+BANG/die 'BANG' if \$BANG/g
unless $status 0;
$_ .= "no $class;\n" if $no_seen;
return 1;
})
}
sub unimport {
filter_del();
}
1 ;
Given this level of complexity, it's perhaps not surprising that source
code filtering is not commonly used.
This RFC proposes that a new standard module -- Filter::Simple -- be
provided, to vastly simplify the task of source code filtering,
at least in common cases.
=head2 The Filter::Simple module
Instead of the above process, it is proposed that the Filter::Simple module
would simplify the creation of source code filters to the following
steps:
=over 4
=item 1.
Set up a module that does a Cuse Filter::Simple sub { ... }.
=item 2.
Within the anonymous subroutine passed to Cuse Filter, process the
contents of $_ to change the source code in the desired manner.
=back
In other words, the previous example, would become:
package BANG;
use Filter::Simple sub {
s/BANG\s+BANG/die 'BANG' if \$BANG/g;
};
1 ;
=head2 Module semantics
This drastic simplication is achieved by having the standard
Filter::Simple module export into the package that Cuses it (e.g.
package "BANG" in the above example) two automagically constructed
subroutines -- Cimport and Cunimport -- which take care of all the
nasty details.
In addition, the generated Cimport subroutine
Re: RFC 229 (v2) Variable interpolation on demand.
"David L. Nicol" wrote: it's not a new feature. It's amazing the subtle control you can get with s/(\$...)/$1/ge depending on your You mean /gee, right? Hadn't thought of that. /ee makes my brain hurt. -- Robert Mathews Software Engineer Excite@Home
Re: RFC 328 (v2) Single quotes don't interpolate \' and \\
=head1 ABSTRACT Remove all interpolation within single quotes and the Cq() operator, to make single quotes 100% shell-like. C\ rather than C\\ gives a single backslash; use double quotes or Cq() if you need a single quote in your string. Yes. If people really need single quotes inside single quotes, why not just put them in q() ?? $need_singles = q(Why don't y'all just put 'em in here?); The difference between '' and q() is that the second is a more flexible alternative. If you really need to put single quotes inside single quotes, use it. But '' and q() should become true strict single quotes. Having them do \ interpolation is not good, it defeats the notion. It was needed in the past, but now there's q(), so it's not needed anymore. Migration with this is fairly easy, run something like this: s/'(.*?\\'.*?)'/q($1)/g; in the translator script. This doesn't catch all the cases, but writing a more comprehensive one shouldn't be too hard. -Nate
Re: RFC 328 (v2) Single quotes don't interpolate \' and \\
On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: Although consensus so far is against the change, views were from Bexisting perl users [who do you expect as the majority on perl6 lists? :-)]. The change would penalise existing perl users, but benefit new perl users (and presumably people teaching perl). I'm not sure if this means you don't care about the opinions of existing Perl programmers or not, but perhaps you would like an opinion from a different direction. I hate the shell's single-quoting method. If I have anything with single quotes in it (usually Perl oneliners, but that's neither here nor there) I have to find some alternative. Usually I have to go back, change the quoting to "", and escape everything inside the single quotes. This is incredibly annoying. With Perl it could be marginally better, what with the q// construct, but it still means that when I have a single quote internally I have to go back and change my delimiter, and verify I'm not using that same delimiter in the string. Whew. Disallowing escapes in a single-quote string does not make easy things easier and hard things possible. The only thing it does is serve to make a shell programmer's introduction to Perl easier, maybe. Is this really a reason to take a feature away from the rest of us? Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 351 (v1) Beyond the amnesic eval
On Fri, Sep 29, 2000 at 09:47:00PM -, Perl6 RFC Librarian wrote:
Classic eval:
eval {}
eval ""
Unscoped eval
+eval {}
+eval ""
I like the general idea of this RFC, but the proposed syntax is less than
desirable. What happens with the following?
$result = 20+eval"$x $op $y";
Perhaps instead of +eval, consider unscoped_eval, or some such.
Or perhaps this should be generalized into a pragma for indicating the
current scope is actually the scope just above it. I believe this idea was
proposed and batted around when the lists were first started; I don't recall
what became of it.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 328 (v2) Single quotes don't interpolate \' and \\
Perl6 RFC Librarian wrote : || =head1 TITLE || || Single quotes don't interpolate \' and \\ || || =head1 VERSION || || Maintainer: Nicholas Clark [EMAIL PROTECTED] || Date: 28 Sep 2000 || Last Updated: 29 Sep 2000 || Mailing List: [EMAIL PROTECTED] || Number: 328 || Version: 2 || Status: Developing [ ... ] || =head1 DISCUSSION || || Limited discussion so far because I wrongly issued the RFC to || [EMAIL PROTECTED] The only responses were from two people both || of whom valued their ability to use single quotes to make strings including || making strings containing single quotes. Here docs already provide a means to || get "quote nothing, everything is literal". One argued that || || Single-quoted strings need to be able to contain single quotes, || which means some escape mechanism is required. || || which I did not agree with. Being able to create strings that contain arbitrary characters is essential for program generators. With the current quoting method, you can take a string, preface any ' or \ with a \, wrap the result with '' and you're ready to insert it into the code you're creating. With the proposed definiton, you'd have to use a q## form, after scanning the string in hopes of finding a character, like #, that wasn't contained in the string. With a here document, you'd instead have to ensure that you create an end of here doc token that doesn't happen to be contained as a line in the string. (Here doc strings are also awkward for some purposes, having the actual content of the string on a separate line interferes with the normal flow for reading the code, unless the string is multi-line data.) -- Sleep should not be used as a substitute| John Macdonald for high levels of caffeine -- FPhlyer | [EMAIL PROTECTED]
Re: RFC 339 (v1) caller-eval BLOCK
caller-eval EXPRESSION;
That's mad, bad, scary and dangerous. Let's do it.
Yes, this is cool. In fact, I'm writing Regexp::Func right now as a
prototype for RFC 164 and discovering I could really use this - in fact,
need it.
A couple things:
1. Implement this eval as UNIVERSAL::eval. Then...
2. Change the above syntax to self-eval(EXPR)
No reason to have to change caller(). If we had a self() that can be
called anywhere and returned a reference to the corresponding
package/parent namespace (like RFC 152's), then this works dandy. Then
UNIVERSAL::eval is simply invoked via simple inheritance. Presto:
package Regexp::Func;
sub replace (;$@) {
# By default, strip leading/trailing whitespace
my $pat = shift || '/(?:^\s+|\s+$)//g';
my @in = @_ ? @_ : $_;
# Just a simple eval is all we need
_pattern_check($pat);
for (my $i=0; $i @in; $i++) {
self-eval("\$in[$i] =~ s$pat;"); # Yes!!
do { chomp $@; croak $@, " in replace" } if $@;
}
# Always return the first string in scalar
wantarray ? return @in : return $in[0];
}
Yeah, I could really use this. ;-)
-Nate
Re: RFC 328 (v2) Single quotes don't interpolate \' and \\
At 04:22 PM 9/29/00 -0700, Damien Neil wrote: On Fri, Sep 29, 2000 at 09:20:23PM -, Perl6 RFC Librarian wrote: Single quotes don't interpolate \' and \\ I rather like the Python triple-quote mechanism used for this purpose: $foo = """Things like ', ", and \ have no special meaning in here."""; Of course, this doesn't help if you want to include three "s in a row in your string. : Argh! *NO*! That way lies madness, or at least DCL's quoting mania. My record, in a command procedure that wrote other command procedures that submitted command procedures to batch, was 13 quotes in a row. Let's *not* go there, thanks. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: RFC 327 (v2) C\v for Vertical Tab
- -Original Message- - From: Russ Allbery [mailto:[EMAIL PROTECTED]] - - Perl6 RFC Librarian [EMAIL PROTECTED] writes: - - However, lack of C\v represents a special case for a C programmer to - learn. C\v isn't used for anything else in double quoted - strings, nor - is it used in regular expressions, so it won't require removal of an - existing feature to add it. Currently a C\v in a double - quoted strings - will be treated as Cv, with a warning about unknown escape issued if - warnings are in force. - - Vertical tab was also omitted from the range of characters considered - whitespace by C\s in regular expressions. - - Just out of curiosity, and I'm not objecting to this RFC, has anyone - reading this mailing list actually intentionally used a vertical tab for - something related to its supposed purpose in the past ten years? I don't even know what a vertical tab is, it doesn't sound like anything very useful.
Re: RFC 327 (v2) C\v for Vertical Tab
David Olbersen [EMAIL PROTECTED] writes: From: Russ Allbery [mailto:[EMAIL PROTECTED]] Just out of curiosity, and I'm not objecting to this RFC, has anyone reading this mailing list actually intentionally used a vertical tab for something related to its supposed purpose in the past ten years? I don't even know what a vertical tab is, it doesn't sound like anything very useful. It advances the paper of your hardcopy terminal a terminal-setting- defined number of lines, usually about eight. The last time I used a vertical tab intentionally and for some productive purpose was about 1984. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 303 (v1) Keep Cuse less, but make it work.
On 27 Sep 2000, Piers Cawley wrote: Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote: Don't change "use less" to "use optimize". We don't need to ruin the cuteness. "use less 'rolled_loops';" sounds really weird. We obviously need to introduce a synonymous Cuse fewer 'rolled_loops' for when we want to be grammatically correct. Or am I just being silly now? C use less 'recursion' sounds just find to me. The negation of C use less 'rolled_loops' , C use more 'unrolled_loops' , does not sound very weird at all. Weren't we planning on haveing a use more as an opposite of use less? If so, let cuteness prevail! Alan Gutierrez
Re: RFC 351 (v1) Beyond the amnesic eval
=head1 ABSTRACT An unscoped eval is needed. It is part of the necessary steps to make Perl palatable as an interactive shell. I agree with Michael that the syntax is not suitable. If it's a separate function, then it needs to be a \w+ name. You should check out RFC 339 - it talks about a very similar extension to eval. The two might be able to be integrated. -Nate
Re: RFC 288 (v2) First-Class CGI Support
* Nathan Wiger ([EMAIL PROTECTED]) [29 Sep 2000 02:14]: A future protocol could well require things in order. Hence you're having the output headers in order. Therefore you should have the input ones available in order as well. I don't see a reason why an @HTTP ordered and %HTTP unordered couldn't both be supported. Neither can I =) [...] Having a %HTTP and a @HEADERS is rather simplistic and not really that accommodating for potential modifications to the protocols for HTTP and CGI. I'm not sure I agree. The goal is to make this stuff easy for the majority of cases. We're certainly not going to get everybody's needs with this simple pragma. Indeed not. In some cases, not even our basic needs. The idea is to make it so "use cgi" lets you write a simple CGI script. One that can fluidly parse every header and is fully extensible per the newest HTTP/6.73 spec? Nope, then it's module time. Such as good ol' CGI.pm, or the appropriate mod_perl module. I'm still failing to see the point of most of this RFC. It doesn't really appear to do anything that isn't done better elsewhere and I'm on the school of thought "If you have good stuff, then don't add not-so-good stuff". Stuff that's in the core should be building blocks off of which other stuff can be based. Providing @HTTP and %CGI is great, because then modules can just "use cgi" and parse those thing up, without having to read from STDIN and do all the GET/POST special stuff. Or they can just grab stuff using CGI.pm... Or someone could split CGI.pm up so that there's CGI::FormValues and CGI::HTTPHeaders. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ A library is a hospital for the mind. Anonymous
Re: RFC 288 (v2) First-Class CGI Support
On Fri, 29 Sep 2000, Robert Mathews wrote: Alan Gutierrez wrote: HTML::Embperl stuffs form input into a hash just as proposed here. For multiple values it creates a tab-delimited string. This will not present the above trouble with commas, since when the user, for some odd reason, enters "Ann Arbor\tMI", in most browsers the input focus will jump to the next input on tab, and the tab does not get entered into a field. Netscape on Solaris has this tabbing behavior for text fields, but allows you to enter tabs in text areas. I guess your solution would be workable, though. Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter, has ideas about this? Another problem, regardless of array refs or tab-delim. A hash %CGI does not address keyword parameters: http://www.foo.com/cgi-bin/search?bar+baz Does this give us an array @CGI? Alan Gutierrez
Re: RFC 288 (v2) First-Class CGI Support
* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:47]: [...] Pity about Solaris. I wonder if Gerard Richter, HTML::Embperl mainter, has ideas about this? Does it really matter since it's a textarea? Typically you know which fields are only going to have one value and can just not split the field at tabs. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ I Xander: But we were going to have a romantic evening! Anya: We were going to light lots of candles and have sex near them!
Re: RFC 288 (v2) First-Class CGI Support
On Sat, 30 Sep 2000, iain truskett wrote: Or someone could split CGI.pm up so that there's CGI::FormValues and CGI::HTTPHeaders. By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC this? Do you think Mr. Stien would think us pushy? IMHO this thread is discussing the implementation of a module, lets have an RFC that frames it that way. Alan Gutierrez
Re: RFC 288 (v2) First-Class CGI Support
* Alan Gutierrez ([EMAIL PROTECTED]) [30 Sep 2000 14:55]: On Sat, 30 Sep 2000, iain truskett wrote: Or someone could split CGI.pm up so that there's CGI::FormValues and CGI::HTTPHeaders. By jove Mr. Truskett, that sounds like a smashing idea! Could we RFC this? Do you think Mr. Stien would think us pushy? If you want and no, respectively. Mind you, I'd be more inclined just to ask Mr Stien and forego Yet Another Perl RFC. I feel the Perl 6 RFCs should just track stuff that is specific to Perl 6. These CGI::* modules should be quite capable of being used in Perl 5. IMHO this thread is discussing the implementation of a module, lets have an RFC that frames it that way. Sounds good. The less that is in core and the more that is in modules, the better, I think. Core doesn't need to split up CGI stuff. That could be tortuous if future HTTP protocols change their requirements (which is quite possible). Someone posited that perl6 should be the final version of perl (with versions converging on 2*pi iirc). The more that is in modules, the more easily this is accomplished. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ Q: How do I block warnings? A: The simplest way is to do: close STDERR; -- perliaq.
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
On 28 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Add Cheader and Cunheader funtions to core distribution =head2 Location These are such lightweight functions that their impact on core would be negligible. As such, they could potentially be put directly into it, since they are just formatting functions compliant with open standards. They are lightweight functions so is there an enormous benifit to having them in the core implemented in C? Indeed they are just formatting functions, not primitives. There may be many applications for them, but there are many applications for Carp, Getopts::Long, File::Find, etc. It is an application specific function. This slope is slippery. Alan Gutierrez
Re: RFC 339 (v1) caller-eval BLOCK
Perl6 RFC Librarian [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE caller-eval BLOCK =head1 VERSION Maintainer: David Nicol [EMAIL PROTECTED] Date: 28 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 339 Version: 1 Status: Developing =head1 ABSTRACT Ccaller is extended to allow complete access to the "call frame" of the current subroutine call. =head1 DESCRIPTION Some new syntax is introduced, involving the Ccaller keyword, that allows evaluation of expressions from the point of view of the situation from which the current method was called. After thinking about it for a while I think caller-eval EXPRESSION; would work well, with the prototype and semantics of this construction being identical to regular Ceval, except that resolution of names is done as if the eval was happening where the call happened. That's mad, bad, scary and dangerous. Let's do it. -- Piers
Re: Cya dudes
"Ed Mills" [EMAIL PROTECTED] writes: I tried to contribute on this list but it seems we've coalesced downto Tom and a handful of others. No one else has a voice. Hmm... not my experience. But then I've only seen your message here because of Simon's response to it, my spamfilter sees your stuff as coming from a forged hotmail address, which makes it kind of tricky for me at least to respond to your ideas 'cos I don't check my spamhole that often. (Though I'm going to have to do that if I want to see your reply to this...) I have nothing but respect for Tom, Nathan, et al, but its no longer my idea of a community - more like a faction. I'm getting more into PHP now and less into Perl, only because PHP evolution seems to be acccelerated by novelty, and not mired into a few people's ideas. The politics of Perl are: A Suggestion... Did Tom or Larry or Uri or someone we all know make it? Yes? Unfold into myriad threads about the wonder of the idea.. No? Don't respond to it, its unworthy.. Hmm. I can't speak for anyone else, but my modus operandi has been: Is it an RFC? Do the title/abstract look like something I'm interested in? If yes, read through and comment if there's anything particularly good or particularly boneheaded in it. If it just looks okay then there's no need to comment. After that keep checking the threads on RFCs I'm interested in and keep my eyes open for any particularly active threads attached to RFCs I haven't looked at and maybe have a look at the root RFC to see if it's really something I'm interested in. Yes, comments from the likes of Damian, Larry et al tend to make me sit up and take more notice, but that's because what they say has been good in the past, I'm only human after all. And yes, I sometimes miss RFCs that I should have commented on earlier (see my comments to the recently frozen one about $#) As for my own RFCs, I don't think of myself as a perl 'name'; I've only really become active on the perl6 lists (it's been ages since I posted to clpm or p5p for instance) but I've seen healthy discussion of the ones I've put forward (and looking back in the archive I see a fair bit of discussion of the println thing you suggested for instance. Nothing but respect for all of you here, and particularly those who I met in Monterray this year at Open Source. I just want to move into an arena of ideas, and not politics. I'll still use Perl but only as my secondary scripting now. PHP is my future because the little guy still has a voice. Sorry to make that statement as I committed so much time and effort to Perl and it's community, but I think, in the end, its only a place where genius has a voice. Sometimes good ideas come out of the masses and litle guys like me. I was good enough to complete 2 graduate programs at State universities in Comp Sci, and I suppose I ought to be good enough to be heard by a programming community. PHP listens, Perl talks. Maybe the PHP folks have less vigorous spam filters. -- Piers
Re: Cya dudes
Piers Cawley [EMAIL PROTECTED] writes: "Ed Mills" [EMAIL PROTECTED] writes: I tried to contribute on this list but it seems we've coalesced downto Tom and a handful of others. No one else has a voice. Hmm... not my experience. But then I've only seen your message here because of Simon's response to it, my spamfilter sees your stuff as coming from a forged hotmail address, which makes it kind of tricky for me at least to respond to your ideas 'cos I don't check my spamhole that often. (Though I'm going to have to do that if I want to see your reply to this...) Worse, I've just worked out *why* the spamfilter is catching your messages (which are obviously *not* forged) and disabled that rule, which would appear to catch anything that's sent to mailing lists like this one that do a resend with new(ish) headers. Mea culpa. -- Piers
Re: RFC 337 (v1) Common attribute system to allow user-defined, extensible attributes
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Common attribute system to allow user-defined, extensible attributes
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 337
Version: 1
Status: Developing
=head1 ABSTRACT
Camel-3 and others have proposed a syntax for declaring variables like
so:
my type $var :attr1 :attr2 = $val;
However, nobody has really nailed down what C:attr1 and C:attr2 are
supposed to do. This takes a shot at it, since this could simplify the
implementation of BRFC 188, BRFC 336, BRFC 163, and others.
Err... have you read perldoc attributes? There's already a mechanism
for doing this (see my japh), though it is a complete PITA to use and
I'd like to see it tidied up (and possibly have attributes.pm
reimplemented, I've got a few ideas, bear with me I may have code
later that does what you want...)
--
Piers
sub MODIFY_CODE_ATTRIBUTES {print "@_[2..$#_].\n";()}
sub MODIFY_CODE_ATTRIBUTES : Just another Perl hacker
