Re: RFC 204 (v2) Arrays: Use list reference for multidimensional array access
Bart Lateur wrote: The problem is that $name = "myarray"; @$name = (1,2,3); print @$name[0,1]; # 1,2 Is very consistent currently. Change one and you have to change the precedence and parsing of all symbolic refs. You are suggesting to keep a weird precedence rule, just to ease symbolic dereferencing!?! That's... obscene. Where did I say that?! I even said: I'm not necessarily against it, but it's a deep issue not just constrained to arrays in this one specific context. My point was if this idea is RFC'ed, the RFC better not be titled "Fix arrays" but better be called "Redo the precedence rules of all symbolic references". -Nate
Re: RFC 185 (v3) Thread Programming Model
On Wed, Sep 27, 2000 at 05:29:22AM -, Perl6 RFC Librarian wrote:
$ok = try $scalar;
$ok = try @array
$ok = try %hash;
$ok = try sub;
I'd like to see a more specific name for these. 'try' is too useful a word
for core to gobble it up for everything (IMHO). attempt_lock? Or simply
put these in a module and not export try by default. (Also, try might get
used for exceptions -- or would at least confuse people who expect it to be.)
Also, it'd be nice if an implicit join was done if a Thread was used in a
stringifying or numifying context. That way, you could treat it as a
function call that ran until it was acatualy needed, as in $factorial27 =
async{factorial(27)}, and somewhere later in your program, did a computation
involving it. At that point, $factorial27 would be forced to take a value
(to whit, 27!), and would no longer be a Thread. OTOH, this is broken wrt
things not returning numbers or strings (IE lists or refs), and makes
numifying/stringifying a mutator, which is probably a Bad Thing.
However, it seems amazingly useful. Hm, I think it could be done easily
enough as a wrapper class.
Sorry I didn't get these in on v2; I don't follow the perl6-language* lists
as well as I probably should. Too much trafic, to little time.
-=- James Mastros
--
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V
PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y?
--END GEEK CODE BLOCK--
Re: RFC 319 (v1) Transparently integrate Ctie
Nathan Wiger [EMAIL PROTECTED] writes:
I'm kind of curious to know what you think would happen with the
following. I've commented where I'm confident...
interface Number;
sub TIESCALAR;
sub STORE;
sub FETCH;
package integer implements Number; # I really like this notation
Tangentially, yes, it is nice to read, but it prevents multiple
interface specifications. "use interface" is more consistent.
It does?
package integer implements qw/Number Countable/;
Et viola.
sub TIESCALAR {...};
sub STORE {...};
sub FETCH {...};
my Number $i; # Number is an interface, so just an assertion
my integer $n; # integer-TIESCALAR($n);
my non_tied $object;# Just an assertion
defined($n);# Should be false
Yes. The only potential gotcha is if the user decides to do something
Really Evil and stores a value as part of their TIESCALAR method. Then
$n-FETCH will return that value and defined($n) will be true.
However, this is not the purpose of tie, and I think an appropriate
response is: Don't Do That. I agree with both you and Damian that TIE*
should be called on declaration for consistency. If a person doesn't
know how to use tie, well, that's not our problem. ;-)
$n = 5;
$i = $n;
$n = 10;
print $i;
$i = $object; # Assertion fails
Assuming you've set up your Cuse optimize restrictions appropriately,
then yes. The key is really what 'non_tied' is setup as. If this is a
builtin type that optimizes itself to be a string object, then yes it
will fail. However, if 'non_tied' is just a synonym for 'float' (for
some odd reason) then the last line will be ok.
I think you're missing the point. What does 'print $i' print? What
happens if you do C$n = $i? Does $i 'remember' that the number that
got assigned to it is an integer? What is the mechanism for that? It
seems that there will need to be some pretty far reaching changes to
Perl if you want this to do the Right Thing. Assuming we know what the
Right Thing is.
my int @b :64bit; # again, just an assertion
Asserting what? That's not valid syntax at the moment.
But it will be. :-) See RFC 279.
Ah. I'll marshall arguments there then.
@c = @b;# empty list passed still
@b = (1,2); # int-TIEARRAY(@a, '64bit'); @b-CLEAR(...);
Hmm... I think this is somewhat ugly. Assuming that you want
Cmy int @b to imply CUNIVERSAL::isa(all(@a), 'int') then tying the
entire array seems a bit weird.
Not necessarily. The key is: *how* would you implement the assertion
check?
If you use tie, then your int class STORE method can do something like
this:
package int;
use base 'var';
# take defaults from var class
STORE {
if ( self-isa($_[1]) ) {
SUPER-STORE($_[0], $_[1]); # internally store
} else {
die "Bad data $_[1]" if ( $under_strict_types );
}
}
Having the programmer implement this assertion check (or not) is a
Very Bad Idea. Assuming we're expecting to get some compiler
optimization from this then things should be enforced rather more
robustly.
Er... You seem to be implying here that *all* classes should have TIE
methods. Which is not good.
No, I wasn't trying to imply that, I'll clarify this point. TIE methods
are still completely optional.
Okay. It's just that your example that I quoted and you cut out seems
to imply otherwise.
Err... Specifying which classes implement an interface in the
interface specification is Wrong Wrong Wrong.
Yes, you're right,
Phew.
Can I just point out that nobody has yet proposed that you can attach
attributes to a package?
Didn't Damian propose Cpackage Foo : interface already? ;-)
Not in an RFC, no.
I'm not entirely sure what you're driving at here. I thought you were
arguing that *all* packages that created objects would use tie magic,
in which case the new attribute becomes unnecessary. And if you're not
proposing that then :tie is too general in the cases where the module
can only tie to specific variable types. I think you get better
granularity with interfaces, which are way more general than a special
new attribute.
No, let me back up a little. The idea is to make it so that tied
interfaces - which are really different beasts from OO interfaces
altogether because of their purpose - should be more closely integrated
into Perl 6. This would allow you to create custom, optimized,
strongly-typed variables that would function just like builtins:
my Matrix @a = ([1,2,3], [4,5,6]);
my NISMap %map :passwd = read_passwd_file();
my Apache::Session %session :transaction;
However, this is not to overshadow OO interfaces, which are needed for
functional methods, as you note.
The :tie attribute is a poorly chosen name. The original name was
:implicit, and was going to be attached to the TIE subs:
Re: RFC 161 (v4) Everything in Perl becomes an object.
Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: Not an awful lot was said once this RFC was condensed down to "Everything becomes an object". I believe some implementation and conceptual hurdles exist which have discouraged more serious discussion. At the suggestion of others I've opted to freeze rather than withdraw. How might I persuade you to reconsider? I was kind of hoping that this one would get withdrawn as well. -- Piers
Re: RFC 161 (v4) Everything in Perl becomes an object.
2000-09-27-05:28:01 Piers Cawley: Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: At the suggestion of others I've opted to freeze rather than withdraw. How might I persuade you to reconsider? I was kind of hoping that this one would get withdrawn as well. As one of the first to jump up and encourage the freeze rather than withdrawl, I feel obliged to speak up here. It was being withdrawn for lack of interest and feedback, not for any criticism. If (and that's a big if) this could be done --- make everything an object --- with no damage to either performance (ruby doesn't seem to be slower than perl, overall) nor to the language (and that I really don't know about), then this would buy us some wonderful power: we could trivially bring to bear the whole operator overloading machinery from the O-O support for redefining the basic operation of the language to customize it to application domains. Could you please do us the service of being more specific about why you want this RFC withdrawn, for the benefit of those of us who don't automatically understand? We see potential for some really exciting good here, and haven't heard where the harm is yet. Thanks! -Bennett PGP signature
Re: RFC 161 (v4) Everything in Perl becomes an object.
On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote: Not an awful lot was said once this RFC was condensed down to "Everything becomes an object". I believe some implementation and conceptual hurdles exist which have discouraged more serious discussion. At the suggestion of others I've opted to freeze rather than withdraw. How might I persuade you to reconsider? I was kind of hoping that this one would get withdrawn as well. Ok, no fair sniping after a freeze. You were warned. It's called email, people! Use it. Jeez... Matt
Re: RFC 161 (v4) Everything in Perl becomes an object.
On Wed, Sep 27, 2000 at 09:53:03AM -0700, Matt Youell wrote: Ok, no fair sniping after a freeze. You were warned. It's called email, people! Use it. Jeez... Never too late to withdraw, sir. [1] The less crap we make Larry wade through, the better. [1] Well, up until the pregnancy, I guess. -- BEWARE! People acting under the influence of human nature.
Re: RFC 161 (v4) Everything in Perl becomes an object.
2000-09-27-15:08:10 Simon Cozens: Never too late to withdraw, sir. [1] The less crap we make Larry wade through, the better. Regarding the specific issue at hand, could you please offer something more specific than "you'd like it withdrawn"? Is there a reason why it's impossible to implement without performance penalty, or why it must have a detrimental effect on the language? I'd cite ruby as an indication that it shouldn't have to inflict any performance hit, and ruby, as well as the obvious utility of bringing to bear O-O overloading techniques, as benefits it could offer the language. And I don't see why it has to be an obtrusive change at all. -Bennett PGP signature
Re: RFC 161 (v4) Everything in Perl becomes an object.
On Wed, Sep 27, 2000 at 12:43:45PM -0700, Nathan Wiger wrote: As list chair, I ask either: 1. The people discussing this clarify themselves 2. The people discussing this please drop it Ho hum. You've heard, I believe, my arguments now. I'm happy to drop the matter, since it seems a ridiculous waste of time anyway. -- As the saying goes, if you give a man a fish, he eats for a day. If you teach him to grep for fish, he'll leave you alone all weekend. If you encourage him to beg for fish, pretty soon c.l.p.misc will smell like a three-week-dead trout.-- Tom Phoenix, c.l.p.misc.
Re: RFC 161 (v4) Everything in Perl becomes an object.
On Wed, Sep 27, 2000 at 12:16:36PM -0700, Matt Youell wrote: I open to hearing your reasons. The biggest reason it wasn't withdrawn is because someone said "hey don't do that, here's why". So give me a "why" already... It doesn't feel right to me. It doesn't feel Perlish. That's it? Matt
Re: RFC 198 (v2) Boolean Regexes
HI Tom, Welcome to England (I presume) This seems very complicated. Did you look at the Ram:6 recipe on expressing AND, OR, and NOT in a regex? For example, to do /FOO/ /BAR/ you need not write /FOO.*BAR|BAR.*FOO/ -- and in fact, should not, as it doesn't work properly on some pairs! For example, /CAN/ /ANAL/ can't be written /CAN.*ANAL|ANAL.*CAN/ of you expect to match "CANAL". Overlaps bite you. You really need /(?=.*CAN)(?=.*ANAL)/ instead, which permits multiple assertions. Please check out the recipe I'm talking about. --tom, from a strange place I will start by admiting I dont have the RAM. I was brainstorming ideas (my day job involves a lot of brainstorming) and trying to think of new/better ways to do things. I am more interested in concepts than syntax. Richard
is \1 vs $1 a necessary distinction?
Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any reason not to standardize these down to one notation (i.e., eliminate one or the other)? Dave
Re: is \1 vs $1 a necessary distinction?
On Wed, Sep 27, 2000 at 08:15:53AM -0700, Dave Storrs wrote: Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any reason not to standardize these down to one notation (i.e., eliminate one or the other)? \1 can be used on the LHS of a s/// whereas $1 there probably won't do what you expect. Also, \1, \2, \3 only takes you as far as \9 ;-) If $1 could be made to work properly on the LHS of s///, I'd vote for that being The Way. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: is \1 vs $1 a necessary distinction?
On Wed, 27 Sep 2000, 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. That was pretty much my thought?
Re: is \1 vs $1 a necessary distinction?
"DS" == Dave Storrs [EMAIL PROTECTED] writes: DS Both \1 and $1 refer to what is matched by the first set of parens DS in a regex. AFAIK, the only difference between these two notation DS is that \1 is used within the regex itself and $1 is used outside DS of the regex. Is there any reason not to standardize these down DS to one notation (i.e., eliminate one or the other)? because $1 having be set previously will be interpolated INTO the new regex. so you have to have another notation to refer to grabbed stuff from the current regex. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: is \1 vs $1 a necessary distinction?
"Jonathan" == Jonathan Scott Duff [EMAIL PROTECTED] writes: Jonathan On Wed, Sep 27, 2000 at 08:15:53AM -0700, Dave Storrs wrote: Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any reason not to standardize these down to one notation (i.e., eliminate one or the other)? Jonathan \1 can be used on the LHS of a s/// whereas $1 there probably won't do Jonathan what you expect. Also, \1, \2, \3 only takes you as far as \9 ;-) Wrong. If you have more than 10 parens visible so far, \10 works just fine. Jonathan If $1 could be made to work properly on the LHS of s///, I'd vote for Jonathan that being The Way. It can't ever. It means $1 from the previous match. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: is \1 vs $1 a necessary distinction?
On 27 Sep 2000, Piers Cawley wrote:
Do we *want* to maintain \1? Why have two notations to do the
I'm kind of curious about what happens when you want to do, say:
if (m/(\S+)/) {
$reg = qr{(em|i|b)($1)/\1};
}
where the $1 in the regex quote is refering to $1 from the previous
regex match.
Well, how about this:
$reg = qr{(em|i|b)(${P1})/\1};
NOTE: ^
If you assume that $1 and ${1} are equivalent (which makes it
possible to have as many backrefs as you want), then you could say that,
if the first character after the { is a P, it means "in the previous regex
match."
Dave
Re: is \1 vs $1 a necessary distinction?
On Wed 27 Sep, Dave Storrs wrote:
On Wed, 27 Sep 2000, Richard Proctor wrote:
Both \1 and $1 refer to what is matched by the first set of parens in a
regex. AFAIK, the only difference between these two notation is that
\1 is used within the regex itself and $1 is used outside of the
regex. Is there any reason not to standardize these down to one
notation (i.e., eliminate one or the other)?
I think this is fixable.
The way you phrase that makes it sound that other people perceive
this as a problem as well, which gives me all sorts of warm fuzzies. :
The only real need for this at the moment is to overcome limitations in
the order of expansion of regexes. RFCs 112, 166, 276... all depend on
fixing this.
Ok, here's another question. How the _HELL_ does everyone else on
this bloody list keep track of every detail in every frigging RFC? Some
random comment comes up, and someone will go, "Oh, the third paragraph of
the second section in RFC 0x97A already mentioned this as a parenthetical
aside, despite the fact that its title and primary topic had no relation
to the issue." I still have (mumble-mumble) RFCs that I haven't even had
time to *read*, let alone memorize every detail of!
In this context I was the author of guess what 112, 166 and 276 (though
I admit to having to look up the number of the last one)
Grr*grumble, grumble, moan, winge*
Ok, back to rationality now.
If the regex compiler gets in before the expansion of the variables to
make these work, it could handle $1 in all cases \1 can be retained for
compatibility.
Do we *want* to maintain \1? Why have two notations to do the
same thing when one is clearly superior? (\1 can only go up to \9 while
the other could theoretically go to ${...}.) Perl6 is breaking
backwards compatibility and eliminating all deprecated features...let's
get rid of \n as backreference notation.
The principle issue would be what to do about use of $1 on the LHS having
its current meaning. Which is rather good for obfuscated code, but not
terribly kind on normal programming.
Note RFC 112 covers assignment within a regex naming rather than numbering
the brackets one wishes to capture, it also covers named back references.
Currently $1 is expanded by the quoting currently before the regex compiler
gets to play, the regex compiler sees the \1 and knows what to do. \ meaning
refer back I am reasonably happy with, the numbers I am not.
Richard
--
[EMAIL PROTECTED]
Re: Perlstorm #0040
==
I lie: the other reason qr{} currently doesn't behave like that is
that
when we interpolate a compiled regexp into a context that requires
it be
recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They should
be treated as subroutine calls. Unfortunately, this requires a
reentrant regex engine, which Perl doesn't have. But I think it's the
right way to go, and it would solve the backreference problem, as well
as many other related problems.
==
The REx engine is reenterant enough right now. All you need to do is
to add the //p switch (or, meanwhile, rewrite each $qrn into (?p{ $qrn })).
Ilya
Re: RFC 106 (v2) Yet another lexical variable proposal: lexical variables made default
I know it's unfair to comment on a frozen RFC, but I think it's
important to note a few things:
On Wed, Sep 27, 2000 at 05:22:30AM -, Perl6 RFC Librarian wrote:
Maintainer: J. David Blackstone [EMAIL PROTECTED]
Status: Frozen
[snip]
Dubbed the "conservative" approach by Mark-Jason Dominus, this option
requires that the programmer disambiguate the situation by declaring
the variable with Cmy. Perl would produce a warning in this case to
the effect that, "A variable used within a block was used after that
block, but never declared or used before it. The enclosing scope
cannot see the same variable that exists within the enclosed block."
Alternatively, if this RFC is adopted, but nothing is done to alert
new Perl6 programmers about these possibly ambiguous cases, the
programmer would receive a "Use of undefined value" warning which
might suffice.
This approach to the problem is problematic to me. I, as most, Cuse
strict in any code of reasonable length. But I'm also very used to
doing something like:
[~] $ perl -wle'while() { ++$foo last if /bar/ } if ($foo) {
print "used last" }'
With the "conservative" approach, this will not DWIM. I'll get some kind
of warning about it, but having to predeclare $foo will not make me
happy.
In the "liberal" approach, perl can do what amounts to "inferring
declarations." To actually refer to it this way would be a
contradiction in terms, since a declaration is explicit, not inferred.
To implement the liberal approach, perl would detect all of the
undeclared variables used within a scope when it compiles that scope.
These variables would become available for use from the minute that
scope is entered. Thus, in the example above, $color is detected as
being a part of the enclosing scope before the interpreter ever enters
the if statement, and $color therefore refers to the same scalar in
both places.
It was observed that this approach could also be implemented by
inferring a variable to be declared at the top-level, the largest
enclosing scope. It does not appear that there would be any
language-visible differences in this implementation, although it would
certainly be different to the implementors.
Erm, but this approach _really_ worries me. Doing things this way is
taking away the whole point of lexically scoped variables!
{
$foo = 0;
sub should_be_closure { $foo++ }
}
...
print "The value of foo is ", ++$foo, "\n";
Eh? We can modify the value of that variable way down here at the bottom
of the file? That's basically useless.
Obviously if you want that closure, you declare Cmy $foo in the scope
that's wanted, but I'm not seeing what this approach is buying us from
the current state of affairs.
It's possible that I'm missing something, though, and I do apologize for
not saying this earlier. After initial discussion died down on -strict,
I neglected to ever go back and say anything.
-dlc
Re: RFC 324 (v1) Extend AUTOLOAD functionality to AUTOGLOB
The AUTOGLOB subroutine should expect to take two parameters, the invocant, and a second parameter specifying what type of item is being AUTOGLOBbed, followed by - in the case of a sub - the sub's arguments. We suggest that the second parameter should be a scalar value - 'scalar' for an AUTOGLOBbed scalar, 'array' for an AUTOGLOBbed array, and so on. This is an interesting idea, but I don't think that a single AUTOGLOB, that has to internally decide what to do based on a string match of one of its arguments, is the best way to go for this. I think TIE has it right: AUTOSCALAR AUTOARRAY AUTOHASH AUTOLOAD This actually has an advantage - in inheritance, you can polymorphically inherit some or all of the AUTO* routines without having to rewrite the whole sub. The $AUTOLOAD variable should be renamed to $AUTOGLOB (with $AUTOLOAD as a deprecated synonym as above). As RFC 8 hints at, $AUTOLOAD should die completely. Make the name of the variable or sub an argument. This has another benefit in that the name of the variable is going to be passed into TIE* as well in Perl 6. Very nice symmetry. -Nate
Re: RFC 290 (v1) Remove -X
Uri Guttman [EMAIL PROTECTED] writes: "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: I'll revise the RFC to add 'readable()', 'writable()', and such synonyms for -r and -w that are more like 'use english' and less like 'use English'. i have a minor problem with the names readable and writeable. i am currently using them as method names in a major project i have created. they are callbacks (see my recent callback rfc) which mean the socket is readable/writeable. maybe put some sort of prefix on them to designate them as file test operators so we don't clutter up the namespace so much. also the common prefix will make it clear tha tthey are part of the family of file test ops. here are some ideas which you can shoot down: a minus prefix like the current -r -readable -tty or has_ as the file has read permission: has_readable has_executable or is_ if the file is a text file: is_text is_sticky is_writable I refer you to my previous message (archived in http://tmtowtdi.perl.org/archive?35:mss:4575). Basically, not have a prefix predicates should have! Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 290 (v1) Remove -X
On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? -- Bart.
Re: RFC 290 (v1) Remove -X
On Wed, Sep 27, 2000 at 08:50:28AM +0200, Bart Lateur wrote: On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? Doesn't work on scalars. Unless every scalar should have a 'readable()' method *just in case* it could contain a filename. Not sure I like that. I just drafted a set of methods. The basic problem is -e = exists(), and -S = socket(), which are already taken. I didn't like the idea of -e = present(), and I couldn't think of a synonym for exists that begins with 'e', nor a synonym for socket that begins with 's'. :-) If that isn't enough, I think we all forgot about thie difference between -r and -R, which *really confuses things. Is one of them more readable than the other? It's late, and I'm just going through another revision of 4 of my last 5, and I went with f*() and F*() for the -RWX. Not as bad as filetest::readable() filetest::really_readable() filetest::exists() filetest::socket() ... Update to be posted as soon as the left hand finds out what the right hand was doing... Z.
Re: RFC 290 (v2) Better english names for -X
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL -r freadable() PRL -w fwriteable() PRL -x fexecable() PRL -o fowned() PRL -R Freadable() PRL -W Fwriteable() PRL -X Fexecable() PRL -O Fowned() PRL -e fexists() PRL -z fzero() PRL -s fsize() PRL -f ffile() PRL -d fdir() PRL -l flink() PRL -p fpipe() PRL -S fsocket() PRL -b fblock() PRL -c fchar() PRL -t ftty() PRL -u fsetuid() PRL -g fsetgid() PRL -k fsticky() PRL -T ftext() PRL -B fbinary() PRL -M fage() PRL -A faccessed() PRL -C fchanged() this looks decent to me. maybe make the prefix f_ to make it a little more readable (overriding that word again! :)? also f/Fexecable() looks very odd. is that your choice or were your right and left hands fighting again? executable is probably the better term and who cares about 2 chars more if you are using this. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 290 (v2) Better english names for -X
On Wed, Sep 27, 2000 at 03:48:33AM -0400, Uri Guttman wrote: "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL -r freadable() PRL -w fwriteable() PRL -x fexecable() PRL -o fowned() PRL -R Freadable() PRL -W Fwriteable() PRL -X Fexecable() PRL -O Fowned() this looks decent to me. Well, it leaves readable for AIO callbacks, so of course you're going to say that. :-) I reserve the right to switch to readable/writeable iff the socket/exists issue has a resolution. Thoughts anyone? maybe make the prefix f_ to make it a little more readable (overriding that word again! :)? I can't think of any builtins that use _, but it's going to be exposed by use english, so perhaps that qualifies it. I'm on the fence though. If it's going to be *_writeable, is_writable() looks better. It is tom's original proposal, after all. also f/Fexecable() looks very odd. Patches welcome for f/F. is that your choice or were your right and left hands fighting again? executable is probably the better term and who cares about 2 chars more if you are using this. No, I chose execable intentionally. Probably change it to executable in v3 anyway. Z.
Re: RFC 290 (v2) Better english names for -X
"AT" == Adam Turoff [EMAIL PROTECTED] writes: AT I can't think of any builtins that use _, but it's going to be AT exposed by use english, so perhaps that qualifies it. I'm AT on the fence though. If it's going to be *_writeable, is_writable() AT looks better. It is tom's original proposal, after all. fine with me. but i like f_ (or plain f) better as is_ doesn't work well with access/modified etc. using f/F is more consistant and marks them as file tests. AT Patches welcome for f/F. that was about the execable part, not the f/F AT No, I chose execable intentionally. Probably change it to executable AT in v3 anyway. who gave you permission to invent new words? :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 288 (v2) First-Class CGI Support
* Perl6 RFC Librarian ([EMAIL PROTECTED]) [27 Sep 2000 18:36]: [] [...] When this pragma is loaded, it should replace the print coderef with a function that will print out all headers in the @HEADERS queue, print out the desired output, and restore the print coderef. It should also ensure that the filehandle it is printing to is STDOUT, not something else. Otherwise if we fork to print stuff to, say, SENDMAIL, then things will go screwy. Was something to go happen about that headers() function or Headers module, or did you decide we'll go for the latter and just write and distribute it on CPAN? What format does @HEADERS entries take? Are they straight "xxx: yyy" or would it be better to have a function neatly join things so people don't felch up their syntax quite so easily? Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ You know you are addicted to coffee if... 6 You've worn out your third pair of tennis shoes this week.
Re: perl6storm #0050
On 26 Sep 2000, Johan Vromans wrote: Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What an idea! I wonder why no language has tried this before. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: perl6storm #0050
On 26 Sep 2000, Johan Vromans wrote: Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. Since when do parentheses make things less readable? Each parenthesis is one "token". The more tokens you need to process, to more you need to think. (Especially if there is little whitespace, but to some extent also if not.) What is your definition of readable? "I know it when I see it". I don't have a definition that I can put in words. But it probably involves whitespace between tokens and the number of tokens. Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: perl6storm #0050
Robert Mathews [EMAIL PROTECTED] writes: Simon Cozens wrote: (defun Schwartzian (func list) (mapcar (lambda (x) (car x)) (sort (mapcar (lambda (x) (cons x (funcall func x))) list ) (lambda (x y) ( (cdr x) (cdr y))) ) ) ) Maybe you'd prefer this: defun Schwartzian func list mapcar lambda x car x sort mapcar lambda x cons x funcall func x list lambda x y cdr x cdr y I know which I'd rather read. Ok, you've proved that lisp doesn't make sense without all those annoying parentheses. 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.
Re: perl6storm #0050
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 19:54]:
On 26 Sep 2000, Johan Vromans wrote:
[...]
By the same reasoning, you can reduce the use of curlies by using
indentation to define block structure.
What an idea! I wonder why no language has tried this before.
I realise you're being sarcastic here, but my serious reply is "because
it reduces readability".
It forces the concept that all statements are equal.
Do you really want to see:
@sorted = sort
$b cmp $a
@lines;
Hmm. Not entirely sure how that indenting went. Let's try again:
@sorted = sort
$b cmp $a
@lines;
Maybe:
@sorted = sort
$b cmp $a
@lines;
I know!
@sorted = sort { $b cmp $a } @lines;
Works brilliantly!
People are probably thinking "no: just for for() while() and so on."
I'm thinking "consistency is the key to everything, including my tomato
soup". Do it one place, it should be eligible everywhere.
And maybe I want to write simple accesors like:
sub title { $_[0]-{'title'} }
Not as clear as
sub title
{
my $self = shift;
return $self-{'title'};
}
But clearer than
sub title
my $self = shift;
return $self-{'title'};
Which really needs something to end it with (such as 'endsub') otherwise
for more complicated routines it is hard to see where your function is
ending. Those { } do have more than just a syntactic use. They provide a
visual aid to the delineation of blocks.
Anyway. That was my irrelevant rant for the day. Erm. I'll go away now.
cheers,
--
iain truskett, aka Koschei.http://eh.org/~koschei/
You know you are addicted to coffee if...
7 Your eyes stay open when you sneeze.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. 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: Intent to RFC #0101
./sun4-solaris/POSIX.pm:sub isatty {
./sun4-solaris/B/Deparse.pm:sub is_scope {
./sun4-solaris/B/Deparse.pm:sub is_state {
./sun4-solaris/B/Deparse.pm:sub is_miniwhile { # check for one-line loop
(`foo() while $y--')
./sun4-solaris/B/Deparse.pm:sub is_scalar {
./sun4-solaris/B/Deparse.pm:sub is_subscriptable {
./CGI.pm:sub isindex {
./CPAN.pm:sub is_reachable {
./CPAN.pm:sub isa_perl {
./Pod/Select.pm:sub is_selected {
./ExtUtils/Embed.pm:sub is_cmd { $0 eq '-e' }
./ExtUtils/Embed.pm:sub is_perl_object {
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
On Wed, Sep 27, 2000 at 09:52:57AM +0100, 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. I'd go further than that. It's clear what's going on for a number of reasons. Firstly, you know the language. Secondly, you know what it's trying to do because the function and the variables are well named. Thirdly, I used whitespace and indentation to make the various levels apparent - that's why I removed the whitespace on the second example. There are many other tricks for making code readable, and whether or not the language supports bracketing or, indeed, any other feature is more or less irrelevant to all of them. You can write clear code in any language, if you take the time; you can write Python in any language, if you want. Readability is a programmer feature, not a language feature. -- "There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: The concept of Cnull as opposed to Cundef is sometimes difficult for people to understand. "People" in this context being the people who are reading perl6-language and purporting to be able to know what Perl 6 needs. People who ought to really understand Perl and how it works. If this concept is too difficult for them, then it really shouldn't exist. KISS. -- If the code and the comments disagree, then both are probably wrong. -- Norm Schryer
Re: perl6storm #0050
Simon Cozens [EMAIL PROTECTED] writes: Readability is a programmer feature, not a language feature. The most important optimization a programmer can make is to optimize for understanding. -- Piers
RE: RFC 263 (v1) Add null() keyword and fundamental data type
On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen [SMTP:[EMAIL PROTECTED]] wrote: This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Quote from Larry: "I have a particular distaste for the sort of argument that goes, 'If I can't have it my way, I'm going to take all my marbles and go home.' That's not an argument--that's nuclear blackmail. I'm the only one who's allowed to make that sort argument, and you'll never hear me making it." On the other hand, I have to agree with the core sentiments. All this talk about nulls and strong types and everything-is-an-object is frankly scaring the willies out of me. Maybe perl does need a revamp, but it should still stay perl. I'm a perl programmer, not a Visual PerlBOLthonajaffellispQL++ robot. Perl has always stood on these: There is more than one way to do it. (Public/private OOP?) No arbitrary limits. (Everything is an object? Exceptions getting in the way of open(FILE,"file") or die "$!\n"? Hard typing?) We're very proud of our language that doesn't force us to put an if before or after a statement, and doesn't care whether we indent one tab per block level, and doesn't belch out exceptions at us if we forget the ungodly mess of exception classes, and allows sheep to sleep and die if I feel poetic. Perl is Perl. It isn't Java. It isn't C++. It isn't Python (thank goodness). Maybe there are a few nifties we can borrow from those creations, but twisting the language inside out to make it closely resemble something second or third or fourth best is quite distasteful. We're improving a language here, not creating a new one. Again from Larry: "At the moment, I'm not only trying to follow along here; I'm also reading all the books on computer languaes I can get my hands on--not just to look for ideas to steal, but also to remind myself of the mindset Perl was designed to escape." and nate: "If you want Ada, you know where to find it" There are a lot of good ideas in these RFC's. Lot of wishing it was language X too, which I can't see as a good thing. Map to null, work around the problem. It takes, what, one line of code to do so? This isn't C where it would take 20 or C++ where it would take 200. But having a real switch statement... that's been on the table for years now... and having parseable regex syntax, fine.
Re: RFC 292 (v1) Extensions to the perl debugger
[Quoting Dave Storrs, on September 26 2000, 11:47, in "Re: RFC 292 (v1) Ext"] I'm confused...are you suggesting that the debugger should no longer be integrated into perl? Absolutely not! What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two independently scrollable windows, one for input and one for output). External tools should manage that. I mentioned the way the perl debugger runs under Emacs, ptkdb is another good example. BTW: the debugger already has command line recall/editing using Term::ReadLine. -- Johan
Re: RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin
On Tue, 26 Sep 2000, Nathan Wiger wrote: John Porter wrote: Yeah, not to mention the fact that many modules, notably CGI.pm, are arranged to allow to use unquoted strings of the form -name: print textfield( -name = 'description' ); Well, this one's not an issue, because = auto-quotes the LHS. It's the same as this: print textfield( "-name", 'description' ); Actually, more like this: print textfield( -'name', 'description' ); Try putting it through -MO=Deparse. I guess the quoting behaviour of = "binds" more strongly than the hyphen, so that "-name =" is interpreted as unary minus + bareword 'name' + big arrow, leading to unary minus + quoted bareword 'name' + big arrow, which is equivalent to - "name" and a comma. Fortunately, - "string" doesn't convert "string" to a number (0) and then apply negation but results in "-string" (`perldoc perlop` says: "If the operand is an identifier, a string consisting of a minus sign concatenated with the identifier is returned. [...] One effect of these rules is that `-bareword' is equivalent to `"-bareword"'." Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: RFC 288 (v2) First-Class CGI Support
* Philip Newton ([EMAIL PROTECTED]) [27 Sep 2000 22:51]: On Wed, 27 Sep 2000, iain truskett wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which order they come. Then, if HTTP/4.2 comes out with the [...] Better to have something that's either (a) pluggable without having to replace all of Perl, or (b) header-agnostic, so you have to specify your own ordering -- which also means you *can* specify your own ordering. 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? cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ The best effect of any book is that it excites the reader to self activity. Thomas Carlyle
Re: Perl6Storm: Intent to RFC #0101
You suggested: file($file, 'w'); # is it writeable? That's really insane. The goal was to produce code that's legible. That is hardly better. It's much worse than is_writable or writable or whatnot. Just use -w if that's what you want. --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 259 (v2) Builtins : Make use of hashref context for garrulous builtins
grep -l Class::Struct */*.pm Class/Struct.pm File/stat.pm Net/hostent.pm Net/netent.pm Net/protoent.pm Net/servent.pm Time/gmtime.pm Time/localtime.pm Time/tm.pm User/grent.pm User/pwent.pm Please check those out for precedent and practice. 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: Intent to RFC #0101
You suggested:
file($file, 'w'); # is it writeable?
Not that I'm advocating it but you do something like:
test($file, WRITEABLE);
test($file, WRITEABLE READABLE);
...
where constants are defined for various "attributes" to be tested for...
Currently 23, or 3 bytes... (not that it matters ;-)
This seems rather readable and less (name-space) cluttery,
and if it suits you it could be named ftest or somesuch...
Hell you could even make it magical and allow the -X switched enlieu of
constants... Where use English would be required to get the constants.
--
#!/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 Setting Orange, the 51st of Bureaucracy, in the YOLD 3166:
No, just the nipple-cones, officer, just the nipple-cones.
Re: RFC 290 Remove -X
One doesn't remove useful and intuitive syntax just because Mr Bill never put it into MS-BASIC! I merely passingly suggested that there be a use English style alias for these. They are, however, wholly natural to millions of people, and should not be harrassed. (NB: 10 million Linux weenies alone) Still, twould be nice to have -rw and -rx and stuff, too. :-) BTW, -s(FH)/2 is still wickedly broken. 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.
Better Security support (was: RFC 290 (v1) Remove -X)
The -wd syntax (writeable directory) is nicer than file($file, "wd"). But anyway, there's hardly anything wrong with -w -d. Don't understand the complaint. One thing I would really like to see is better security support. Look at the Camel-III's security chapter, File::Temp, and the is_safe stuff I've done lately. 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 303 (v1) Keep Cuse less, but make it work.
Don't change "use less" to "use optimize". We don't need to ruin the cuteness. 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.
RFC 307 (v1) PRAYER - what gets said when you Cbless something
Goodness, no, don't call it "PRAYER". The blessing is one of corporate approval, not ecclesiastical deprecationem. Please don't piss people off. 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 263 (v1) Add null() keyword and fundamental data type
David Grove wrote: On Wednesday, September 27, 2000 4:17 AM, Tom Christiansen wrote: This is screaming mad. I will become perl6's greatest detractor and anti-campaigner if this nullcrap happens. And I will never shut up about it, either. Mark my words. Quote from Larry: "I have a particular distaste for the sort of argument that goes, 'If I can't have it my way, I'm going to take all my marbles and go home.' That's not an argument--that's nuclear blackmail. I'm the only one who's allowed to make that sort argument, and you'll never hear me making it." Yes, and this RFC was already retracted, so flames are particularly silly. So could we all please let it die and comment on the 'use tristate' alternative proposed in RFC 275? -Nate
RE: perl6storm #0050
On Wednesday, September 27, 2000 10:21 AM, John Porter [SMTP:[EMAIL PROTECTED]] wrote: Philip Newton wrote: On 26 Sep 2000, Johan Vromans wrote: By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. What an idea! I wonder why no language has tried this before. It's a question of what the language allows vs. what it requires. Perl is nice because it allows you to write in (nearly) any style you want -- lots of parens, no whitespace... Requiring the use of parens is about as un-perl-like as requiring indentation to denote blocks. Although I have no interest in saying anything supportive of this idea, I think it would be dreadfully funny if Python suddenly lost its primary point of advocacy against the Perl language just because we allowed (not required) blocks by indentation. Maybe then they'd stop invading perl5-advocacy. ;-)) But no thanks: pass. (Is that sys.pass() or language.pass()?)
Re: RFC 303 (v1) Keep Cuse less, but make it work.
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. -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn
Re: RFC 290 (v2) Better english names for -X
Adam Turoff wrote: PRL -r freadable() PRL -w fwriteable() PRL -x fexecable() PRL -o fowned() PRL -R Freadable() PRL -W Fwriteable() PRL -X Fexecable() PRL -O Fowned() this looks decent to me. I reserve the right to switch to readable/writeable iff the socket/exists issue has a resolution. Thoughts anyone? I actually like the above because of the common prefix. It makes it quite clear these are file tests. maybe make the prefix f_ to make it a little more readable (overriding that word again! :)? I can't think of any builtins that use _ Indeed, no builtins include _. In fact, the warning Unquoted string "stuff" may clash with future reserved word is only raised if: You used a bareword that might someday be claimed as a reserved word. It's best to put such a word in quotes, or capitalize it somehow, or insert an underbar into it. also f/Fexecable() looks very odd. Patches welcome for f/F. Yeah, mixed case gives me the willies! Bigtime. Plus, see above. Here's some: frealreadable() frealwriteable() frealexecable() frealowned I was going to list other alternatives, but I think those work just fine, personally. Long is not necessarily bad; this is "use english" after all. -Nate
Re: RFC 288 (v2) First-Class CGI Support
On Wed, Sep 27, 2000 at 07:36:42AM -, Perl6 RFC Librarian wrote: Tainting should be able to be turned off, as Tom recommends, but only if the user turns on the "absolutely, positively, do NOT turn on taint mode" switch. I can see it now -- Cno taint 'really';. Really, I don't see why we can't just have a 'use taint' and 'no taint' pargma. You have to turn on tainting at the commandline, but other then that, you can turn it on and off (even Cuse taint 'warning', possibly) at runtime. Doing so is probably not a good idea in the vast majority of cases, but should still be supported. Perl should have a safety on its guns, but shouldn't prevent you from shooting yourself in the foot if you really want to. Otherwise, perl would be another BD language. In specific, I can see a suid script dropping permissions, and then doing a 'no taint' so it can run freely in the end-user's account. Think cgi_wrapper without spawning a new interpreter. -=- James Mastros -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GUCS d--- s-:- a20 C++ UL+++@ P L++@ E-() N o? K? w@ M-- !V PS++ PE Y+ PGP(-) t++@ 5+ X+++ R+ tv+ b+++ DI+ D+ G e++ h! r- y? --END GEEK CODE BLOCK--
Re: RFC 292 (v1) Extensions to the perl debugger
On Wed, 27 Sep 2000, Johan Vromans wrote: What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two independently scrollable windows, one for input and one for output). External tools should manage that. I mentioned the way the perl debugger runs under Emacs, ptkdb is another good example. BTW: the debugger already has command line recall/editing using Term::ReadLine. I disagree. I want to have perl provide reasonable default behavior for these extremely useful and commonly-desired functions, and I don't want it to be dependent on modules from outside the core or on requiring the user to configure something (after all, if the user must configure it, it's not default). I want perl to provide me with a standard interface which satsifies my basic requirements. I want this interface to be the same on all platforms so I don't need to get used to "oh yeah, today I'm on the Windows box, so it's Shift-UpArrow for the command history." I'm not saying that outside tools shouldn't be built to provide _better_ versions of the standard behavior, or nicer UIs. I'm just saying that the basic versions are not acceptable, and should be improved and standardized. Dave
Re: RFC 303 (v1) Keep Cuse less, but make it work.
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? -- piers
Re: RFC 19 (v2) Rename the Clocal operator
Rename the Clocal operator A list of other proposed replacement names includes (but is not limited to, since I certainly have forgotten some): Cnow Unfortunately, I wish this RFC would have taken a stand on at least a first choice. :-( I always thought that "now" was by far the most descriptive, because these changes really are scoped in time, and not location (since they reach throughout code). Plus, it's short. Short good. I also thought there was considerable consensus on this one, at least more than any of the others: http://www.mail-archive.com/perl6-language@perl.org/msg01174.html http://www.mail-archive.com/perl6-language@perl.org/msg01245.html http://www.mail-archive.com/perl6-language@perl.org/msg01266.html http://www.mail-archive.com/perl6-language@perl.org/msg01294.html Plus you didn't even mention my "here" suggestion (which is fine, actually, because I like "now" better anyways). :-) -Nate
Re: RFC 288 (v2) First-Class CGI Support
On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote: Really, I don't see why we can't just have a 'use taint' and 'no taint' pargma. Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. Z.
Re: RFC 288 (v2) First-Class CGI Support
Philip Newton wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which order they come. Then, if HTTP/4.2 comes out with the Toast: light|medium|dark header, which has to come after the new Breakfast: header Wait, you're both right! ;-) Personally, I'd like to see a simple version of CGI::header be embedded in core. HTTP-type headers are widely used in many applications. So you could have: @HEADERS = header(content-type = 'text/html', toast = 'medium', # not too crispy breakfast = 'yes'); Under normal life, @HEADERS would just be some variable. But the "use cgi" pragma could simply flush @HEADERS out ahead of time before your output stream. If @HEADERS is empty, the "use cgi" pragma just prints out "Content-type: text/html\n\n"; Note that HTTP-style headers are used lots of other places: @mail_header = header(from = '[EMAIL PROTECTED]', to = '[EMAIL PROTECTED]'); print $MAILPIPE @mail_header, @mail_message; So, the formatting of and the auto-printing of cgi headers are really two separate things. 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? -Nate
Re: RFC 303 (v1) Keep Cuse less, but make it work.
Piers Cawley wrote: Simon Cozens [EMAIL PROTECTED] writes: "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? Or have perl enforce the correct grammar. % perl -w use less 'calories'; syntax error at - line 1, near "use less" Execution of - aborted due to compilation errors. But on a tangential note: has anyone proposed letting functions, perhaps by prototype, allow the autoquoting of arguments? Why should we not be able to write use fewer sewers; and have it dwim? -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: RFC 303 (v1) Keep Cuse less, but make it work.
On Wed, Sep 27, 2000 at 02:45:24PM -0400, John Porter wrote: But on a tangential note: has anyone proposed letting functions, perhaps by prototype, allow the autoquoting of arguments? I thought about it, but it's hard to know when to stop. use fewer sewers; would be fine, and I'd like to see it work, but what I *really* wanted was l((apply foo (mapcar bar (@wibble -- In related wibbling, I can see an opening for the four lusers of the Apocalypse... "I didn't change anything", "My e-mail doesn't work", "I can't print" and "Is the network broken?". - Paul Mc Auley
Re: RFC 303 (v1) Keep Cuse less, but make it work.
Simon Cozens wrote: I thought about it, but it's hard to know when to stop. Yep. If you don't stop, pretty soon you have sh. :-P l((apply foo (mapcar bar (@wibble pragma time: use literal qw( apply mapcar http://www.perl.org/ ); use LWP::Simple; getprint http://www.perl.org/; Oh No! Rebol! -P -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
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. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
Simon Cozens wrote: Readability is a programmer feature, not a language feature. Right. Parens, and other devices for "readability", are there for the user to use, if she chooses. Perl is not about forcing a certain style. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: perl6storm #0050
On Wed, Sep 27, 2000 at 03:35:39PM -0400, John Porter wrote: Yes, but it's hard to read. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. Perl is English-like. And sometimes in English parentheses *are* necessary to increase both meaning and readability, as your own message proves. -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. - Paul Tomblin, in the monastery.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
At 10:26 AM 9/27/00 +0100, Simon Cozens wrote: On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: The concept of Cnull as opposed to Cundef is sometimes difficult for people to understand. "People" in this context being the people who are reading perl6-language and purporting to be able to know what Perl 6 needs. People who ought to really understand Perl and how it works. If this concept is too difficult for them, then it really shouldn't exist. KISS. SQL's NULL is an interesting and rather useful concept, though it's fairly mind-bending if you've not had much reason to use it. (The same can be said for OO programming, undef, and regular expressions) Whether (and how) it should be in perl is another matter entirely, of course. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 288 (v2) First-Class CGI Support
At 02:20 PM 9/27/00 -0400, Adam Turoff wrote: On Wed, Sep 27, 2000 at 12:09:20PM -0400, James Mastros wrote: Really, I don't see why we can't just have a 'use taint' and 'no taint' pargma. Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. 'no taint' does make sense, though 'use taint' might not except to locally undo 'no taint'. Whether it's feasable in a program that's not invoked with taint checking depends on how much the parser depends on the potentially icky before parsing's complete. Of course, we can always maintain tainting status and just ignore it unless we're in a taint-checking block. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 288 (v2) First-Class CGI Support
Sounds good. I'll start on my 39th :-{ RFC right now... ;-)
-Nate
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...
It has uses in HTTP, CGI and SMTP contexts, probably others. Would
be nice if there were some sort of interaction with 'open http $url' as
well. Perhaps that would be what supplies %HTTP (or %HEADERS) for
incoming headers and does trickery with print and @HEADERS...
Z.
Re: perl6storm #0050
Simon Cozens wrote: Perl is English-like. And sometimes in English parentheses *are* necessary to increase both meaning and readability, as your own message proves. That's rather disingenuous, since perl does not use parens for the same purpose English does. Parens are necessary in a programming language to override the default precedence. (Wouldn't it be nice if we used them in English for that. Alas.) "Meaning" is not "increased". Whether readability is enhanced is debatable. I tend to think not. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: RFC 288 (v2) First-Class CGI Support
Dan Sugalski wrote: Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. 'no taint' does make sense, though 'use taint' might not except to locally undo 'no taint'. Actually, from my talks with Larry both on and off-list about this, he convinced me pretty strongly that the only thing that really makes sense is untainting data sources. And this should be done via $fh-untaint, which already exists. The original email was here: http://www.mail-archive.com/perl6-language@perl.org/msg00394.html Follow the thread a little for details. A "no taint 'checking'" seems like an interesting idea, but I'm not sure providing lots of ways around tainting is what we want... -Nate
Re: perl6storm #0050
At 03:35 PM 9/27/00 -0400, John Porter wrote: 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. Lisp requires parens, because it has no precedence rules. (Well, hardly any). It has (almost) no other syntax. This is the situation we would like to avoid in perl. By letting every operator have well-defined precedence, and every be function well prototyped, there should never be any ambiguity (to the compiler, at least) as to what is meant, even with no parens. Ideally, anyway. 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. -- John Porter Aus des Weltalls ferne funken Radiosterne.
Re: RFC 288 (v2) First-Class CGI Support
At 12:52 PM 9/27/00 -0700, Nathan Wiger wrote: Dan Sugalski wrote: Because taint mode needs to be turned on REEELY early, like before pragmas are compiled. 'no taint' does make sense, though 'use taint' might not except to locally undo 'no taint'. Actually, from my talks with Larry both on and off-list about this, he convinced me pretty strongly that the only thing that really makes sense is untainting data sources. And this should be done via $fh-untaint, which already exists. 'no taint' and 'use taint' shouldn't affect whether data is tainted--the rules for that should stay in effect. What they should alter instead is perl's response to tainted data while they're in effect. In a 'use taint' block perl should check, while in a 'no taint' block it shouldn't. That does make rather a lot of sense, though it's arguable whether it's a good idea if you don't know what you're doing. That's never been perl's problem, though... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 262 (v1) Index Attribute
Webmaster wrote:
What would really be nice here is an Cindex function, similar to the
scalar version, that returns the index of the matching entry in a list. For
instance:
my $n=0;
foreach (@items){
print "Found It at position $n!\n" if /$seek/;
$n++;
}
Could be replaced by:
if (my $n = arrindex( @items, $seek )) {
print "Found It at position $n!\n" ;
}
Grant M.
[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
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"A taste so good that we stand behind every bottle and can."
Re: RFC 288 (v2) First-Class CGI Support
Parse the CGI GET/POST request, returning CGI variables into %CGI
(regardless of the source) in an un-HTTP escaped fashion
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q-param("foo");
Are you going to make the values of %CGI listrefs? That should have
been spelled out before you froze the RFC. Also, it seems a bit
inconvenient if you always have to say C$CGI{bar}[0] when you just
want one value.
Or would you rather have %CGI magically notice what context it's in?
*Shudder*
--
Robert Mathews
Software Engineer
Excite@Home
Re: Perl6Storm: Intent to RFC #0101
Robert Mathews [EMAIL PROTECTED] writes: Nathan Wiger wrote: How many people really "use English" other than beginners? I would use it, but I heard a nasty rumor that it incurs the same penalty as using $' and such. I try to avoid too much line noise in code that has to be maintained. I have a very serious problem with use English, namely that it makes Perl code much more difficult to read and maintain for people who know Perl. Writing something that's marginally easier to understand for a beginner and harder to understand for an expert doesn't strike me as a good idea. I know what $/ does; I double-take at $INPUT_RECORD_SEPARATOR and am never sure whether it's a user's personal global variable or $/ or some other thing. And $ARG and $MATCH both really look like global variables to me and I'd hunt through the program trying to find where they're defined for a while before realizing they're weird use English things. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Perl6Storm: Intent to RFC #0101
Russ Allbery wrote: I have a very serious problem with use English, namely that it makes Perl code much more difficult to read and maintain for people who know Perl ... and don't know use English. Why can't they learn to use it? Are you saying that nothing is worth knowing unless the oldsters know it already? It's not that I want to jam English down everyone's throats. But Nate asked, "does anyone want this," and I said, "yes." Or at least, I would want it if it worked. I know what $/ does; I double-take at $INPUT_RECORD_SEPARATOR and am never sure whether it's a user's personal global variable or $/ or some other thing. And $ARG and $MATCH both really look like global variables to me and I'd hunt through the program trying to find where they're defined for a while before realizing they're weird use English things. You'd learn to recognize the long variable names if you used English regularly. It's a chicken-and-egg problem, but not a very difficult one. -- Robert Mathews Software Engineer Excite@Home
Re: Perl6Storm: Intent to RFC #0101
Russ Allbery wrote:
I have a very serious problem with use English, namely that it makes Perl
code much more difficult to read and maintain for people who know Perl.
Writing something that's marginally easier to understand for a beginner
and harder to understand for an expert doesn't strike me as a good idea.
I know what $/ does; I double-take at $INPUT_RECORD_SEPARATOR and am never
sure whether it's a user's personal global variable or $/ or some other
thing. And $ARG and $MATCH both really look like global variables to me
and I'd hunt through the program trying to find where they're defined
for a while before realizing they're weird use English things.
Fear not, for soon we will be able to do:
use less English;
Per RFC 303. This pragma will enable lovely mnemonics, like:
prn "Line break after this string". $OLS;
/^[A-Z]{3,6}/ { $v = sca rev $MTC };
And they thought Perl was unreadable before... just wait 'til they get a
load of this!
--
Mike Pastore #!Perl Monk Web Coder
[EMAIL PROTECTED] bilogic.org Sys Admin
Re: Perl6Storm: Intent to RFC #0101
Robert Mathews [EMAIL PROTECTED] writes:
... and don't know use English. Why can't they learn to use it?
Why can't the new users of Perl learn the real variable names?
I guess I don't buy the argument that the real names are harder to learn.
Most of them have fairly useful mnemonics, you see them and use them
constantly so they become familiar quickly, and most Perl code out there
uses them.
Are you saying that nothing is worth knowing unless the oldsters know it
already?
\begin{rant}
No, I was not saying that. I was saying exactly what I said. I meant
what I said. If I'd meant something else, I would have said that instead.
\end{rant}
It's not that I want to jam English down everyone's throats. But Nate
asked, "does anyone want this," and I said, "yes." Or at least, I would
want it if it worked.
Hey, I'm not claiming you're trying to jam anything anywhere. We were
discussing use English, and I'm expressing my opinion just like you are.
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, so
I threw in my two cents.
You'd learn to recognize the long variable names if you used English
regularly. It's a chicken-and-egg problem, but not a very difficult
one.
I've yet to understand why I'd *want* to use English regularly; so far as
I can tell, it has essentially no benefit in the long term. Perl is not
now, nor is it likely to ever be, a language that's particularly readable
by people who don't know Perl, and use English in order to learn the
strange names used by use English strikes me as rather circular. Either
the person maintaining the code learns Perl, in which case the use English
names won't be necessary, or they don't, in which case they're unlikely to
be able to maintain the code anyway.
I know it's not the only stance to take, but I prefer to try to make my
Perl code very readable by people who know Perl, and encourage people who
don't know Perl who are trying to read my code to learn Perl first, or at
the same time. There are certainly languages out there that are more
readable for people who don't know the language at all than Perl is, but I
don't find this a particularly important feature in a language. In those
cases where it is, I'd use a language other than Perl.
use English doesn't really address the syntactical points of Perl that
make it hard to read for someone who doesn't know Perl; it strikes me, and
always has struck me, as a bad partial solution to a problem that may not
need to be solved and that only makes things more complicated in the long
run.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 288 (v2) First-Class CGI Support
From: "Dan Sugalski" [EMAIL PROTECTED] To: "Nathan Wiger" [EMAIL PROTECTED] Sent: Wednesday, September 27, 2000 4:08 PM 'no taint' and 'use taint' shouldn't affect whether data is tainted--the rules for that should stay in effect. What they should alter instead is perl's response to tainted data while they're in effect. In a 'use taint' block perl should check, while in a 'no taint' block it shouldn't. Couldn't have said it better myself. And god knows I've tried. G It might be nice if the result of a calculation was never tainted when the calculation was in a 'no taint' block. That does make rather a lot of sense, though it's arguable whether it's a good idea if you don't know what you're doing. That's never been perl's problem, though... :) I think that 'no taint' should solicit a warning. (default warning set) It should warn sepperately if uid=0 or gid=0 when you 'no taint'. (default warning set) It should fail if you 'no taint' when uid=0 or gid=0 with 'use strict "taint"'. (in default strict set?) Hm, this behavor would be equivlent to making "unsafe" errors normal: 'no strict "taint"' == 'no taint' 'use strict "taint"' == 'use taint' 'use warnings "taint"' == 'use taint warnings' (You'd have to put the warnings/errors about 'no taint' in the 'notaint' set.) -=- James Mastros
Re: RFC 288 (v2) First-Class CGI Support
* Nathan Wiger ([EMAIL PROTECTED]) [28 Sep 2000 05:33]: Philip Newton wrote: Is order important for @HEADERS? Would it be better to have %HEADERS instead that does such auto-formatting? In my opinion, no, for the reasons given before. Hashes are unordered, and if you want to order the keys, you need to know the possibly keys and in which order they come. Then, if HTTP/4.2 comes out with the Toast: light|medium|dark header, which has to come after the new Breakfast: header Wait, you're both right! ;-) More or less, yeah =) Personally, I'd like to see a simple version of CGI::header be embedded in core. HTTP-type headers are widely used in many applications. So you could have: @HEADERS = header(content-type = 'text/html', toast = 'medium', # not too crispy breakfast = 'yes'); Under normal life, @HEADERS would just be some variable. But the "use cgi" pragma could simply flush @HEADERS out ahead of time before your [insert "STDOUT"] output stream. If @HEADERS is empty, the "use cgi" pragma just prints out "Content-type: text/html\n\n"; Personally speaking, I'd prefer a headers object. Just so that things could be extended more easily in the future (in case headers ever need to get slightly more complicated than a simple order array). (Plus it means things could be slightly more easily kept track of in the implementation: it's quite probable that you won't want duplicate keys in the array and this is best served by having a hash behind the scenes (possibly with an ordered array of keys) but you can probably see where I'm aiming at now? Extensibility.) [...] 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? I'd say RFC it separately. cheers, -- iain truskett, aka Koschei.http://eh.org/~koschei/ The book to read is not the one which thinks for you, but the one which makes you think. James McCosh
Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
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 [snip] I've yet to understand why I'd *want* to use English regularly; so far as I can tell, it has essentially no benefit in the long term. [snip] I know it's not the only stance to take, but I prefer to try to make my Perl code very readable by people who know Perl, and encourage people who don't know Perl who are trying to read my code to learn Perl first, or at the same time. [snip] use English doesn't really address the syntactical points of Perl that make it hard to read for someone who doesn't know Perl; it strikes me, and always has struck me, as a bad partial solution to a problem that may not need to be solved and that only makes things more complicated in the long run. 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. Using Randal's code: /foo/ print while ; Note that "use English" here does nothing to improve the horribly unreadable - yet beautifully succinct and flexible - syntax that is Perl. My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) -Nate
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. Z.
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Adam Turoff wrote: On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. It's a good thing we've got Larry Wall to untie the Gordian knot of perl6. One rfc to add more english, one to take it away. -- Robert Mathews Software Engineer Excite@Home
Re: Expunge use English from Perl?
My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. Yes, but perhaps a little bit of both. Truthfully, I've always seen long alternatives as useless bloat, not used widely over the long term. Once people learn the shortcuts, they use them. Expunging "use English" may will improve Perl syntax, since it's one less way to do things with already dubious value. Yes, the overlong variable names are a waste of time, IMO, because I've never seen them used in "real code". It's almost a rite of passage to take off the training wheels and use the "real names" of the variables. Who wants to write $INPUT_RECORD_SEPARATOR when you can write $/ ? I'm not vehemently opposed to "use English", or even the long alternatives to -r and -w that RFC 290 proposes. But I do think, truthfully: 1. They don't solve the real syntactic problems 2. Very few people will ever use them long-term So if they bloat the language, we should consider expunging them. They certainly bloat Camel with duplicate definitions. And I consider the mneumonic of $! much stronger than $ERRNO (or was that $OS_ERROR or $SYS_ERROR or ??) Personally, my stance is that we should all come to accept that we use and love a language with a syntax that drives many people mad. Not everyone's gonna like Perl, so I think we should just accept it and move on. -Nate
Re: Expunge use English from Perl?
On Wed, Sep 27, 2000 at 05:11:30PM -0700, Nathan Wiger wrote: Yes, but perhaps a little bit of both. Truthfully, I've always seen long alternatives as useless bloat, not used widely over the long term. Once people learn the shortcuts, they use them. Expunging "use English" may will improve Perl syntax, since it's one less way to do things with already dubious value. A lot of use English has to do with aliasing global variable linenoise, which is already going away. For instance, $/ is becoming per-handle, and $: (?) is probably going away because it has nasty action-at-a-distance properties, and FORTRAN programmers never use it to offset the zero-index to one. (Abigail uses it to make japhs that bizarrely store the number 17.) It has nothing to do with improving the syntax though, because everything in use English is a variable that serves as a reference to some other variable. I'm not vehemently opposed to "use English", or even the long alternatives to -r and -w that RFC 290 proposes. But I do think, truthfully: 1. They don't solve the real syntactic problems No, because the syntactic problems are -s(FH)/2, and that is solved by fsize(FH)/2 iff -s is replaced with fsize (or a better spelling thereof). 2. Very few people will ever use them long-term I dunno. I remember looking at some code that used '-x _' that had half a department befuddled. -rwx FH is better, and gets rid of the special case bare _ syntax. Z.
Re: RFC 226 (v2) Selective interpolation in single quotish context.
The story so far:
On September 13 Jarkko professed a desire for
"a quotish context that would be otherwise like q() but with some minimal extra
typing
I could mark a scalar or an array to be expanded as in qq()." [1]
Seeing this as being especially useful for those of us creating command files on VMS
using
here-docs, I volunteered to write the RFC, and proposed that variables be tagged to be
interpolated
in any single-quotish context.
A couple of forms of tagging were proposed. The initial RFC proposed doubling C$
and C@
(i.e. C$$scalar and C@@array). Damian Conway suggested C\I..\E [2] which has a
very Perlish
feel to it, but Greg Linderman pointed out that C\I..\E could easily occur in text
containing Win32
filespecs, and added
"There just really isn't a character that works inside ' for adding additional
interpolation semantics." [3]
All in all, the general sentiment is that single quotish context should not change.
As Nat so
succinctly put it:
I personally do not want to see q() screwed with. [4]
As another approach, Greg also suggested that perhaps C\D..\E in double quote
context could
*disable* interpolation, effectively turning C\D..\E delimited blocks of text into
single
quote context. [3] While passing Jarkko's "minimal extra typing" requirement, this
still
requires one to be aware of and modify naturally occurring C\Es in the tagged text,
as Greg
points out. In addition, to me this seems to be a little bassackwards, no disrespect
intended. [5]
Nat Torkington and M-J Dominus suggested overloading strings operations [6] and the
use of a block
scoped pragma to change single quotish semantics [7], respectively. Jarkko also
suggested a pragma
"...to *really* tag variables lexically to be expanded within singlequotes. Or
for that matter,
*not* to be expanded within doublequotes." [8]
My own preference (and the one I should have suggested at the onset instead of trying
to wedge this
thing into q() context) is for another quote context, one which would be otherwise
like q() but with
some minimal extra typing... This has been suggested by more than one, although
sometimes with some
reluctance. But I believe it fits the bill and doesn't step on any current quote
context toes.
Let's call it qt(), for quote tagged. That and the means of tagging is open for
discussion, but at
least now we know some pitfalls. Working from previous suggestions:
$scalar # [6] Nat
$$scalar # [1] Jarkko
\I$scalar\E # [2] Damian
TeXies may prefer \I{$scalar}, and the hybrid \I$scalar doesn't seem bad. I don't
particularly care
and it may be that there's this perfectly obvious solution that only Larry can see and
we really shouldn't
dicker around too much on this point.
However, this doesn't address here-docs. q(..) and qq(..) are not the same as '..'
and ".." when it
comes to here-docs.
print 'END'; print q(END);
abcabc
ENDEND
The second results in CCan't find string terminator "q" anywhere before EOF at - line
1.. I'm not
overly surprised given the special nature of here-docs, but I see nothing wrong with
allowing
print q(END) to mean print 'END' , and
print qq(END) to mean print "END"
. And once the foot's in the door,
print qt(END)
follows.
Time is getting short so I don't really expect any resolution before Oct. 1, although
if this seems at least
reasonably acceptable I can get another RFC out on the q(END) == 'END' proposal
pretty quickly.
Brad
[1] http://www.mail-archive.com/perl6-language@perl.org/msg03888.html
[2] http://www.mail-archive.com/perl6-language@perl.org/msg03970.html
[3] http://www.mail-archive.com/perl6-language@perl.org/msg03983.html
[4] http://www.mail-archive.com/perl6-language@perl.org/msg04018.html
[5] The perl6 lists had started to become as annoyingly uncivil as p5p
has been. I only just decided to come back and see this through.
[6] http://www.mail-archive.com/perl6-language@perl.org/msg03982.html
[7] http://www.mail-archive.com/perl6-language@perl.org/msg03965.html
[8] http://www.mail-archive.com/perl6-language@perl.org/msg03962.html
Re: RFC 288 (v2) First-Class CGI Support
At 07:09 PM 9/27/00 -0400, James Mastros wrote: From: "Dan Sugalski" [EMAIL PROTECTED] To: "Nathan Wiger" [EMAIL PROTECTED] Sent: Wednesday, September 27, 2000 4:08 PM 'no taint' and 'use taint' shouldn't affect whether data is tainted--the rules for that should stay in effect. What they should alter instead is perl's response to tainted data while they're in effect. In a 'use taint' block perl should check, while in a 'no taint' block it shouldn't. Couldn't have said it better myself. And god knows I've tried. G It might be nice if the result of a calculation was never tainted when the calculation was in a 'no taint' block. Yerk. No, that's bad. The data is still tainted--the fact that it flowed through a "no taint" block doesn't make it any more trustworthy. Tainting really can't be dealt with like that. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Expunge use English from Perl?
Adam Turoff wrote: It has nothing to do with improving the syntax though, because everything in use English is a variable that serves as a reference to some other variable. Yes, and that's why I really think it's a waste of time. ;-) I'm not vehemently opposed to "use English"... But I do think, 1. They don't solve the real syntactic problems No, because the syntactic problems are -s(FH)/2, and that is solved by fsize(FH)/2 iff -s is replaced with fsize (or a better spelling thereof). This is one thing that I'm scared most of, and that is having two alternatives which work only in certain contexts. I'm sure p5p has already extensively looked at -s(FH)/2 being "wickedly broken" (as I believe Tom put it), but the solution should theoretically be to make -s(FH)/2 work. The consensus has already pretty much said that they want -s et all to stick around. So if RFC 290's idea is still to replace -X, then I'm very much against it. But I was under the impression that they're just "use english" alternatives. If, however, these alternatives fix bugs that -X can't handle, then that's not good. I'll dig through the p5p archives and toke.c to see if any wisdom is magically imparted on me. ;-) 2. Very few people will ever use them long-term I dunno. I remember looking at some code that used '-x _' that had half a department befuddled. -rwx FH is better, and gets rid of the special case bare _ syntax. Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. -Nate
Re: RFC 288 (v2) First-Class CGI Support
Dan Sugalski wrote:
It might be nice if the result of a calculation was never tainted when the
calculation was in a 'no taint' block.
Yerk. No, that's bad. The data is still tainted--the fact that it flowed
through a "no taint" block doesn't make it any more trustworthy. Tainting
really can't be dealt with like that.
Phew! I was hoping you'd say that, Dan! ;-)
If we're just turning on and off taint *checking*, it might be worth
noting that in whatever pragma name we choose:
#!perl -T
{
no taintchecks;
}
Just want to plant the seed early. I can see "no taint" or "no tainting"
being *really* confusing (unless it was "no taint 'checks'" or
something).
-Nate
Re: RFC 288 (v2) First-Class CGI Support
At 07:53 PM 9/27/00 -0700, Nathan Wiger wrote:
Dan Sugalski wrote:
It might be nice if the result of a calculation was never tainted when the
calculation was in a 'no taint' block.
Yerk. No, that's bad. The data is still tainted--the fact that it flowed
through a "no taint" block doesn't make it any more trustworthy. Tainting
really can't be dealt with like that.
Phew! I was hoping you'd say that, Dan! ;-)
If we're just turning on and off taint *checking*, it might be worth
noting that in whatever pragma name we choose:
#!perl -T
{
no taintchecks;
}
Just want to plant the seed early.
This is a good idea. It's sufficiently important a distinction that the
longer pragma name's worth it--the fact that someone needs to type the
whole thing out to turn it off would make people less likely to do so...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 288 (v2) First-Class CGI Support
Robert Mathews wrote:
Parse the CGI GET/POST request, returning CGI variables into %CGI
(regardless of the source) in an un-HTTP escaped fashion
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q-param("foo");
Are you going to make the values of %CGI listrefs? That should have
been spelled out before you froze the RFC. Also, it seems a bit
inconvenient if you always have to say C$CGI{bar}[0] when you just
want one value.
Two choices as I see it:
1. make a listref only for multiple values:
@name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );
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.
But I don't think listrefs are needed in all contexts, since you should
know which elements will likely have multiple values (checkboxes, etc).
But having a direct data access method like %CGI does create this
problem. Shit.
Maybe %CGI is tied. Fast embedded tie, like in Perl 6. :-)
-Nate
Re: RFC 288 (v2) First-Class CGI Support
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? 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. I think this one belongs in perl6-stdlib, certainly not in the perl6-core! I've lost my RFC draft, but it's title was: No JAWS -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.005.03, 5.6.0, 5.7.1 516 on HP-UX 10.20 11.00, AIX 4.2 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
