Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
Ilya Zakharevich wrote: so what is wrong with the statement '@y = 3*@x;' then ? That other constructs *also* create an array context, in which the behaviour of multiplication you propose is not appropriate. for example? I did not see any viable proposal on changing things in a major way. To design such a change is a *major* work. We need to keep a lot of possible combinations with other features in mind, and understand all the ramifications and desired/undesired interaction. We need insight. We need to balance the tradeoffs. This is what will happen no doubt, and what will emerge will probably be less than the radicals hope for and more than the conservatives would want! I did not mean interviews. 10 years ago I read the manual. It was clearly there. I am sure it was, the guy is nuts. Karl.
RFC Freeze
In 2 and a bit days all RFCs must be frozen--those not frozen will be auto-retracted by the librarian! So, could you please freeze your RFCs--the following have some still outstanding: Ilya Zakharevich [EMAIL PROTECTED] 8 David Nicol [EMAIL PROTECTED] 2 Buddha Buck [EMAIL PROTECTED] 1 pdl-porters team [EMAIL PROTECTED] 1 Nathan Torkington [EMAIL PROTECTED] 1 Total 13 The list is here: http://dev.perl.org/rfc/overdue-perl6-language-data.html When freezing your RFC, please include a discussion section at the top summarising the feedback received. If there are outstanding issues, you may want to post a message to the list asking for clarification of ideas before submitting the frozen RFC. Feel free to shoot me an email if you want any clarification of this process. The -meta archives also contain more information about this.
RFC 119 (v4) Object neutral error handling via exceptions
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Object neutral error handling via exceptions =head1 VERSION Maintainer: Glenn Linderman [EMAIL PROTECTED] Date: 16 Aug 2000 Last Modified: 28 Sep 200 Mailing List: [EMAIL PROTECTED] Number: 119 Version: 4 Status: Frozen =head1 ABSTRACT Revisit what the goals of error handling and exceptions are for, to determine the set of desirable unit operations, rather than start with a bundle of stuff from another language, and try to make it Perlish. =head1 CHANGES =head2 notes on freeze Tony Olekshy was going to suggest a bunch of improvements where this RFC misinterprets RFC 88 in the comparison, but in the end I guess he was satisfied enough with it the way it is, after getting more familiar with this one. There's really a lot of synergy between the ideas in RFC 88 and RFC 119. Mostly RFC 88 is more rigid in suggested OO-ness, and RFC 119 doesn't prescribe that. Much of the implementation of the two could be done identically. The other major difference between the RFCs is that RFC 119 suggests a new mechanism for exception handling, separate from the current eval/die handling. This allows 100% compatibility (which cannot be achieved with RFC 88), and preserves a distinction between "fatal" and "non-fatal" errors. By doing so, the "catch-all" clause is much more useful in RFC 119, and the distinction between fatal and non-fatal errors (as perceived by the author of a sub or module) is an extremely convenient way of simplifying code when the original author correctly classifies the errors. =head2 version 3 changes Addition of p52p6 option for converting eval/die to throw/catch (if practical; the interfaces are quite different). Added the "scope" and "hooks" sections to the RFC 88 comparison. Updated the section on conversion wrappers. Updated implementation section to talk about DESTROY. Added a status field in the VERSION section. =head2 version 2 changes Addition of "always" clause. Clarified the rules for catching to specify that catch statements prior to the current point of execution in a given scope are not candidate targets for throws, only catch statements after the current point of execution in a given scope. Clarified that when a catch statement is encountered in the normal flow, that it is not executed. Added a section discussing the use of this "always-on" mechanism by people that prefer error returns. Added a few notes regarding implementation. Added a section regarding differences between RFC88v2d5 and RFC119 =head1 DESCRIPTION There are numerous RFCs regarding a complete bundle of exception handling mechanisms. Most of them are modeled after some other languages exception handling mechanism, adapted somewhat to Perl, and somewhat to the goals of the author. While this is not all bad, as the problems being faced were faced in the other languages as well, it is not necessarily all good, either. This RFC examines some of the incentives behind C++ exceptions, both the structure of the code and the structure of the exception object, then examines the goals of an exception mechanism, then examines some techniques that could be used to reach the goals. The result can be made to look a lot like the C++ exception mechanism if desired, but can be much more powerful when all its features are used. So this leads to the following "head2"s: - C++ exceptions - Goals of exceptions - Techniques for exceptions - Results - C++-like Usage - Conversion wrappers I focus on C++ rather than Java, because Java (pardon me, Java-heads) is just an attempt to use the best parts of C++ without all the baggage of C, so while most of this could have been changed in Java, it wasn't. This made Java easy to learn for C users who'd read about C++, and for C++ users. This didn't make Java a significantly better language than C++, although they were able to remove some of the worst C++ language traps. To excel, you need to not only remove some worst, but add some best. I think that's a goal of Perl. While Graham's error.pm module is a valiant attempt to include C++-like exception handling in Perl, it has various deficiencies (discussed by others) that can be attributed to be an add-on to Perl, just like C++ exception handling has various deficiencies because of being an add-on to C. =head2 C++ exceptions Remember that C++ exceptions were built first as a preprocessor for C. Therefore, the mechanisms used had to exist in C. Stack unwinding could therefore only be done by using the only non-local goto facility supported by C: longjmp. This forced a number of decisions about the design of exceptions, not all of which are good. I note in passing that ANSI Forth defines catch and throw which use single cells as parameters... so not all usage of catch and throw is related to
The One True Deadline is approaching
We've only got 4 days left until the One True Deadline on this whole thing. Please, go check this out: http://dev.perl.org/rfc/overdue-perl6-language-io.html And get your RFC's finished up. Remember: Oct 1st is a true deadline, coming from the powers above, meaning if your RFC is not frozen by then, it will be auto-retracted and not considered. My original comments on this process can be read here for those interested: http://www.mail-archive.com/perl6-language-io%40perl.org/msg00288.html If you need help or guidance, feel free to email me. Otherwise, good luck. -Nate
Re: RFC 336 (v1) use strict 'objects': a new pragma for using Java-like objects in Perl
On Thu, Sep 28, 2000 at 09:05:52PM -, Perl6 RFC Librarian wrote: =head1 TITLE use strict 'objects': a new pragma for using Java-like objects in Perl =head2 protected Just take Conway's RFC 188 and do a s/private/protected/g :-) "protected" is a very loaded term. What you propose to call protected in Perl isn't the same as protected in C++. This will cause confusion. =head2 private Like Conway's private operator defined in RFC 188, but accessing an hash key or a method that has been marked as private from outside the defining package should result in a fatal error. What does this buy us? What is the benefit? =head2 static Methods not marked as such should return a fatal error if called directly on the class. Again, where's the benefit? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 308 (v1) Ban Perl hooks into regexes
I consider recursive regexps very useful:
$a = qr{ (? [^()]+ ) | \( (??{ $a }) \) };
Yes, they're "useful", but darned tricky sometimes, and in
ways other than simple regex-related stuff. For example,
consider what happens if you do
my $regex = qr{ (? [^()]+ ) | \( (??{ $regex }) \) };
That doesn't work due to differing scopings on either side
of the assignment. And clearly a non-regex approach could
be more legible for recursive parsing.
--tom
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: RFC 308 (v1) Ban Perl hooks into regexes
In [EMAIL PROTECTED], Tom Christiansen writes:
:I consider recursive regexps very useful:
:
: $a = qr{ (? [^()]+ ) | \( (??{ $a }) \) };
:
:Yes, they're "useful", but darned tricky sometimes, and in
:ways other than simple regex-related stuff. For example,
:consider what happens if you do
:
:my $regex = qr{ (? [^()]+ ) | \( (??{ $regex }) \) };
:
:That doesn't work due to differing scopings on either side
:of the assignment.
Yes, this is a problem. But it bites people in other situations
as well:
my $fib = sub { $_[0] 2 ? 1 : $fib($_[0] - 1) };
I haven't kept up with the non-regexp RFCs, but I hope someone
has suggested an alternative scoping that would permit these
cases to refer to the just-introduced variable. Perhaps we
should special-case qr{} and sub{} - I can't offhand think of
another area that suffers from this, and I don't think these
two areas would suffer from an inability to refer to the same-
-name variable in an outlying scope.
A useful alternative might be a different special case. Plucking
random grammar, perhaps:
my $regex = qr{ (? [^()]+ ) | \( ^^ \) }x;
Certainly I think a simple self-reference is likely to be a
common enough use that it would help to avoid the full deferred
eval infrastructure, even when it works properly.
:And clearly a non-regex approach could be more legible for
:recursive parsing.
Like any aspect of programming, if you use it regularly it will
become easier to read. And comments are a wonderful thing.
Hugo
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
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.
Well, maybe I do. Forget $P1. If the user wanted $1 from the
previous RE, then they should have saved it somewhere. This would
eliminate the "major" RE-engine changes to make $P1 work. But it
would require that the p52p6 translator make some really smart
modifications.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: is \1 vs $1 a necessary distinction?
On Wed, 27 Sep 2000 10:34:48 -0500, Jonathan Scott Duff wrote: If $1 could be made to work properly on the LHS of s///, I'd vote for that being The Way. I disagree, because \1 is different from a variable $foo in at least two ways: * $foo is compiled into /$foo/ before anything is matched. \1 is a repetition of what was just matched; this is dynamic interpolation instead of static. * if $foo contains metacharacters, they are treated as metacharacters. for example, if $foo is "a.b", then /$foo/ can match "axb". /\1/, OTOH, can only match the LITERAL string that $1 captured. With $foo='a.b', /($foo)!$foo/ and /($foo)!\1/ will not match the same set of things. "\1" is more like equivalent to "\Q$1\E". Therefore, I don't want $1 on the LHS to be the standard syntax. -- Bart.
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
:=item *
:/(foo)_$1_bar/
:
:=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.
: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
:captured in the Bprevious match...which could be a long, long way away,
:possibly even in some module that you didn't even realize you were
:including (because it was included by a module that was included by a
:module that was included by a...).
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.
:The key fact here is that, in the first section of a s/// you are supposed
:to use C\1, but in the second portion you are supposed to use $1. If
:you understand the whole logical structure behind it and understand how an
:s/// works (i.e., the right hand side of an s/// is a double-quoted
:string, not a regex), you will understand the distinction. For newbies,
:however, it is apt to be quite confusing.
I think the whole idea that the LHS of s/// is a pattern, but the
RHS is a string (module /e, of course) is apt to be confusing when
you first encounter it. You won't be able to make sense of any but
the simplest use of s/// until you understand it, I think, and the
documentation expresses it quite clearly.
:=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.
If you are suggesting that they should have a special meaning only
in regexps, and only if braced, then I'd find it even more confusing.
The use of braces is usually the easiest (and only?) way to split
out a variable from following alphanumerics:
/foo${P1}bar/
:These changes eliminate a potential source of confusion, retain all
:functionality, provide an easy migration path for P526, and the last
:notation (${P1}) serves as a clear indicator that you are talking about
:something from outside the current regex.
What is the migration path for existing uses of $P1-style variables?
:=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.
:=head1 IMPLEMENTATION
:
: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. We'd need to avoid that and get either
the the raw data for the string or some list that has undergone a
minimum of preparation. It is possible we need that anyway - it is
a prerequisite for some of the other proposed enhancements (such as
the meta-referred-to RFC 112) and would certainly make the regexp
engine more flexible - but it is certainly substantial work. I don't
know what gotchas may arise. In general it seems a shame to recreate
large parts of the existing string parsing/interpolation code, but
it may not be possible to avoid it.
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.
:=head1 REFERENCES
:
:RFC 112: Assignment within a regex
:
:RFC 276: Localising Paren Counts in qr()s.
I didn't see a mention of these in the body of the proposal.
To me, the prime issue is with \1. The backslash is heavily overloaded
in perl, and that makes it difficult to suggest a consistent and
legible extension that would allow us to refer back to either variables
(RFC 112) or hash keys (RFC 150). I don't think switching to $1 is any
help for those, though.
Hugo
Re: RFC 332 (v1) Regex: Make /$/ equivalent to /\z/ under the '/s' modifier
In [EMAIL PROTECTED], Bart Lateur writes: :I'll try to find that "thread" back. This was my message: http://www.mail-archive.com/perl6-language-regex%40perl.org/msg00354.html :I don't think changing /s is the right solution. I think this will :incline people to try and fix their problems by adding /s, without :realising that this changes the definition of every . in their :regexp as well. : :Perhaps. I do think that, in general, textual data falls into one of :three categories: : : * text with possibly embedded newlines : * text with no embedded newlines : * text with an irrelevant newline at the very end. : :The '/s' option is for the 1st case. No '/s' for the 3rd. As for #2: you :don't care. I'd distinguish the first case further into 'the newlines are significant' or not - /s is often desired for the first case, and /m often for the second. And then I'd be tempted to repeat the whole list, replacing 'newline' with 'record separator'. I have to say I'm quite prejudiced against /s - I consider myself reasonably knowledgeable about regexps, but on average about once a month I find myself unsure enough about which is /m and which is /s that I need to check the top of perlre to be sure. I think we've appreciated for some time that it was a mistake to name them as if they were opposites, but if anything I'd like to reduce the need for them rather than to increase it. Hugo
Re: RFC 332 (v1) Regex: Make /$/ equivalent to /\z/ under the '/s' modifier
Is $$ the only alternative, or did I miss more? I don't think I've even
seen this $$ mentioned before?
$$ is not a suitable alternative. It already means the current process
ID. It really cannot be messed with. And ${$} is identical to $$ by
definition.
I still like the idea of $$, as I described it in the original thread.
I've seen no comments for or against at this time.
See above.
I can't see how yet another alternative, /$$/, is any better than what
we have now: /\z/.
I agree. If it's more alternatives we're after, just have the person
write a custom regex. The idea is to make Perl do the right thing,
whatever that may be.
The big problem with changing $, as you note, is for people that need to
catch multiple instances in a string:
$string = "Hello\nGoodbye\nHello\nHello\n";
$string =~ s/Hello$/Goodbye/gm;
Without $, you can workaround this like so:
$string =~ s/Hello\n/Goodbye\n/gm;
My suggestion would be:
1. Make $ exactly always match just before the last \n, as the
RFC suggests.
2. Introduce some new \X switch that does what $ does
currently if it's deemed necessary.
We're back to new alternatives again, but the one thing this buys you is
a $ that works consistently. I don't think many people need $'s current
functionality, and those that do can have an new \X.
-Nate
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
=item *
C\1 goes away as a special form
=item *
$1 means what C\1 currently means (first match in this regex)
=item *
${1} is the same as $1 (first match in this regex)
=item *
${P1} means what $1 currently means (first match in last regex)
Here's the big problem with this, and I think others have said it
similarly: If we need the functionality of both \1 and $1, then there is
no reason redoing the syntax. Period.
If \1 is unneeded, then let's ditch it and just use $1 everywhere.
However, this is not the case, as Randal, Bart, and others have shown.
If we need \1, then we should leave as-is. There's no reason to force
literally millions of people to relearn this. Renaming something just to
rename it does not add value.
-Nate
Re: RFC 143 (v2) Case ignoring eq and cmp operators
This RFC still has silly language that discounts what has been said before. 1) It calls uc($a) eq uc($b) "ugly", despite their being completely intuitive and legible to even the uninitiated. 2) It then proposes "eq/i" without the least blush, despite how incredibly ugly and non-intuitive and, if I may, syntactically perverse such a notion is. --tom 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: perl6storm #0050
John Porter [EMAIL PROTECTED] writes: Piers Cawley wrote: You know, I'm trying to see what's annoying about all those parentheses in the lisp function and what do you know, I can't see anything wrong. Okay, so it's not Perl syntax, but it's still clear what's going on. Yes, but it's hard to read. We could argue this back and forth, but I don't think that was hard to read. Sure you need to know lisp to understand it, but the same could be said of *any* programming language. -- Piers
my and local
As we sneak under the wire here, I'm hoping someone has posted an RFC that alters the meaning of my/local. It's very hard to explain as is. my is fine, but local should be changed to something like "temporary" (yes, that is supposed to be annoying to type) or "dynamic". 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: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
Try thinking of it this way: it's only a bareword if
it would make use strict whinge at you. Thus, the
constructs you cited are all non-uses of barewords,
such as in use Foo or require Foo or Foo = 1, or
even $x{Foo}. And I have proposed (nonRFC) that
Foo-bar() also be not a bareword. Yes, I know
strict doesn't carp about it, but that could be Foo().
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.
Murdering @ISA considered cruel and unusual
I strongly agree with the opinion that we should try and get away from special variables and switches in favor of functions and pragmas. Witness 'use base' instead of '@ISA', 'use warnings', and so on. Huh? Why??? Perl's use of @ISA is beautiful. It's an example of code reuse, because we don't need no stinking syntax! use base is, or can be, pretty silly -- think pseudohashes, just for one. The general sentiment you espouse obviously has a line beyond which you don't intend to cross. The question is where that line lies. --tom, who knows that it's hard to read his mail, but it's even harder to write it 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: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
So what's left?
print STDERR "Foo";
We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
through.
It is? I certainly hope not. It makes as much sense to
do that as to force a dollar sign on subroutines.
sub $foo { ... }
or
sub 'foo' { ... }
Heck, maybe everyone should be forced to write
*foo = sub { ... };
$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.
Eek, that's what I want to kill. I want you to HAVE to
write that as
$time = time();
with the parens. The lack of parens is the root of MANY
an evil in perl.
--tom
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: my and local
On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote: As we sneak under the wire here, I'm hoping someone has posted an RFC that alters the meaning of my/local. It's very hard to explain as is. my is fine, but local should be changed to something like "temporary" (yes, that is supposed to be annoying to type) or "dynamic". Someone has: RFC19 "Rename the Clocal operator" http://tmtowtdi.perl.org/rfc/19.pod Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: my and local
To my mind, things would be a lot clearer if my and local were to change places - but I can see why that would not be a good thing. If it's not too late for suggestions for renaming local, what about 'override'. Dave. - Original Message - From: "Michael Fowler" [EMAIL PROTECTED] To: "Tom Christiansen" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 28, 2000 10:36 AM Subject: Re: my and local On Thu, Sep 28, 2000 at 10:18:34AM +0100, Tom Christiansen wrote: As we sneak under the wire here, I'm hoping someone has posted an RFC that alters the meaning of my/local. It's very hard to explain as is. my is fine, but local should be changed to something like "temporary" (yes, that is supposed to be annoying to type) or "dynamic". Someone has: RFC19 "Rename the Clocal operator" http://tmtowtdi.perl.org/rfc/19.pod Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 288 (v2) First-Class CGI Support
On 27 Sep 2000, at 23:48, iain truskett wrote: So surely you'd want %HTTP (the input headers) to also be an array rather than a hash, since they'd be required in order as well? I don't care, because I don't work with this much. And I don't know whether I'd need to bear in mind the protocol which requires the order; I'd probably want to access them randomly. But that I send out has to follow the protocol. 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); the output also has an order, and *someone* has to provide for that order, and I believe it is not good for Perl to do so (for the reasons given before). Cheers, Philip
Re: RFC 288 (v2) First-Class CGI Support
* Philip Newton ([EMAIL PROTECTED]) [28 Sep 2000 21:19]:
On 27 Sep 2000, at 23:48, iain truskett wrote:
So surely you'd want %HTTP (the input headers) to also be an array
rather than a hash, since they'd be required in order as well?
I don't care, because I don't work with this much.
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.
And I don't know whether I'd need to bear in mind the protocol which
requires the order; I'd probably want to access them randomly. But
that I send out has to follow the protocol.
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'm thinking a $headers_in and a $headers_out type thing is needed where
things are a Headers object that can either return a given header
my $type = $headers_in-value('Content-Type');
or process things sequentially
foreach my $header_key ($headers_in-keys)
{
}
and of course add and remove things
while ($headers_in-keys)
{
my $headerline = $headers_in-shift;
my ($key, $value) = ($headerline-key, $headerline-value);
}
$headers_in-add('Breakfast-Food', 'Bagel');
and so on.
Flexible. Transparent. You could even tie things if you want, so things
are slightly more transparent. Combine operator overloading with some of
Damian's 'want' and Quantum::Superpositions stuff and things become
rather interesting.
Having a %HTTP and a @HEADERS is rather simplistic and not really that
accommodating for potential modifications to the protocols for HTTP and
CGI.
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.
the output also has an order, and *someone* has to provide for that
order, and I believe it is not good for Perl to do so (for the reasons
given before).
I would agree.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
You know you are addicted to coffee if...
2 You sleep with your eyes open.
Re: Murdering @ISA considered cruel and unusual
Tom Christiansen [EMAIL PROTECTED] writes: I strongly agree with the opinion that we should try and get away from special variables and switches in favor of functions and pragmas. Witness 'use base' instead of '@ISA', 'use warnings', and so on. Huh? Why??? Perl's use of @ISA is beautiful. It's an example of code reuse, because we don't need no stinking syntax! Indeed. Clear, simple, works. And if you're that way inclined lets you do all sorts of weird shit. I say keep it. use base is, or can be, pretty silly -- think pseudohashes, just for one. Cuse base has the potential to be very nice indeed. Preferably after pseudo hashes have been excised from the language. It happens at compile time. You can enforce various levels of stricture through it, which can potentially make it easier for the compiler to optimize stuff. It's vaguely necessary if you're going to have interfaces and all that (at least, the compile time behaviour is). I say keep it. Neither of these methods is the One True Way. They are both very useful in their place. Deciding where those places are is left as an exercise for the interested programmer. -- piers
Re: RFC 48 (v4) Replace localtime() and gmtime() with date() and utcdate()
Certainly numbers should never be "zero-padded"! 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: Expunge use English from Perl? (was Re: Perl6Storm: Intent toRFC #0101)
On Wed, 27 Sep 2000, Nathan Wiger wrote: Russ Allbery wrote: I've found the use of use English in code I had to maintain to be annoying and unhelpful, and to actually degrade the maintainability of the code Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. Well, I think it has some limited uses. Remember that not everyone programs in perl all day everyday. Many competent people are only occasionally perl programmers. I find that I don't remember many of the less-frequently-used perlvars (where less-frequently-used depends on the types of programs I write, obviously). I certainly couldn't tell you off-hand the differences among $ $ $( and $). I'd have to look them up. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Murdering @ISA considered cruel and unusual
Piers Cawley wrote: I strongly agree with the opinion that we should try and get away from special variables and switches in favor of functions and pragmas. Witness 'use base' instead of '@ISA', 'use warnings', and so on. Huh? Why??? Perl's use of @ISA is beautiful. It's an example of code reuse, because we don't need no stinking syntax! Indeed. Clear, simple, works. And if you're that way inclined lets you do all sorts of weird shit. I say keep it. I *do* agree with keeping @ISA, actually. :-) My message was spawned by a message of Ilya's proposing that we slash and burn everything except a very few variables. I actually said that this was a fragile approach. But I do agree new variables should be avoided where possible. Shit, 90% of my modules would break, including Class::Handler, which I particularly like (and there's no way around @ISA with 'use base', since it works at runtime). -Nate
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
Tom Christiansen wrote: So what's left? print STDERR "Foo"; We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go through. It is? I certainly hope not. It makes as much sense to do that as to force a dollar sign on subroutines. Your point is assuming that STDERR retains its weirdness, and does not become a simple scalar object so that these two: print $STDERR @data; $STDERR-print(@data); Are 100% the same. Making STDERR into $STDERR is all hinged on fast vtable stuff in core, which looks quite likely based on things Dan says, but not set in stone. 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. Eek, that's what I want to kill. I want you to HAVE to write that as $time = time(); with the parens. The lack of parens is the root of MANY an evil in perl. Check out use strict 'words' in RFC 278. -Nate
Re: RFC 288 (v2) First-Class CGI Support
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. I'm thinking a $headers_in and a $headers_out type thing is needed where things are a Headers object that can either return a given header Flexible. Transparent. You could even tie things if you want, so things are slightly more transparent. Combine operator overloading with some of Damian's 'want' and Quantum::Superpositions stuff and things become rather interesting. 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. 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. 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. -Nate
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote: On Wed, 27 Sep 2000, Nathan Wiger wrote: Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. The key point is that it's optional. If you think it's a waste of time and effort, don't use it. If other people use it, well... does Perl stop people programming in ways you don't like? -- It is better to wear chains than to believe you are free, and weight yourself down with invisible chains.
Re: RFC 262 (v1) Index Attribute
Webmaster wrote:
(I have attached a prototype of what I had in mind)
From: "David L. Nicol" [EMAIL PROTECTED]
Yes, that is exactly what is being suggested, but the "indexof" function
is implicit in the attribute. Your code becomes
print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
I do like the iterator, but I also prefer:
" split( /$delim/, $items[$index] );"
To
" split( /$delim/, $items[${_:n}]);"
for readability.
yes. I imagine :n would be used in debugging code, where you don't
really need it for the general meaning of the passage.
$items[$_:n]# curlies only are required for interpolation
I didn't say it so many words, but an example of how to _access_ an
attribute inside interpolation -- that is what I was getting at too;
The two might actually be able to work together, if ':n'
was an element of the actual array, whereby a subsequent call to the array
index function using 'null' or 'undef' as the starting index would pick up
where it left off. The other part is that the array index function could
potentially return a list. (see attached)
It's only a suggestion, and I have programmed long enough to do it other
ways (see attached), but if RFC 199 doesn't fly, this would be nice to have
around.
Grant M.
[EMAIL PROTECTED]
it's not a member, but an attribute, thus the colon. The curlies are
only needed because we're inside double-quotes in my example.
Re: my and local
On Thu, 28 Sep 2000, Steve Fink wrote: Tom Christiansen wrote: As we sneak under the wire here, I'm hoping someone has posted an RFC that alters the meaning of my/local. It's very hard to explain as is. my is fine, but local should be changed to something like "temporary" (yes, that is supposed to be annoying to type) or "dynamic". my's runtime/compile-time schizophrenia is rather bizarre too. I'd like my $x if 0; to be equivalent to my $x; Why? Do you mean that you want $x to be created/instantiated even if the boolean clause is false (but could have been true)? In an if/then blcok the scalar would be scoped locally and so would be irrelevant if the boolean clause evaluated evaluated to false. As it is, it is kind of strange that the scope of $x in your statement isn't bound in the if/then structure. -Adam btw: I am guessing that you usually write that my $x = $y if 0/1; Which could be done slighlty safer my $x = 0/1 ? $y : 0; # or undef
Re: perl6storm #0050
Buddha Buck wrote: While Perl -lets- every function be well prototyped, it doesn't -require- every function to be well prototyped. Because of this, it might be well nigh impossible to eliminate all ambiguity to the compiler. Well, right. Clearly, in those cases, you can expect to need parens sometimes. -- John Porter Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...
split() ideas
I thought I had sent this the other day, but it doesn't appear to have made it through... Here are a couple of ideas that I don't have time to RFC, but some who likes them might: 1. Allow the first argument to split() to be a number such that the string is broken into chunks of that many characters. 2. Allow the first argument to split() to be an array of numbers, such that split returns a list of strings each as long as the corresponding number. Yes, I know this can be done with unpack() or substr(), but that's never stopped us before. Note that if #1 is adopted, $foo in "split $foo, $str" will no longer really mean "split /$foo/, $str". -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: split() ideas
On Thu, Sep 28, 2000 at 01:02:11PM -0500, Jonathan Scott Duff wrote: I thought I had sent this the other day, but it doesn't appear to have made it through... Here are a couple of ideas that I don't have time to RFC, but some who likes them might: 1. Allow the first argument to split() to be a number such that the string is broken into chunks of that many characters. 2. Allow the first argument to split() to be an array of numbers, such that split returns a list of strings each as long as the corresponding number. Yes, I know this can be done with unpack() or substr(), but that's never stopped us before. Ah, but with them you would need a loop. One other way would be to allow \G to work in split() so you could do @ary = split(/\G(=..)/, $str) but then we can already do this with @ary = $str =~ /\G(..)/sg; Note that if #1 is adopted, $foo in "split $foo, $str" will no longer really mean "split /$foo/, $str". Right, and I think that the fact that there are already several ways to do it, we don't need to add another. Graham.
Re: RFC 288 (v2) First-Class CGI Support
Nathan Wiger wrote:
1. make a listref only for multiple values:
@name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );
Ick. That piece of code is small enough, but it's going to end up
replicating itself everywhere %CGI is accessed. This will be a fruitful
new source of bugs when people forget to check Cref $CGI{name}, and a
maintenance nightmare when someone makes a small like adding "multiple"
to a select tag.
But I don't think listrefs are needed in all contexts, since you should
know which elements will likely have multiple values (checkboxes, etc).
Maybe (and I stress maybe) the programmer knows, but the code that
parses into %CGI doesn't know whether a parameter is from a checkbox
group with only one value checked, or something else.
2. make it a comma-delimited string:
$name = $CGI{name};
@name = split ',', $name;
The problem arises if your data has commas in it.
Double ick.
Maybe %CGI is tied. Fast embedded tie, like in Perl 6. :-)
It looks to me like FETCH is always called in scalar context. Even
saying C@foo{...} results in multiple scalar fetches. That could be
changed, I suppose, but it makes me twitch. Maybe someone who knows
ties better could comment on this.
--
Robert Mathews
Software Engineer
Excite@Home
Re: Murdering @ISA considered cruel and unusual
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? -- John Porter
Re: split() ideas
Jonathan Scott Duff wrote:
1. Allow the first argument to split() to be a number such that
the string is broken into chunks of that many characters.
@strings = /(.{$n})/g;
2. Allow the first argument to split() to be an array of
numbers, such that split returns a list of strings each as
long as the corresponding number.
@strings = do { my $re = join '', map { "(.{$_})" } @lengths; /$re/ };
--
John Porter
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Andy Dougherty [EMAIL PROTECTED] writes: I find that I don't remember many of the less-frequently-used perlvars (where less-frequently-used depends on the types of programs I write, obviously). I certainly couldn't tell you off-hand the differences among $ $ $( and $). I'd have to look them up. I never understood why these were variables. You don't change UIDs or GIDs that often, and when you do you tend to want precise control and because they're variables, they have weird interaction semantics and you have to assign to them in just the right order to get done what you want to get done. See recent threads on comp.lang.perl.moderated. I'd honestly rather see getuid, geteuid, getgid, getegid, and getgroups, along with some consistent and complete subset of the setting functions (with portability magic behind the scenes), in a separate module that only those programs that need to do UID fiddling need to load. I guess the exception is getpwuid($), which is probably done more than any other operation on UIDs, but maybe just keep that single variable. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 288 (v2) First-Class CGI Support
On Thu, Sep 28, 2000 at 08:06:42AM +0200, H . Merijn Brand wrote: On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE First-Class CGI Support Freezing within two days doesn't leave much space for comments and or objections does it? Retractions are still possible with frozen RFCs. Minor revisions and clarifications are still acceptable for frozen RFCs. The intent of this RFC seems clearly stated. That, and the discussion I saw seemed to have fleshed out the major issues, and was getting bogged down in trivia (e.g. embperl). I'm not against making things easier in general, but I don't want perl to be Just Another Web Service. I've started an RFC on that when perl6 just started, but I saw discussions take a good direction, so I didn't post it. Please post it. Or something along the lines of what you were thinking. I think this one belongs in perl6-stdlib, certainly not in the perl6-core! Probably. But it has interaction with taint mode, which is also something of an internals issue. And there are some minor language design issues, like making %CGI become the equivalent of %ENV and making taint mode manditory (unless it's REEELY not wanted). One strike against -stdlib, is that the standard library has CGI.pm already, and this is a plea for a more standard, less feature-bloated module that could easily be reused for all of the CGI output interfaces. Z.
Re: Murdering @ISA considered cruel and unusual
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"! -- People in a Position to Know, Inc.
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Simon Cozens wrote: On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote: On Wed, 27 Sep 2000, Nathan Wiger wrote: Y'know, I couldn't have said this better myself. :-) I've always felt that "use English" was a waste of time and effort, a bandaid trying to act as a tourniquet. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. The key point is that it's optional. If you think it's a waste of time and effort, don't use it. If other people use it, well... does Perl stop people programming in ways you don't like? I agree with you. That's why I'd never RFC that we should lose it.* I was just voicing my opinion that I personally think it's a waste. But that doesn't mean others don't like it. ;-) -Nate * assuming it doesn't harm the language, which it doesn't currently
Re: RFC 171 (v3) my Dog $spot should call a constructor implicitly
On Thu, Sep 28, 2000 at 12:25:32PM +0100, Tom Christiansen wrote: You also didn't mention that you would have broken the symmetry between my Dog $spot; our Dog $spot; No, I didn't mention our Dog $spot should be the same thing, but on an our variable. Or that constructors have no (and should have no) set name in Perl. What of TIEARRAY, TIEHASH, TIEHANDLE, etc.? What of the alternative for providing an author-specified implicit constructor name through a pragma? Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to coredistribution
Perl6 RFC Librarian (Today): =head1 TITLE Add Cheader and Cunheader funtions to core distribution Maintainer: Nathan Wiger [EMAIL PROTECTED] =head1 ABSTRACT !-- snip -- This RFC proposes that Perl include a simple function, Cheader, that can be used to interact with these headers more easily. It is a general-purpose formatting function that does not do any content-specific handling (unlike CCGI.pm's version). It is also proposed that an Cunheader function be included which converts in the opposite direction. While I'm not sure if this belongs in the core or not, I think it's nifty, and I'd like to point out an almost inevitable side effect. Knowing well the nature of Perl hackers, this function will almost certainly be used for non-header tasks such as config files, as the data format used in most plaintext headers is both simple and general. Add comment detection to the parsing, f'rinstance, and this is quite similar to a Java Properties file. Useless comment, probably, but it sprung to mind. ~ j. // "The National Association of Theater Concessionaires // reported that in 1986, 60% of all candy sold in movie // theaters was sold to Roger Ebert." -- D. Letterman
Re: PERL6STORM - tchrist's brainstorm list for perl6
I think the octal number representation should not be accepted... Adam Krolnik Verification Mgr. LSI Logic Corp. Plano TX. 75074
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution
On Thu, Sep 28, 2000 at 03:22:08PM -0600, John Barnette wrote: Perl6 RFC Librarian (Today): =head1 TITLE Add Cheader and Cunheader funtions to core distribution While I'm not sure if this belongs in the core or not, I think it's nifty, and I'd like to point out an almost inevitable side effect. Knowing well the nature of Perl hackers, this function will almost certainly be used for non-header tasks such as config files, as the data format used in most plaintext headers is both simple and general. Add comment detection to the parsing, f'rinstance, and this is quite similar to a Java Properties file. My first thought was "this should definitely be in a module" and your comments just fire those synapses even more strongly. To me core-worthy things must be primitivish. The idea of colonizing and s/_/-/g and ucfirst()ing each word and adding newlines or reversing all of that seems so unprimitive. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 262 (v1) Index Attribute
David L. Nicol wrote:
print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
If we are going to be throwing around attributes like that, why
don't we switch to using the ubiquitously recognizable dot instead
of colon?
for my $iter ( @things ) {
print "index= ", $iter.indexof, "\n";
--
John Porter
Jetzt schalten wir das Radio an. Aus dem Lautsprecher klingt es dann...
Re: RFC 262 (v1) Index Attribute
John Porter wrote:
David L. Nicol wrote:
print "Found It at position ${_:n}!\n" if /$seek/ foreach @items
If we are going to be throwing around attributes like that, why
don't we switch to using the ubiquitously recognizable dot instead
of colon?
for my $iter ( @things ) {
print "index= ", $iter.indexof, "\n";
I hope that was a rhetorical question, but here is the rhetorical answer:
Because the ubiquitously recognizable dot is already in use as the
string concat operator in this language, and overloading it would
cause far far far too much ambiguity. This answer also goes for schemes
for optimising
-
into one character.
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution
Personally I think this is probably a bad idea.
But if such a thing WERE to be implemented, I don't see why you have to have
two words...
header(a1, b=2); #options list, returns a string with formatted headers
header($foo); #scalar option $foo is parsed and a list is returned
#(for assignment to a hash most likley)
header(); #implied scalar option $_, if this is a hash reference,
#header acts in the format sense... else parse
header(header(a=1, b=2)); #essentially a NOOP
PS un is such a lame prefix and very un perl like... unjoin? unpush?
okay so unshift, but still... hey wait I want undelete!
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";{$F[0]};sub t{*t=sub{};
return if rand().5;$_="Vg'f abg lbhe ghea lrg, abj tb.";{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}v;}{$_++;$_--;$_||=4;
if($_2||($_212)){$_="Vainyvq ragel";{$F[0]};last;}t;$0-=$_;$_="Lbh jva";
die({$F[0]}) if !($0-1);$0-=$0%2?$02?2:1:$0=5?$02?3:1:rand.5?1:3;
$_="V jva";die({$F[0]}) if !($0-11);}v __END__ http://pthbb.org/
MOTD on Sweetmorn, the 52nd of Bureaucracy, in the YOLD 3166:
No civilized person ever goes to bed the same day he gets up
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution
Jonathan Scott Duff wrote: My first thought was "this should definitely be in a module" and your comments just fire those synapses even more strongly. Yes, this will likely end up in a core module. The main thing is that it always has to be available so that pragmas like "use cgi" can import it. -Nate
Re: RFC 333 (v1) Add Cheader and Cunheader funtions to core distribution
PS un is such a lame prefix and very un perl like... unjoin? unpush? okay so unshift, but still... hey wait I want undelete! Heh. :-) This is not really true, in fact within Perl it is the One True Prefix, ala undef, unlink, unpack, unshift, untie... -Nate
Attribute access
There are many (good) RFCs that specify new attributes. To the best of my
knowledge, there is no good RFC discussing how to go about making
attributes, setting them, and getting them.
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) -- I don't
have the time to write or maintain an RFC.
The idea is this: every variable should have a psudohash of attributes.
To access the attribhash, you'd use somthing like this:
my($scalar,@array,%hash,^placeholder,sub);
my %arraysattribs = %@array:;
my $subsline = $sub:{line};
print "\%hash has the following attributes:\n";
foreach (keys %%hash:) {
print "\$\%hash:{$_} = ", $%hash:{$_}, "\n";
}
$subsattribsref = \%sub:;
This is to say, the attribhash for a varable VAR (where VAR includes the
funny-character is the hash VAR:. (You can use any expression with a valid
result for VAR.)
In 5.6, Cmy $foo: = "42\n"; has the same effect as Cmy $foo = "42\n";,
and Cprint $foo:; is a syntax error.
You need to keep the funnychar of the attributed thingy somewhere in the
attribhash syntax, since otherwise $foo's attribues aren't seperable from
@foo's.
The reason you want an attribute hash is fairly obvious, I think.
An operator with rvalue and lvalue semantics is also possible:
%foosattribs = attribs @foo;
%foosattribs{private}++;
However, I can't see how you could set an attribue on a value without making
a temporary.
Variable names containing a : that isn't part of a :: would be reserved.
(That, or the bare colon is an operator returning a hash (not a list).)
You can also set an attribute like this:
my $foo :private;
This is equivlent to:
my $foo;
$$foo:{private} = 1;
my $foo :private(1);
is equivlent to
my $foo;
$$foo:{private} = [1];
my $foo;
means that
exists($$foo:{private}) is false.
You can put an attribute in anything that can be used as a variable:
Whole arrays.
Whole hashes.
Scalars.
Array elements.
Filehandles
[Globs].
Subs.
Hash values.
Hash key-value pairs? This probably makes sense iff hash keys become full
scalars and not strings that act like scalars sometimes. It would be
useful, though.
Note the last one especialy.
$$hash{elem}:{raccess}++;
$hash{elem} = 42;
exists $$hash{elem}:{raccess}; #is false.
This is because %$hash{elem}: sets the attribute on the value of
$hash{elem}, not on the spot in the hash.
I don't know what a good syntax for the hash position would be. And I've
got other work to do now.
-=- James Mastros
Creating attributes:
--
-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--
RFC 340 (v1) with takes a context
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
with takes a context
=head1 VERSION
Maintainer: David Nicol [EMAIL PROTECTED]
Date: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 340
Version: 1
Status: Developing
=head1 ABSTRACT
"call frames" become useful as objects. The current one is always Cwith with
no argument and you can get into an arbitrary one by using Cwith $whatever
BLOCK in either forward or backward form, like Cif.
=head1 DESCRIPTION
=item description by commented example
sub A{
my $A = shift;
return with;
};
$context1 = A(3);
print "$context1"; # something like CONTEXT(0XF0GD0G)
print "$A" with $context1; # prints 3
with $context1{print "$A"}; # same thing
=item coexistence w/ pascal-like with
The context-access Cwith takes a scalar argument, the pascal-like with takes
a hash. If the pascal-like with is considered as describing aliases to defined
variables, the two have deep similarities.
=item CONTEXT objects in other contexts
In an array context, one of these CONTEXT things will expand into key-value
pairs if it can.
=item warning about memory leaks
using Cwith to store contexts may adversely affect memory recycling.
=head1 IMPLEMENTATION
Perl5 has the hooks required to do this: the closure stuff. This proposed
Cwith keyword makes access into such things more explicit.
=head1 REFERENCES
None.
Re: RFC 288 (v2) First-Class CGI Support
On Wed, 27 Sep 2000, Nathan Wiger wrote:
Robert Mathews wrote:
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q-param("foo");
2. make it a comma-delimited string:
$name = $CGI{name};
@name = split ',', $name;
The problem arises if your data has commas in it. Then you're hosed. So
door #1 might be the only solution.
Hosed indeed. One can control whether or not checkboxes, options, and radio
buttons have a comma in their value attribute. Method two fails when the
user enters "Ann Arbor, MI".
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.
I've used HTML::Embperl a lot and I've not difficulty with series data,
and yes I've worked with checkboxes and selects. It will go a long way
for classic CGI. If the source is coming from other than a browser, or
from a scripting language within the browser it is possible to defeat
this scheme, but we are looking to keep it simple for the common case.
Re: RFC 288 (v2) First-Class CGI Support
On Wed, 27 Sep 2000, Adam Turoff wrote: On Wed, Sep 27, 2000 at 11:33:13AM -0700, Nathan Wiger wrote: Ziggy, are you interested in this idea enough (at all?) to stick a note about the 'header' function into the RFC? Or should I RFC it separately? Adding headers() to the core language (or a similar pragma that is automagically invoked by cgi) would make more sense to me. I'd be in favor of a new RFC. Adding it into cgi sounds like we're on the road to spontaneously reinventing CGI.pm... ^^^ You are probably finding that CGI.pm is huge for a reason. Because Frist-Class/easy-to-write CGI requires more than form posts and headers. This header functionality is application specific and does not belong in the core any more than the socket stuff which seems to be on its way out. I don't see why this has be implemented in the core in C. Once again, if core means core modules, and as a part of cgi.pm or headers.pm or some such I am not concerned. And a switch for tainting and inclusion of this module sounds peachy. No core. Alan Gutierrez
Cya dudes
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. 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.. 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. Again, sorry, -Ed _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: RFC 288 (v2) First-Class CGI Support
Alan Gutierrez wrote: This header functionality is application specific and does not belong in the core any more than the socket stuff which seems to be on its way out. I don't see why this has be implemented in the core in C. Once again, if core means core modules, and as a part of cgi.pm or headers.pm or some such I am not concerned. And a switch for tainting and inclusion of this module sounds peachy. No core. Yes, I believe that is the idea, at least currently. CGI.pm is also massive because it also includes a whole bunch of h2() and like methods that we wouldn't need here. The idea is just to cover basic stuff that modules like CGI.pm could potentially build on. -Nate
Re: Attribute access
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! ;-)
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!".
To access the attribhash, you'd use somthing like this:
my($scalar,@array,%hash,^placeholder,sub);
my %arraysattribs = %@array:;
my $subsline = $sub:{line};
print "\%hash has the following attributes:\n";
foreach (keys %%hash:) {
print "\$\%hash:{$_} = ", $%hash:{$_}, "\n";
}
$subsattribsref = \%sub:;
Here's what I'm thinking: a new builtin, attr(). This might also be
implementable as UNIVERSAL::attr.
Syntax would be such:
@attrs = $object-attr;
@attrs = attr %hash;
$is_fluffy = attr %hash, 'fluffy'; # query a specific attribute
Another keyword could be 'is', which is cuter:
$can_puff = is %hash, 'fluffy';
but it's way too close to 'isa' for my tastes. If attributes were the
proper tense then 'has' would work:
$nice_coat = has $spot, 'fluffiness';
which I kinda like.
The attr keyword could be overloaded to also do sub/struct-like
definitions, as specified in RFC 337.
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.
That way, attributes can be applied to objects, packages, subs, and
other things that don't have variable representations:
package BigInt : autotie;
package main;
if ( has BigInt 'autotie' ) {
# class is automatically tied...
}
The declaration of attrs is proposed vaguely in RFC 337. I'll add access
before the freeze.
-Nate
RFC 277 (v2) Method calls SHOULD suffer from ambiguity by default
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Method calls SHOULD suffer from ambiguity by default
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 24 Sep 2000
Last Modified: 28 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 277
Version: 2
Status: Developing
=head1 CHANGES
The first version was too cute, trying to prove a point but failing
miserably. So here it is, in plain English.
=head1 ABSTRACT
RFC 244 proposes special-casing - to quote the left operand, and
eliminating the bareword indirect object syntax entirely.
These are both Bad Ideas, and will likely cause a large number of
longtime Perl hackers to run away screaming.
Many people, myself included, view the ability to type:
$q = new CGI;
$val = shift-{fullname};
And have Perl DWIM is what makes Perl Perl, and fun. Forcing me to
write:
$q = new {'CGI'};
$val = shift()-{fullname};
Because this ambiguity upsets a few people is just plain silly. And
Bvery un-fun.
Tightening this syntax by default makes no sense. Rather, this is
something that can easily be added to Cuse strict. See BRFC 278 for
details on Cuse strict 'words' and Cuse strict 'objects'.
=head1 DESCRIPTION
In Perl 5, there are already plenty of ways in which people can
Bvoluntarily disambiguate the above:
$q = new 'CGI'; # main::new('CGI');
$q = CGI::-new; # or 'CGI'-new;
$val = shift::-{fullname}; # or 'shift'-{fullname}
$val = shift()-{fullname}; # main::shift()-{fullname}
And if people want this to be enforced, then they can easily Cuse
strict 'words' as specified in RFC 278.
Perl 6 should be a value add to Perl 5. It should not take away
established, widely-used syntax just because of a little ambiguity. This
is hardly the only syntactic ambiguity in Perl.
=head1 IMPLEMENTATION
Perl 6 should tokenize the above just like Perl 5.
=head1 MIGRATION
None. Why would we want there to be?
=head1 REFERENCES
RFC 28: Perl should stay Perl.
RFC 278: Additions to 'use strict' to fix syntactic ambiguities
RFC 244: Method calls should not suffer from the action on a distance
