Re: apo 2
On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: And btw . . . Wouldn't $thing has property make more sense than $thing is property $foo has true doesn't flow as well as $foo is true. Dunno quite what the other expected uses are. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Stupid am I? Stupid like a fox!
Re: sandboxing
On Fri, May 04, 2001 at 09:03:05AM -0500, Jarkko Hietaniemi wrote: Memory limits we should be able to do, assuming Perl 6 continues to have its own malloc. Well... Perl doesn't use it's own malloc *that* widely. Who knows what Perl 6 will do internally, but we'll probably have some sort of malloc wrapper at least. Anyhow, if you need to set a certain flag when compiling perl6 to allow certain sandbox features (I can see certain checks necessary being in very hot parts of the code) that should be ok. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: Apoc2 - STDIN concerns
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote: I'm wondering what this will do? $thingy = $STDIN; This seems to have two possibilities: 1. Make a copy of $STDIN 2. Read a line from $STDIN While perhaps inconsistent, I'd really rather it did #2. Here's the basic argument... compare how often you dup a filehandle with how often you read from one. Duping is swamped by several orders of magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line = $STDIN.next should still work normally. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Do you have a map? Because I keep getting lost in your armpits.
Re: Apoc2 - STDIN concerns
On Fri, May 04, 2001 at 07:02:14PM -0700, Nathan Wiger wrote:
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still work normally.
You know, I hear what you're saying, but it really makes the little hairs on
my neck stand up. Just imaging trying to teach this:
$a = $b;# assignment or readline?
Well, overloading and tying can already do things like this, but
that's a weak argument at best.
I dunno, I think its natural enough that it won't seem jaring. And
after the nth time of having to type while($line = $file.next) {
you'll be wishing for it. Maybe other people use $_ more than I do.
I rarely use it.
Of course, if overloading is implemented well, as I expect it to be,
there's no reason you couldn't just have a special filehandle class
that redefines the copy constructor.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
List context isn't dangerous. Misquoting Gibson is dangerous.
Re: .NET
On Wed, May 02, 2001 at 04:26:27PM -0500, Jarkko Hietaniemi wrote: You are saying that the Clippy wasn't originally and truly annoying? :-) Annoying enough to spawn vigor! http://www.red-bean.com/~joelh/vigor/ -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Q. What are seven candles, seven cows, and seven heads of the beast which rises from the sea? A: Metaphors. They are all symbolic. Which means, they are not real things. --Alex Chiu, Immortality Guy
Re: Please make last work in grep
On Wed, May 02, 2001 at 11:13:13AM +0200, Alexander Farber (EED) wrote:
I would like to propose adding the last statement
to the grep, which currently doesn't work:
For the record, I have no problem with this. :)
maas34: perl -e 'grep { print and $_ == 3 and last } (1,2,3,4,5)'
123
Can't last outside a loop block at -e line 1.
This way it would be possible to use such constructs:
FYI, its not hard to write a routine to do just that...
first { some_condition } @stuff;
sub first (@) {
my($cond, @stuff) = @_;
my $first;
foreach (@stuff) {
if( $cond ) {
$first = $_;
last;
}
}
return $first;
}
print first { $_ 5 } 1..10;
6
And I'm quite sure there's an RFC for doing something like this alread
up for Perl 6.
Here I am looking for a button with a special name - Delete ... -
and there can be only one such button, so I have to interrupt the
grep after I find it (otherwise the $1, $2, $3, $4 might be unset).
(grep {...} @stuff)[0] will work, but its inelegant.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Maybe they hooked you up with one of those ass-making magazines.
-- brian d. foy as misheard by Michael G Schwern
Re: Please make last work in grep
On Wed, May 02, 2001 at 06:05:54PM +0200, H. Merijn Brand wrote: IIRC, that optimization is not even considered for reasons of many people wanting the side effects of grep/map finishing over all elements (which could of course be from a tied array or database connection) If we could determine if the block has no side effects... oh wait, everything in Perl has a side effect. ;) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I was *meant* to mount your donuts.
Re: Flexible parsing (was Tying Overloading)
On Sat, Apr 28, 2001 at 02:44:17PM -0400, Dan Sugalski wrote: Well, I was thinking that generally the site policy would be expressed in a single file This smells strangely familiar. Alot like the .perlrc discussion that was had back many moons ago. The havoc a general syntax-altering policy file could wreck would be enourmous. To use a Perl 5 example, consider the simple setting of use strict as a general site policy. Basicaly, most of the Perl code in your /usr/bin will explode when you try to run it. Unfortunately, the perl6-language archive doesn't seem to go back far enough to cover the .perlrc discussion. Is the old archive still around? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One But in the year 2006, the entire world shall be united. Then the God followers will live happily ever after on earth. --Alex Chiu, Immortality Guy
Re: a modest proposal Re: s/./~/g
On Sat, Apr 28, 2001 at 10:39:01AM -0700, Larry Wall wrote: Now we just need to make ... ___ ... mean something exceptional. ___ ... ___ is valid. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #437: crop circles in the corn shell
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 11:44:24AM -0400, Dan Sugalski wrote: At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote: To use a Perl 5 example, consider the simple setting of use strict as a general site policy. Basicaly, most of the Perl code in your /usr/bin will explode when you try to run it. Right, that's why the policy stuff we're discussing is optional... :) Ugg, we're definately rehashing the .perlrc discussion now. :( By optional I take it you mean an admin can choose to define their own site policy or not? I see this as causing more trouble than its worth. Consider the following post Perl6 laments... Oh damn, this won't work under insert naughty OS here because they ship with a messed up policy file! There's no real good solution to this one anymore than there's a good solution to people shipping with dead perls. Grrr, I can't run insert program here because the admin has an odd Perl policy setup This one could be dodged by having $HOME/.perl_policy (oops, I almost typed '.perlrc' :) files which override the site-wide policy. But the idea of programs running differently depending on which user you are makes my brain hurt. It also waters down one of the intents of a site policy which is to keep users from doing naughty/silly things. Of course, the site policy could deny being overriden by the user policy... but then that brings us right back to square one. In general, easy, customizable configurations are for applications, not languages. Go with 'use Policy::...' on each script. A site-wide policy is easily gotten by simply defining /usr/bin/perl as a shell alias: #!/bin/sh /usr/bin/realperl -MPolicy::Company $@ Or something like that. Before anyone brings up but that fork will slow things down! consider the startup search for site policy files that will have to occur when *every* perl program runs if you go that route (then again, we already do that with Config.pm and other libraries). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 12:49:28PM -0400, Dan Sugalski wrote: At 05:37 PM 4/29/2001 +0100, Michael G Schwern wrote: By optional I take it you mean an admin can choose to define their own site policy or not? No. Optional in that you have to do a use SomePolicyThingWeHaventDecided; to put it in force. Ahh, ok. Carry on then. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One OH GOD!! It's LINUX! All you Linux fanboys go wild! It never crashes! It'll wash your underpants! It'll eat your dog for you, if you want your dog to be eaten! It'll make you attractive and smell good and... it'll... uh... uh. Man, I'm so sick of this shit. http://www.goats.com/archive/000602.html
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 12:20:42PM -0700, Ask Bjoern Hansen wrote: don't know which archive you are talking about, but http://archive.develooper.com/perl6-language%40perl.org/ should have all mails sent to perl6-language from it's start to a few days ago when I moved stuff around. I think I need to get my eyes/head examined. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One i gave them some paste do that funky dance, white boy i laughed my ass off -- Fmh
Re: C or SH like string cat proposal
On Wed, Apr 25, 2001 at 12:10:10AM -0500, David L. Nicol wrote: That means, if you have a long list of scalars rou want to cat together and it will run over the edge of your line you can do this: $onethroughten = $one$two$three$four$five $six$seven$eight$nine$ten; I think the proper phrase here is ick. To my non-C, non-Shell programming eyes, that's just a confused jumble. It'll also play hell with trying to mix strings in there. I could live my entire life without seeing: $foo = $one$two'three'$fourfive$six Will someone please explain to me the indirect object syntax which this allegedly steps on? (The hellish abomination of ;) indirect object syntax works like this: $obj = new Some::Module @args; to mean $obj = Some::Module-new(@args); Any proposal which tries to use whitespace as a concatination operator runs into its territory, but I don't think yours would cause problems (except for the rash of patients admitted to local hospitals with bleeding eyes). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Let me check my notes...
Re: Dot can DWIM without whitespace
On Wed, Apr 25, 2001 at 08:33:33AM -0400, Stephen P. Potter wrote: How about symbolic refs to function names? $a = $x ? hop : skip; $b = $y ? scotch : soda; $a.$b;# call one of hop.scotch, skip.scotch, hop.soda, skip.soda 5.005_03 and under required parens after the method reference $obj-$meth_name(); 5.6.0 appears to have removed that requirement, but I don't see why that couldn't be required again in Perl 6 to disambiguate if needed. | Alternately, we can overload . to do a deref on (blessed?) references, and | concat otherwise. I think this would lead to hard to find bugs when someone mispelled something. I think it would also throw Dan into convusive fits. Additionally, it would make finding method calls lexically near impossible. I'd like to keep Perl 6 refactorable as much as possible. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #356: the daemons! the daemons! the terrible daemons!
Re: Dot can DWIM without whitespace
On Wed, Apr 25, 2001 at 07:23:47PM -0700, Edward Peschko wrote: On Thu, Apr 26, 2001 at 03:16:46AM +0100, Simon Cozens wrote: SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet? Just for the record, I'm totally with Simon here. Having . do triple duty (decimals, method calls and string concat) will be hard enough to teach. Throw obscure whitespace rules in there and you'll spend all day trying to explain it. The problem already comes up... '4. 5' is not the same as '4.5'. '.' is *already* doing double duty as decimal mark. The fact that you don't see this very often shows exactly how rare the mistake arises. Most people, by around first grade, understand that 4.5 is a number. 4. 5 is (thank goodness) a syntax error, so any confusion is resolved immediately. '4 .5' for some reason is not, but as Casey pointed out that's probably a parsing hiccup. Additionally, its pretty damn rare for anyone to want to concatenate two bare numbers. I think the 'tutorial' will come from experience. When the error that you get from $a.$b comes up (and it should be a syntax error) you'll see exactly what is wrong. If $a. $b, again, syntax error. Only $a . $b should be allowed. The only point of contention would be if someone said $a . b, when they meant $a.b. And how often will that occur? Very often, because I'd expect $a.$b to work and be very surprised when it fails! Very little else in Perl is white-space sensitive without very good, fairly obvious reasons (as with decimal numbers above), let's avoid it here. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One They just don't make any good porn music anymore, do they? - WXDX DJ refering to More, More, More
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 12:32:29PM -0400, John L. Allen wrote: I think someone may have mentioned this already, but why not just say that if you want '.' to mean concatenation, you have to surround it on either side with white space? If there's no white space around it, then it is forced to mean method invokation, or whatever else. This approaches whitespace as syntax. Very few Perl operators care about whitespace between their words (even -) or whitespace at all. More generally, its going to cause alot of careful squinting at code to distinguish between different operators. This will lead to subtle bugs because someone accidentally put a space after the . and didn't notice. Its just cutting it too thin. Don't go this route unless others are exhausted first. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #100: IRQ dropout
Re: Sane + string concat proposal
Seems servicable. Doesn't exactly make me jump up and down, though. A few nits... On Tue, Apr 24, 2001 at 11:42:00AM -0700, Nathan Wiger wrote: More Details Ok, if you're still reading, cool. Let's get down to the nitty-gritty. Here are some more examples of code: Perl 5Perl 6 - print Next is . $i + 1;print Next is + $i + 1; Two problems. First, the Perl 5 example is equivalent to: print +(Next is . $i) + 1; and I don't think that's what you ment. I think you ment... print Next is . ($i + 1); Which brings up a problem. '$foo + $number' is numeric addition. So shouldn't 'Next is + ($i + 1)' be numeric as well since one of the sides is unquoted? Probably not what you wanted. This problem will happen with any complex expression which you can't easily put quotes around. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One If you are only one year old, and this is the first time you have ever seen a burger, your related neurons will gather into a new hamburger group. But I bet you are not that young and already know what a burger is. --Alex Chiu, Immortality Guy
Re: Sane + string concat proposal
On Tue, Apr 24, 2001 at 11:53:49AM -0700, Mark Koopman wrote: Perl 5Perl 6 - print Next is . $i + 1;print Next is + $i + 1; this is the root of the problemPerl 5 version is easy to understand, Perl 6 version is still ambiguous The Perl 5 version is also ambiguous as you didn't catch the precidence problem I noted eariler. ;) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One ...and that, children, is how to clean and load a .38 revolver. Questions?
Re: Sane + string concat proposal
On Tue, Apr 24, 2001 at 12:23:24PM -0700, Austin Hastings wrote: Some of the objections have gone by, but what if you reverse the quotes? Make operator-in-quotes be a string operator (hell, make that true for the other ops, too) Perl 5 Perl 6 --- --- - . + + . + eq = or eq gt or gt If we go this route, we may as well just use 'cc'. Much less typing (no chording), less confusing, analagous to 'eq' and 'gt'. Perl 5Perl 6 - $res = $var + $var2; $res = $var + $var2; $name = This . that; $name = This + that; $name = This . $that; $name = This + $that; print Next is . $i + 1;print Next is + $i + 1; $me = $name . getpwuid($); $me = $name + getpwuid($); All those quotes make my eyes bleed. Oh, not to seed the clouds or anything, but what about += and .=? Any proposal will have to deal with those. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Do you have a map? Because I keep getting lost in your armpits.
Re: Strings vs Numbers (Re: Tying Overloading)
On Tue, Apr 24, 2001 at 12:23:33PM -0700, Edward Peschko wrote: ok, well.. I've heard arguments for '+' (namely that its intuitive, other language compatible, etc...) so what are the arguments against it? This one seems to have slipped by... http://archive.develooper.com/perl6-language%40perl.org/msg06550.html Basically talking about the problems of trying to use the same operator for strings and concat in a typeless language. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Beer still cheaper than crack!
Re: how about just juxtaposing? (Re: Sane + string concat proposal)
On Tue, Apr 24, 2001 at 02:32:39PM -0500, Jarkko Hietaniemi wrote:
Has the road of just putting things next to each other been extensively
tried? It works for Awk... juxtapose, the Famous Invisible Perl
Operator.
Perl 5 Perl 6
$a = $b . $c; $a = $b $c; # or $b$c
$a = foo.$c; $a = foo $c; # or foo$c
$a = foo . $c; $a = foo$c; # foo $c wouldn't work...
$a = $c . foo; $a = ${c}foo# (if foo is a function)
$a = foo() . $c;$a = foo() $c;
$a = $c . foo();$a = $c foo();
$a = $b-c . $d;$a = $b-c $d; # or $b-c$d;
This is going to make finding syntax errors a bit difficult, as many
will simply become concatination operators. Consider
print Foo
foo(bar);
Did the author forget a semi-colon, or did they intend to concatinate
there? Also, consider this...
print foo bar;
Is that 'print foo(bar);' or 'print foo().bar;' in Perl 5?
I can see that the indirect objects can be painful
That's ok, just kill indirect objects. Ooop, I'll be leaving before
Nathan finishes loading his gun. ;)
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
purl Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
YA string concat proposal
Ok, time for me to shot down.
I've already voiced my views about trying to make addition and
concatination into a single operator in a typeless language
http://archive.develooper.com/perl6-language%40perl.org/msg06550.html
and I think its a losing proposition.
So here's something simple. Sort of a fallback proposal in case
nothing amazingly clever comes up.
cc and ce
Perl 5 Perl 6
print foo . bar;print foo cc bar;
print 2 . 4;print 2 cc 4;
print foo . ($i + 1);print foo cc ($i + 1);
$foo .= bar ; $foo ce bar;
Its unambiguous and its analgous to eq, ne, gt, get, etc... About the
only problem I can think of is if you define a function called cc() or
ce(), but we live with that already with gt() and friends.
It also has the nice side-effect of preserving '.=' functionality,
which I'd rather not lose (especially after having made fun of
$foo = $foo . 'bar'; type code).
PS It doesn't have to specifically be cc and ce. Just so long as it
matches /^[a-z]{2}$/ and /^[a-z]e$/
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
I'm going to have to hurt you on principle.
Re: YA string concat proposal
On Tue, Apr 24, 2001 at 01:05:24PM -0700, Nathan Wiger wrote: While we're brainstorming a wish-list, here's something I've always wanted, a replacement for: $a = $b . $a; I don't think there's any pressing need for this unless you can show a common case where a prepend op would make things significantly easier. (Postpend (is that a word?) doesn't make things particularly easier either, but people will expect it and its a bit more common case.) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Free beer w/riot!
Re: Larry's Apocalypse 1
On Mon, Apr 16, 2001 at 09:58:05AM -0500, Brian Wheeler wrote: Name tricks are ugly, but useful. Perhaps the best solution would be to call the new interpreter perl6. If it finds itself being called 'perl' or 'perl5' then it should assume perl 5 code I just worry about users not being aware of this. As I mentioned eariler, it was very common on systems that had perl4 as /usr/bin/perl and perl5 as /usr/bin/perl5. People would get these strange errors from perl and either not think to look at the version and/or not think that perl5 might be installed under another name. It was quite common. It is a servicable solution, just be ready for the extra problems. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One ...and that, children, is how to clean and load a .38 revolver. Questions?
Re: Larry's Apocalypse 1
Dan Sugalski [EMAIL PROTECTED] writes: Why? We don't ask this of any other compiler, so why ask it of perl? (You won't find this in a C, or Fortran, or Ada compiler...) Yes, but my compiled C binaries in /usr/bin don't break when I upgrade gcc. A binary is largely independent of its compiler once it is compiled and installed, interpreted programs do not have this luxury. Think of it this way... what would happen if Borne Shell suddenly decided it was going to introduce fundemental incompatibilities? (I'm sure they already have...) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Teleportation must be invented. If we don't invent teleportation, China will throw nuclear bomb everywhere. Especially now everyone can live forever. --Alex Chiu, Immortality Guy
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 05:15:56PM -0400, Ted Ashton wrote: 2) If the executable called ends in 6. ETOOMAGICAL. Shades of zip/unzip here. On some systems zip and unzip are just hard links to the same binary. It figures out what it supposed to do by what name is called. Very magical. Very bad. That way, "the #! thing" would suffice for normal code and one could just perl6 -e 'whatever;' for one-liners. One-liners run on a Perl 6 binary should just be Perl 6 code. Do we really have to worry about backwards compatibility with one liners? Hmm... programs that have perl one-liners inside them might be troublesome. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One What makes an animal escape from danger? When a small fish sense a big fish coming, it escapes. Who taught them to run for their lives? No one. The negative and positive charges made them advance and retreat automatically. --Alex Chiu, Immortality Guy
Re: Auto-install (was autoloaded...)
On Thu, Feb 08, 2001 at 01:40:52PM -0500, Dan Sugalski wrote: Seperated documentation is no documentation. At some point things are going to get split out, unless you wedge the docs into the actual program itself. (You were, after all, talking about config files and XS modules, and those can't usefully stay inside the archive) True, but those things are essential to making the program work, and their loss will be dearly (and immediately) noted. Documentation is the first thing to get ditched in any install process. I was mostly thinking perldoc (yes, wedging the docs into the program) *plus* the normal man page generation and install. That's how I normally do things. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Only mindless violence can raise my spirits now!
Re: Auto-install (was autoloaded...)
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote: Other important issue I don't know yet: Is there an Archive::Zip module for Perl? How cross-platform is it? Can we bundle it with Perl (licensing issues)? Is it stable? Will it give us the support we need (access to individual files in the archive, and the ability to `fake' them as real files through tied filehandles)? I'm a bit more worried about Compress::Zlib, which Archive::Zip uses. There are versions of that for pretty much every OS, including MacOS, but its historically been a bit weird. I remember there being a Very Deep XS Bug that we couldn't quite dig out a while ago. Or maybe it was in Archive::Tar... one of the two. Anyhow, I'm not worried about them much. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Any sufficiently encapsulated hack is no longer a hack.
Re: Auto-install (was autoloaded...)
On Thu, Feb 08, 2001 at 08:53:07AM -, Filipe Brandenburger wrote: Branden wrote: When I download a module from Internet, say module Foo, then I install it and try to use it, it promptly breaks when it tries to `use Bar' and sees that Bar is not installed on my system. So I have to go on to Internet again, find Bar, install it, so on, until I find Bar needs Baz, or anything like it. Well, I think this could be handled by Perl itself. Oddly enough, Perl does handle this... mostly. The CPAN shell can automatically download and install prerequisites for modules, provided the module explicitly declares the prereqs. Class::DBI ultimately needs something like 9 other CPAN modules, which would be a nightmare but for this feature. perl -MCPAN -e 'install Class::DBI' Its only on the more recent versions of the CPAN shell (1.48), but since the shell whines about updating itself everytime you use it, there's no reason not to have the latest. I've taken advantage of this for local projects using the CPAN::Site module and setting up a local repository for local code. Now, the idea of perl automagically going out and downloading untrusted code (all the code on CPAN is untrusted) from untrusted sources (ergo, CPAN is untrusted) from untrusted scripts (if its a core feature, any script can do it) makes my feet itch. We can't do this until there's a way to security audit CPAN... which is supposed to be my job. :( However, if you *really* want to do it, you can pretty easily. Just code up a function which tries to use the given module, otherwise it fires up the CPAN shell and install it, then tries to use it again. I've been meaning to do this for a while now. Another problem is the fact that not everything on CPAN installs easily. Most does, but some require certain interaction and configuration (LWP, Net::FTP, most any DBD driver...). Those can't be done automagically, but if we could do 80% then that's ok. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ If you have to shoot, shoot! Don't talk. -- Tuco, "The Good, The Bad And The Ugly"
Re: Auto-install (was autoloaded...)
On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote: The issue is actually not auto-downloading modules and their prerequisites, but actually packaging several scripts and modules in one file, so as Java's jar do. I think supporting this would be neat. I thought about making a "par" utility. It would basically do this: # for each module needed... perl Makefile.PL PREFIX=foo LIB=foo/lib make test make install Then you just stick your program into foo/bin or something and tar it all up and ship it off. The "pun" utility (I couldn't resist) then untars the thing and runs "perl -Ifoo/lib foo/bin/whatever.plx". Any obvious flaws? Poke me enough and I'll get around to doing it. As to the question of security, if you download a script on a site that says it does XYZ and you actually trust the script does XYZ (trust in the sense that you *believe* it), I don't see why wouldn't you trust that the script would load modules that aren't harmful, either from CPAN or from another place. Download Memoize from CPAN sometime and install it. Make sure you're sitting down. All it takes is one joker, or one person to have a bad day, or get a little too drunk one night near a computer. We *can* automate security auditing of CPAN. I know it can be done because I've seen it done on smaller scales and it will happen. If you missed it, look at the CPANTS synopsis http:[EMAIL PROTECTED]/msg00148.html Its vapor yet, but its all within the realm of "solved problems". -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ BOFH excuse #301: appears to be a Slow/Narrow SCSI-0 Interface problem
Re: Auto-install (was autoloaded...)
On Thu, Feb 08, 2001 at 11:21:17AM -0500, Dan Sugalski wrote: I'm not sure this is all necessary. Wouldn't we be reasonably better off if we instead just shipped off bytecode compiled versions of the scripts? Sure, except... 1) You lose your readable source code (discussions of B::Deparse as a viable alternative /dev/null) 2) You have to make provisions to distribute your documentation seperately. 3) It makes it harder to bundle non-Perl things, like configuration files, images, sound files, etc... If you want to send those along with the bytecode you windup needing a par-style utility anyway. 4) What Brenden said 5) Do YOU have a stable bytecode compiler?? I don't. Perhaps it wasn't clear, I don't mean to have par as part of 6.0, I mean to have it out, like, maybe next month if I decide to work on it. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Kids - don't try this at--oh, hell, go ahead, give it a whirl...
Re: Auto-install (was autoloaded...)
On Thu, Feb 08, 2001 at 05:39:01PM +, Nicholas Clark wrote: Do we really want to use tar format (over say cpio) as tar rounds files up to 512 block boundaries, and has some arbitrary restrictions on filename lengths in the headers? First cut will be tar. Why? Its simple, its common, and we have a well-developed Perl module for it. Later it can be changed to anything we want. Encapsulation++ -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: Really auto autoloaded modules
On Fri, Feb 02, 2001 at 11:56:50AM -0600, Garrett Goebel wrote:
Michael Schwern's AnyLoader is a bit strange though. To use an explicitly
qualified function if the only perceivable gain were to allow you to skip
needing an 'use'. After all, if the purpose is to mangle your namespace...
why are you explicitly calling a function in the first place? But that
isn't the main reason for AnyLoader is it?
The main use of AnyLoader was to automate the lazy loading of modules
on demand without the problems of autouse.pm.
$ perl -wle 'use autouse "Carp" = qw(carp croak); carp("foo")'
Subroutine carp redefined at /usr/lib/perl5/5.6/autouse.pm line 57.
foo at -e line 1
$ perl -wle 'use AnyLoader; Carp::carp("foo")'
foo at -e line 1
The main use is for branches of code which are rarely executed, yet
required pulling in heavy modules. Carp, for example (before it went
on a diet in 5.6.0).
if( $some_error ) {
require Carp;
Carp::croak("A!");
}
I got tired of writing "require Carp" all over my code.
Anyhow, the fully-qualified function name requirement can easily be
removed. All I have to do is check to see if the namespace of the
called function matches the namespace of the caller. That indicates
an unqualified, undefined function call (though doesn't guarantee it,
but this IS a prototype). Then AnyLoader looks in a (as yet
undetermined) function registry (a glorified hash), loads the
appropriate module and exports the appropriate function.
PS Actually, it REALLY exists because Arnar came up with a neat trick
and I ran with it.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
The eye opening delightful morning taste of expired cheese bits in sour milk!
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 04:44:00PM -0600, Jarkko Hietaniemi wrote: Or explore various garbage collection alternatives. No good, the mob wouldn't be happy. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ purl Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!
Re: Really auto autoloaded modules
On Thu, Feb 01, 2001 at 10:14:20AM -0500, Dan Sugalski wrote:
One of the features of perl 6 is going to be the ability to automatically
use a module if one or more preregistered functions are used in your
source.
Would someone care to take a shot at formalizing the system? We need a way
to register these functions, track the module version (if any) they're in,
and stuff like that. (Including, I'm sure, things I've forgotten)
Have a look at AnyLoader in CPAN.
NAME
AnyLoader - Automagically loads modules for fully
qualified functions
SYNOPSIS
use AnyLoader;
Carp::croak("This is going to hurt the Perl community more than it ".
"is going to hurt you!");
Its not quite what you're talking about (yet) but we can extend it to
flesh out the idea of automagical autoloading.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Communism is the antichrist, which promised to bring peace and equality to
mankind, only to be disproved by the work of time.
--Alex Chiu, Immortality Guy
Re: Really auto autoloaded modules
On Thu, Feb 01, 2001 at 02:04:41PM -0500, Ken Fox wrote: Dan Sugalski wrote: Looks pretty close to what's needed. Care to flesh it out (and streamline it where needed) to a PDD? Isn't the trick to detect the necessary modules at compile time? Yeah, but at least with AnyLoader as a prototype we can flesh out the semantics and details of how it should work and what should be registered and how the registry works, etc... Maybe the EXPORT list should be registered without module names and the EXPORT_OK list with module names? Maybe I can do something with UNIVERSAL::exports. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Summer sun beats down I sigh and wait for winter warm paste enemas. -- mjd
Re: Why shouldn't sleep(0.5) DWIM?
On Tue, Jan 30, 2001 at 09:43:37AM -0600, Jarkko Hietaniemi wrote:
I guess it's part of the can of sub-second worms: if we do sleep(),
people will ask why don't we do time() and alarm(), too. sleep() and
alarm() we could get away with more easily, but changing time() to do
subsecond granularity would be A Bad Thing for backward compatibility.
Sorry, I forgot to mention the translations. Yes, it becomes:
sleep(EXPR) - sleep(int(EXPR))
alarm(EXPR) - alarm(int(EXPR))
time- int(time)
and that should handle it. The nice part is it doesn't really require
any code translations, you can get away with overriding the core
functions instead:
sub sleep { CORE::sleep(int($_[0])); }
sub alarm { CORE::alarm(int($_[0])); }
sub time { int CORE::time }
something like that. hand-wave
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
That which stirs me, stirs everything.
-- Squonk Opera, "Spoon"
Re: Why shouldn't sleep(0.5) DWIM?
On Tue, Jan 30, 2001 at 10:49:56AM -0500, Dan Sugalski wrote: Also there isn't a portable way to do subsecond sleeps. Not that it's stopped perl before, but on some of the platforms that perl 5 runs on there isn't *any* way to do it. Then how does select(undef, undef, undef, 0.25) work on those? Or doesn't it? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Any sufficiently encapsulated hack is no longer a hack.
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, Jan 31, 2001 at 05:23:43PM -0500, Dan Sugalski wrote: Pulling out or mangling time strikes me as intensely pointless, and I don't see it happening. The socket stuff is really the only core functionality that makes any sense to pull out, and that only from an architectural standpoint. Perhaps some of the more grossly UNIX specific things like getpwnam's extended family and the SysV IPC stuff? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ MERV GRIFFIN!
Why shouldn't sleep(0.5) DWIM?
Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
sleep($time);
}
else {
select(undef, undef, undef, $time);
}
}
Why can't Perl? Smells like a C holdover to me.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
If you have to shoot, shoot! Don't talk.
-- Tuco, "The Good, The Bad And The Ugly"
We're overcaffinated!
I didn't post up jwz's grumblings to kick off Yet Another Java vs Perl Argument. Nor did I post it to point out that he's a curmudgeonly young fart (which he is, but that's not a Bad Thing). Its there because he made alot of good points which apply to Perl. Keep the discussion focused there, on Perl and how we're going to improve it. Not on jwz or Java, they're incidental. Should we put bignums in the core? Is it worth the hassle to do Everything-An-Object? Macros? Can we declare it a Design Decision that scalars are going to be big (to a system programmer's shrunken eye)? etc... -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ And it's made from all-natural baby skin, so you know it's good for the environment. http://www.goats.com/archive/000606.html
Re: RFC195: Do not remove 'chop' PLEASE!
On Mon, Jan 29, 2001 at 10:39:42AM -0500, John Porter wrote: Yes; but the question isn't really "why", it's "how". Apparently chop() is specialized internally to detect the hashness of its argument, in a way that can't be expressed by a prototype. That's what I thought, but no. The hash effect is pervasive and chop() now has a simple prototype of @ in 5.7.0. (where before it was undefined) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in [EMAIL PROTECTED]
Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 04:28:08PM +0100, [EMAIL PROTECTED] wrote: Aliasing again. They keys are copies, the values aliases. How bizarre? Why does it work that way? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ "None of our men are "experts."... because no one ever considers himself expert if he really knows his job." -- From Henry Ford Sr., "My Life and Work," p. 86 (1922):
Re: JWZ on s/Java/Perl/
On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote: Uhm, I'm sorry, but that's not good enough. You cannot distinguish between Windows 95/98/ME on one side, and NT/2k on the other, using $^O alone. After all, $^O is just a constant burnt into the executable when perl was compiled. You can run the same perl.exe on all platforms, and indeed, most people do. Yet win9* and NT are different enough in behaviour (e.g. flock) to warrant a test on platform. Er... which is: no go. Well, fork works on both now, but I see your point. There are ways of detecting the OS at run-time under Windows, mostly through MFC junk or peeking in the registry. It would probably be good to do it for the MacOS versions, too. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ That which stirs me, stirs everything. -- Squonk Opera, "Spoon"
Re: JWZ on s/Java/Perl/
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote: The desire to know the name of the runtime platform is a misdirected desire. What you really want to know is whether function Foo will be there, what kind of signature it has, whether file Bar will be there, what kind of format it has, and so on, whether a feature Zog is present, or what is the value of parameter Blah. Just knowing the name of the platform doesn't buy you a whole lot. True, but you can't do any of all that without knowing the platform accurately (nontrivial and requires core mod or XS). Once that's done, the rest is just a matter of extending File::Spec (trivial and pure Perl). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: JWZ on s/Java/Perl/
On Mon, Jan 29, 2001 at 12:10:31AM -0600, Jarkko Hietaniemi wrote: Trivial? *cough* *snigger* I'd write it up for you right now, but its too big to fit in the margin. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Skrewtape I've heard that semen tastes different depending on diet. Is that true? Skrewtape Hello? Schwern Skrewtape: Hang on, I'm conducting research.
Re: RFC195: Do not remove 'chop' PLEASE!
On Sat, Jan 27, 2001 at 03:42:43PM -0700, root wrote:
I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
chop() and chomp() are very often confused due to their similar names,
similar functionality and the fact that chop() did chomp()'s job
(poorly) prior to perl5. Nowdays, chop() is very often used where
they really ment chomp().
Actually, the docs are somewhat to blame for this. perlfunc is loaded
with chop misuses. Will fix.
The complex nature of the complete chop() is unfortunate, it makes it
very difficult to reimplement and prototype. The basic version,
however, isn't hard:
sub chop (;\$) {
my($var) = @_ ? $_[0] : $_;
return substr($var, -1, 1, '');
}
Once you start getting into chopping lists and hashes, it becomes
impossible to prototype.
PS I just ran exactly into your example the other day dealing with
Text::Wrap guts.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
BOFH excuse #69:
knot in cables caused data stream to become twisted and kinked
Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 01:26:09AM +0100, [EMAIL PROTECTED] wrote:
On Sat, Jan 27, 2001 at 05:13:23PM -0500, Michael G Schwern wrote:
This one not only modifies its arguments (or $_ when called without),
it also has the right prototype and works on lists:
sub chop (@) {
my $__;
map {$__ = substr $_ = -1, 1, ""} @_ ? @_ : $_;
$__;
}
Aliasing is a cute thing.
I keep forgetting you can modify @_ in place. However, the prototype
on chop is beyond Perl's system. 5.6 reports it as undef, but 5.7.0
says @. Odd. 5.7.0 also adds the additional complexity of dealing
with hashes. Cchop(%hash) is supposed to work... and it does (on
your routine). How does that work? I'd expect %hash to be fed to the
subroutine as a list.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Paste is a waste if you're chaste,
but in this case dump a load
of goo and poo by the case in your face,
and place in your jawls like a juicy chaw,
but don't spit that shit and enjoy it all.
-- Ubergirl's beau
Re: RFC on Coexistance and simulaneous use of multiple module version s?
On Fri, Jan 26, 2001 at 02:08:01PM -0600, Garrett Goebel wrote: Discussion of RFC 271 and 194 on pre and post handlers for subroutines reminded me of Larry's desire for Perl 6 to support the coexistance of different versions of modules. Besides http://dev.perl.org/rfc/78.pod, are there any RFC's which directly or indirectly relate to this? This sort of came up during the CPAN sekret meeting at TPC last year. Ziggy should have the details, but from what I remember we discussed an idea to allow people and organizations to produce their own list of approved modules. For example, if Oracle had their own QA people approve a set of modules and versions allowed for use in their company. These lists would be archived and made available just like CPAN is now. A subclass of the CPAN shell could be built allowing the user to specify which organizations they trust and it would only pull modules from there. This isn't *quite* what most people are thinking of, and it in no way addresses the problem of having multiple versions of the same module installed on a given machine, but it does allow people to pick and choose between implementations without fragmenting CPAN. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Only mindless violence can raise my spirits now!
Re: RFC from a newbie: Method References
On Fri, Dec 15, 2000 at 11:23:23PM -0800, Ian Hickson wrote:
Having said that: The only feature that I really miss from Perl 5 is the
lack of method pointers -- that is, references to functions in a package
with an associated object.
Oh, that's easy. Use a closure...
my $foo = Foo-new;
my $meth_ref = sub { $foo-method };
$methodref();
In fact, here's an example implementation...
package Class::MethRef;
use strict;
sub meth_ref {
my($proto, $method, @args) = @_;
return sub { $proto-$method(@args) };
}
So this...
my $meth_ref = $obj-meth_ref('foo', @some_stuff);
$meth_ref-();
is equivalent to this..
$obj-foo(@some_stuff);
You could even make the meth_ref take additional (or overriding) arguments.
Its a good idea, I'll put Class::MethRef on CPAN soon.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines
CAPS LOCK KEY STUCK STOP CANNOT PROGRAM PERL REVERTING TO BASIC STOP SEND HELP QUICK STOP -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse When faced with desperate circumstances, we must adapt. - Seven of Nine
Re: RFC 266 (v1) Any scalar can be a hash key
On Thu, Sep 21, 2000 at 03:54:27AM -, Perl6 RFC Librarian wrote: =head1 IMPLEMENTATION Dunno. With my vague understanding of the existing code and hash tables in general: I believe the main reason why hash keys can't be references is because they're not really scalars. Internally they're just normal char strings IIRC, not SVs. I'm sure at one point there were efficiency and memory arguments for this, but I don't know if they still hold. The idea of promoting hash keys to true scalars has been knocked out before. I'm sure you can dig up some p5p threads on the subject. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Maybe they hooked you up with one of those ass-making magazines. -- brian d foy as misheard by Michael G Schwern
Re: RFC 267 (v1) Eliminate dump() function
On Thu, Sep 21, 2000 at 03:55:21AM -, Perl6 RFC Librarian wrote: Eliminate dump() function I didn't even know it existed. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Any failure I encounter in life is the fault of android weasels. -- everything i ever needed to know i learned from goats
Re: RFC 264 (v1) Provide a standard module to simplify the creation of source filters
On Wed, Sep 20, 2000 at 04:12:17AM -, Perl6 RFC Librarian wrote:
Given this level of complexity, it's perhaps not surprising that source
code filtering is not commonly used.
The both times I've attempted to use Filter::Util::Call, I've wound up
reverting to Filter::Util::Exec and doing something like this:
use Filter::Util::Exec;
sub import {
my($self, $term) = @_;
$term = 'Peterbilt' unless defined $term;
Filter::Util::Exec::filter_add($self, $^X, '-pe', "");
warn "Use of '\$1' detected at line \$.\n".
"Perhaps you meant '$term'?\n" if /(peterbuilt|$term)/i
$term ne \$1;
s/$term/;/g;
}
Filter::Util::Call's way of doing things is just too twisted and
strange.
Anyhow, I guess this is an elaborate "me too".
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
shitting is a chore
wet glue enters my sphincter
I shall poop no more
-- Schwern
Re: RFC 259 (v1) Builtins : Make use of hashref context for garrulous builtins
On Tue, Sep 19, 2000 at 07:00:36AM -, Perl6 RFC Librarian wrote: =head1 REFERENCES This RFC explains the mechanism by which HASHREF context would be detected: RFC 21: Replace Cwantarray with a generic Cwant function These RFCs propose alternative solutions to this problem: RFC 37: Positional Return Lists Considered Harmful RFC 127: Sane resolution to large function returns Don't forget RFC 48 which discusses a localtime() replacement returning a hash. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse gumballs have no paste Tim's balls are so damn pasty bend over and squeal -- |siv|
Re: RFC 257 (v1) UNIVERSAL::import()
Would anyone find it useful to have a UNIVERSAL method which reports
on what sybols a given module exports? For example:
package Foo;
@EXPORT = qw(this @that);
@EXPORT_OK = qw($up down);
# this, @that, $up, down
print join ", ", Foo-exports;
With an argument, it would be analgous to can():
print "Yes" if Foo-exports('this');
This can be useful for sanity checking when doing incestuous things
with modules:
if( $error ) {
require Carp;
assert( Carp-exports('cluck') );
Carp::cluck('The Royal Air Force does not allow chickens to '.
'fly planes!');
}
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC 257 (v1) UNIVERSAL::import()
On Tue, Sep 19, 2000 at 08:06:58AM -0700, Nathan Wiger wrote: If exports() could take arbitrary symbols, just like @EXPORT Yes, that's the idea. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Cheating is often more efficient. - Seven of Nine
Re: pack/unpack is damn unperlish. Explain them as Perl.
On Mon, Sep 18, 2000 at 10:54:04AM -0700, Peter Scott wrote: I don't see how you could possibly do it without that any more than you can use numbers without understanding the range limits of integers and floating point roundoff. You ignore that incidental detail until later on in the docs and assume that by the time users start writing programs with numbers 2**31 they'll have read that far. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Mon, Sep 18, 2000 at 04:58:45AM -, Perl6 RFC Librarian wrote:
=head2 Combining attributes
You can, of course, combined the C:laccess and C:raccess attributes
on a given key to autogenerate accessors that work in both Clvalue and
Crvalue contexts, if you simply want to hide your data.
How about also just ":access" to do both? It would seem to be the
most common case.
=head2 Mixing autoaccessors and real subs
The final case is where these become really powerful, but also makes the
implementation a little tricky. Here, we want to create an lvalue sub
that does something productive, but an rvalue autoaccessor:
I really don't see how this is necessary. If you have to write a
custom accessor, you might as well write the whole thing. Doesn't
save much programming effort to be able to still use the default for
one context and custom for other, and it would greatly simplify the
implementation without it.
I also don't see that the optimization of one half of the accessor vs
the other is worth the trouble.
=head1 IMPLEMENTATION
In order for this to work, a couple things have to be true:
1. Autoaccessor methods have to take precedence over declared
methods in some way.
2. A means for duplication of method namespace has to exist.
If we eliminate the thing about mixing, this goes away.
4. There must be a way to set attributes on individual hash keys
in Perl 6.
While in general this might be a good idea, is it really necessary for
this proposal? How about this:
package Foo;
use laccess qw(this);
use raccess qw(foo);
use access qw(up);
sub new { bless {} }
my $foo = Foo-new;
$foo-this = 'that';
$foo-foo('bar');
$foo-up = 'down';
$foo-up('sideways');
This also means accessors are defined on a per class basis rather than
per object (which is potentially extremely confusing and difficult to
implement).
Although this makes your C$self-{DATA}-{NUMERIC}-{S_size} :raccess('size') =
undef; case tricky to emulate. It also makes
combining attributes difficult. Will ponder.
Bingo. So, implementationally, it seems all of these could be satisfied
by having this:
$r-method;
Do the following in order:
1. Look for a declared autoaccessor for the given context.
Context. I hope this means context of the object $r?
2. readonly rvalue subs
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00096.html
implies that this isn't needed because of the proposed :constant hash
attribute. This isn't enough. There is a distince difference between
an attribute that is constant, and one which is read-only. That
difference being that a read-only value should be able to be written to
*privately*.
Consider the case of an accessor which returns a list of object fields
which have changed since the last time the object was changed
(Class::DBI does this). The list of obviously not constant, yet the
accessor should be read-only.
3. mutators
I suspect the first one should not be solved. The real idea behind
autoaccessors, as James pointed out, is speed and simplicity. As such,
requiring you to pass stuff around by reference:
$r-autoaccessor = \@stuff;
$r-autoaccessor(\@stuff);
@stuff = @{$r-autoaccessor};
I was about to say that :deref wouldn't be a bad idea, but that would
just be shifting the problem from pass-by-reference to pass-by-value.
$r-autoaccessor = @stuff;
@stuff = $r-autoaccessor;
If this is made equivalent to your code above, it makes pass-by-value
icky.
$r-autoaccessor = @{[@stuff]};
If we make it copy the value of @stuff first (like $r-autoaccessor =
[@stuff] currently does) then this all encourages inefficiencies.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
GuRuThuG make a channel called Perl, and infest it with joking and
funit doesnt make alot of sense.
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Sun, Sep 17, 2000 at 11:25:49PM -0700, Nathan Wiger wrote:
I also don't see that the optimization of one half of the accessor vs
the other is worth the trouble.
Well, it depends on how much faster the autoaccessor is. If it is much
faster, and you need to access a whole bunch of data repeatedly, then
this makes sense. But if the autoaccessor is about the same as a sub
speed-wise, then screw it, I agree.
I dunno, its going to be alot of work for an optimization. Hell, if
you implement that, you might as well go all the way and implement
polymorphic functions.
2. readonly rvalue subs
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00096.html
implies that this isn't needed because of the proposed :constant hash
attribute. This isn't enough.
Yeah, check out this email:
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00099.html
The idea I originally had was that :raccess would specify something was
an rvalue accessor which only returned a value, and couldn't take
arguments. I think this is probably the way to go, otherwise we have to
start adding other keywords, properties, etc, which really complicate
things too much.
Saw that email, its not enough. The usefulness of an automated
accessor is hamstrung if you can only get with it and never set. The
vast majority of cases wil be read/write.
You need not have :raccess, :rvalue, :laccess and :lvalue. Just
:raccess, :rvalue and :readonly (not :ronly, looks like :rightonly).
For an idea of how complicated this can all get, look at
Class::MethodMaker. Has a *bewildering* array of options. What
you've got so far looks down right boney by comparison.
Couldn't quite see what you were getting at here - maybe a little
clarification. I'm pretty sure I understand ("autoderef bad, but forced
copy bad too") but want to make 100% sure.
That's about it. *grunt*
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
Re: RFC 254 (v1) Class Collections: Provide the ability to overload classes
On Mon, Sep 18, 2000 at 05:49:28AM -, Perl6 RFC Librarian wrote:
Here's where the problem lies. Even though we now have a subclass
of Frog, the Forest class is still referencing the original Frog
class and not Frog::Japanese.
The DBI has this very problem! DBI-connect() returns DBI::db
objects, DBI-prepare() returns DBI::st. If you want to override the
behavior for statement handles and connections, its not enough to just
subclass DBI::st and DBI::db, you must also subclass DBI and override
connect() and prepare() (and hope DBI doesn't use DBI::st or DBI::db
anywhere else.)
DBI-init_rootclass() is a fairly hairy workaround to this problem.
It works like this:
package Ima::DBI::db;
@ISA = qw(DBI::db);
package Ima::DBI::st;
@ISA = qw(DBI::st);
package Ima::DBI;
use base qw(DBI);
Ima::DBI-init_rootclass;
# $dbh is an Ima::DBI::db object, $sth is an Ima::DBI::st
$dbh = Ima::DBI-connect(...);
$sth = $dbh-prepare(...);
Ima::DBI-init_rootclass() informs the DBI that Ima::DBI is a subclass
and that Ima::DBI::db and Ima::DBI::st objects should be used. It
does this by just appending '::db' onto the classname, which means the
names of the classes are fixed. A Bad Thing.
[From DBI-connect()]
# XXX this is inelegant but practical in the short term, sigh.
if ($installed_rootclass{$class}) {
$dbh-{RootClass} = $class;
bless $dbh = $class.'::db';
my ($outer, $inner) = DBI::_handles($dbh);
bless $inner = $class.'::db';
}
It works, but to quote Tim Bunce there... *sigh*.
So anyhow, yes, this is a big, icky problem.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN
sChWErn ScHWeRn schweRn sCHWErN schWeRn
scHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN
sChwern scHWerNscHWeRn scHWerNScHwerN
SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN
sChWeRn
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
On Mon, Sep 18, 2000 at 09:48:27AM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Nope. fields::new() basically just does Cbless
[\%{"$class\::FIELDS"}], $class, but the current pseudohash
implementation doesn't care if something is an object or not. It just
cares about either A) its type or B) what's in $ph-[0].
Hmm... it still feels like undocumented behaviour. I'd definitely be
inclined to tighten up the base/fields behaviour. My feeling is that
the proposal makes them closer to the Right Thing.
Its plenty documented. But if we simply put a bullet into
pseudo-hashes, as per RFC 241, this all goes away.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC - Interpolation of method calls
On Mon, Sep 18, 2000 at 07:23:41AM -0600, Tom Christiansen wrote:
Oh joy: now Perl has nested quotes. I *hate* nested quotes.
Those are single-quotes inside double-quotes.
Yep: nested, with varying semantic effects. Completely nasty.
As Nate pointed out: print "$hash-{'f'.'oo'}" already works fine and
the world spins on.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Mon, Sep 18, 2000 at 01:02:31PM -0700, Glenn Linderman wrote: OK, thanks for the info. I'm not an internals guy, but I guess I should have written the benchmark. It just _seemed_ they should be slower, because there is more work to do the hashing. The actual lookup, I agree, should be the same. Similar mistaken logic leads to "globals are faster than lexicals". Now while it is _totally_ true from your numbers that the lookup (read reference) costs are the same, it would seem that the variability in write references could still make this pay off. The set_const is about 40% slower for hash, and set_var is about 166% slower. Accessor overhead swamps all. N.B. I wonder if the hash accessor is faster because the array accessor is referencing past the end of the array? (not apples to apples here, you use index 0 everywhere else, and index 1 in the accessor.) Its just benchmarking flutter. I reran it with 1 everywhere else and the same results. Besides, because $aobj is global, the first call would extend the array and the following 899_999 wouldn't worrry about it. I know, lets call it a pseudo-hash! Been there, done that, worn the scars proudly. Is _that_ what a pseudo-hash is? Then it sounds like a good idea. But maybe there are some differences between today's pseudo-hash and my proposal, even though they might be similar. I think mine is pretty general, and the discussion on this list made it sound like pseudo-hash has some other restrictions? Read RFC 241 for a brief overview of pseudo-hash problems. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Mon, Sep 18, 2000 at 01:26:45PM -0700, Glenn Linderman wrote:
Michael G Schwern wrote:
Similar mistaken logic leads to "globals are faster than lexicals".
Maybe so, but I'd think lexicals would be faster, because more of
the lookup is done at compile time rather than runtime... so I'm not
sure what is similar about the mistaken logic...
A better one would be "dereferences are slower than using the variable
directly". ie. its a common misconception that $href-{key} should
be slower than $hash{key} because you have to dereference $href. This
mostly comes from C where dereferencing a pointer is slower than using
the variable directly.
Turns out references edge out globals. Why? A global variable has to
look up its symbol at run-time, get a *reference* out of it and
dereference it. Most of the time if you're using a reference, its
lexical. All a lexical reference has to do is dereference itself,
thus avoiding the symbol table lookup.
I've see this done:
sub foo {
my($href) = shift;
local(*hash) = $href;
}
as an "optimization". Turns out that slows things down even further!
Declaring the local version of %hash is much, much more work than
everything else altogether.
I guess I'm trying to say something about micro-optmizations being
more trouble than they're worth and usually hurt more than they help.
So let's posit you've cured the accessor overhead problem. Now
we're left with set_const being 40% slower for hash, and set_var
166% slower for hash. Still want to ignore it? Why?
Well, the fixed accessors would be using constant key lookups, so we
only have to worry about 40%, and this is 40% of a tiny, tiny fraction
of the actual overhead of a typical class. So going nuts about making
it faster probably won't gain us much overall. Certainly not worth
the effort of making arrays as easy to use as objects.
Take a class you've written that uses thin accessors and run it
through a profiler. Look at the time spent in the accessors and
reduce it by 80% (the expected efficiency increase for built-in
accessors) and recalculate its overall effect on your performance. If
its more than 5% I would be surprised.
Bascially, if accessor methods are currently eating less than 25% of
your total overhead, they will eat 5% if they are made built-in.
After that, diminishing returns kicks in. A further 40% reduction
results in a 2% overall increase. Who cares? Spend the time elsewhere.
(This is the classic argument against early/micro optimizations)
I know, lets call it a pseudo-hash!
Been there, done that, worn the scars proudly.
Is _that_ what a pseudo-hash is? Then it sounds like a good idea.
Yeah, it *sounds* like a good idea, but there's lots and lots of
little problems.
Doesn't play well with multiple inheritance
I can sure believe this. There'd be indexes from multiple base classes. I
don't know how Perl does multiple inheritance anyway, so I can't comment
effectively on whether this is or would be a problem. If Perl does multiple
inheritance, I haven't stumbled across the documentation for it, but neither
have I looked. I don't use multiple inheritance.
The phrase "multiple inheritance" only comes up in perlboot, perltoot and
perltootc. perlobj only implies that MI works because otherwise it
would be $ISA, not @ISA.
I use MI alot and really couldn't see a language without it.
Muddles the behavior of typed variables
Not sure what this means.
Currently, the only thing really using the Cmy Dog $spot syntax is
psuedo-hashes.
my Dog $ph;
$ph-{cat} = 'Mrs. Chippy'; # $ph-[$Dog::FIELDS{cat}]
and there have been several RFCs about clarifying what typed variables
mean (usually in reference to objects). Pseudo-hashes get in the way
of alot of those proposals.
Requires significant extra documentation and complication of
hash operations.
I've used perl for some years, and never noticed pseudo-hashes from the user
perspective. Is this an internals only issue? Or what else have I missed?
Its both an internals and a doc issue. In the guts, there's a bunch
of special cases for them in the guts (though not nearly so
troublesome as, say, threading) although most of the functionality is
restriected to av.c. The documentation is the bigger issue,
pseudo-hashes involve alot of caveats when explaining hashes, though
much of them have gone away in 5.6.0.
Also, the whole fields and base modules are troublesome. If you wish
to write a subclass but use a pseudohash for your object instead of a
hash, you really can't unless the class author was careful enough to
declare all their fields (a rare occurance). Also, consider the case
of a pseudo-hash friendly class, but with a subclass that uses @ISA
directly instead of base.pm and hashes instead of pseudo-hashes. A
subclass of that subclas
Re: RFC 252 (v1) Interpolation of subroutines
On Mon, Sep 18, 2000 at 01:16:43AM -0600, Tom Christiansen wrote: Huh? And what if it's a built-in? What if it's not quite a built-in, but an import? What if you don't *know* whether it's a built-in? Easy enough, built-ins shouldn't be special (I'm speaking in general, not just when interpolated). They should be able to be called like any other subroutine and even take a reference. They can continue to be differenciated from defined funtions with the CORE:: prefix. The caveats and special cases surrounding built-ins are argument enough for their syntactical unification with functions. Hasn't anyone RFC'd this? And yes, the distinction between quoted and unquoted context is beginning to blur. This is not necessarily a Bad Thing. I'm sure Old School C programmers thought it was the End Of The World when it was proposed that scalars and arrays should interpolate. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I'm not cute, I'm evil. -- Diablo www.goats.com
Re: RFC 223 (v1) Objects: Cuse invocant pragma
On Mon, Sep 18, 2000 at 10:16:46AM -0400, John Porter wrote:
Hildo Biersma wrote:
IMHO, mixing procedural and OO interfaces to the same module is a bad
idea. Promoting it in the language is not wise.
O.k., but that's not the same as disallowing it. Perl is not a BD
language.
I'd just like to second John here. I've got a couple of modules where
the OO and functional interfaces happen to mesh together beautifully
(Class::Fields is one). CGI.pm isn't exactly the greatest example of
a combination of the two styles... but from the holy wars which rage
between C$cgi-param('foo') and Cparam('foo') regularly, I can see
why it is desired.
But it doesn't have to be easy.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC 253 (v1) UNIVERSAL::require()
On Mon, Sep 18, 2000 at 11:20:15AM -0400, John Porter wrote: Seems to me that it would need to be written as $module-UNIVERSAL::require; How do you propose to avoid that? What is a class but a package? And what is the name of a class but a package name? And since there's no concept of an undefined package, any valid package name is a valid class (I'm sure there are exceptions). It all works. Run the prototype code on any module. No. Any reason not to let the error arising from Ceval "require ".ref $obj to do its normal thing? The case may be rare, but it should be allowed: UNIVERSAL::require() should DTRT given an object ref. The case is so rare for one having an object *before* loading its class that most of the time C$obj-require will be a programming mistake. If C$obj-require is made to work, the mistake will become silent and not be noticed until much futher on down in the code. Garbage In, Error Out. If you really want it, the wrapper require() is trivial. DTRT? Data Terminal Ready, Tim? Document Filing and Retrieval Tedium? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse If you only hear one song this year there's something terribly wrong with you.
Re: pack/unpack is damn unperlish. Explain them as Perl.
On Mon, Sep 18, 2000 at 12:31:34PM -0400, Casey R. Tweten wrote: I think pack/unpack are perlish enough. Especially if we believe that printf/sprintf are perlish. Interpolation is perlish. printf and sprintf are not. And for similar reasons as pack/unpack. "%e a floating-point number, in scientific notation". People don't trip over s/printf as much for several reasons: Anyone who's written even the slightest amount of C has used printf(). Even if you haven't, there's high odds that someone around you has and can help. printf() has a direct analogy to print(). "printf is like print, except..." which makes it much easier to explain. It provides that bit of mental runway to get the reader's mind off the ground. The differences between sprintf and printf are very easy to explain. "Equivalent to Cprint sprintf" -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I SEE A RED ASS AND I WANT TO PASTE IT BLACK WON'T OPEN ANYMORE I PASTED UP THE CRACK -- swansong
Re: pack/unpack is damn unperlish. Explain them as Perl.
On Mon, Sep 18, 2000 at 12:32:08PM -0400, Sam Tregar wrote: "Describe to me how you use a supermarket shopping-cart in terms of a hardware store. Don't mention any words for food. Just talk about nuts and bolts." "When shopping for tools, a shopping-cart is the thing you carry your tools in before paying for them. It rolls around on wheels and keeps one hand free for more important things like holding your beer." You can do it! While it seems "food" and "supermarket" are critical to the understanding of a shopping-cart, they're really just incedental. I'm saying the same thing about un/pack! If I grok'd the bastards, I'd write the explaination myself. Maybe you don't get to know how good it is until you need it? I'm sure there are many times when pack should have been used but it got hacked together with something else. The prime example is fixed-width data parsing. Most people reach for substr() or a regex, but the best solution (as pointed out in perlfaq5) is pack. Yet it still remains obtuse and I'm largely cargo-culting when I use it. Think about a user who does not understand regexes. They typically have no idea what they're missing. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse GuRuThuG make a channel called Perl, and infest it with joking and funit doesnt make alot of sense.
pack/unpack is damn unperlish. Explain them as Perl.
My first language was Perl and its pretty much my native computing tongue. My lack of a firm grounding in C or other lower level language probably hamstrings my understanding of manipulating binary structures (I do, at least, understand what "single-precision float in the native format" means, but it makes my feet itch). This is probably a Good Thing in this case, as I'm scratching my head, along with lots of other people, over what the hell pack is good for and how do you use it? Its just damn unperlish. Perhaps that's in its nature, being that its for converting data from things which are Perl, but we've got to be able to do better. I really can't articulate better than that because I don't really grok the existing pack/unpack and what they're supposed to do. Something about converting binary structures into Perl and vice-versa. But there's got to be a better way. Maybe the docs just need an overhaul. Perhaps someone could attempt to write an explaination of pack and unpack in completely Perl terms. No bits, no ints, no nybbles, no IEEE floating point arithmetic, no prior knowledge of C necessary. Those are not Perl. Scalars, arrays, hashes, functions, methods, loops, contexts. These are Perl. This is *explaination*, not documentation. I don't want details, I want to know the basics of who needs it, what it does, when I should use it and how its used. Once we have this in hand, it may help us to write a better interface. If nothing else, we'll get a perlpacktut man page. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse If you only hear one song this year there's something terribly wrong with you.
Re: RFC 100 (v2) Embed full URI support into Perl
On Sun, Sep 17, 2000 at 05:36:56AM -, Perl6 RFC Librarian wrote: unlink "/local/etc/script.conf";# non-portable unlink "file:///local/etc/script.conf"; # portable '/local/etc/script.conf' is very unlikely to exist or be a sensible filename on Windows or MacOS (or Unix. Shouldn't that be /usr/local?). The suggestion about stripping C:\ off the filepath doesn't help much. Windows programs like to put things in the root directory. (C:\PERL anyone?). Unix prefers many different locations, and severely restricts usage of /. MacOS and Windows paths have a chance of being portable, since both don't mind putting things in root positions, by mapping C: to the main MacOS partition. What about D:? "file://C|/foo" and "file://D|/foo". On Windows they're seperate. On Unix they're... what? On MacOS, C: could be the main partition and D: a secondary one (if it exists, which is relatively uncommon), but which one? And as the disposition of MacOS partitions varies wildly, it will more than likely produce extremely surprising results. AUUGH!! And we haven't even gotten into VMS and OS/2 yet. Oh, how about the Amiga? BeOS? OS390? Solving the file seperator problem is one thing. Calling it "portable" is huge stretch. Now, where the file: url *does* win is relative files. open 'file:some/directory/file'; All the noise I was talking about above goes away.. but there's more trouble waiting. Case-sensitive vs insensitive filesystems, maximum filename length, maximum path length, restrictions on the filename, restrictions on the suffix (ie. 8.3 DOS). Maybe we should just go back to paper. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRn scHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: RFC - Interpolation of method calls
Sorry, I wasn't subscribed to perl6-language-objects and didn't even
realize there was a discussion going on. I just fixed that.
I didn't mean to hijack RFC 103, I can't remember if I'd even looked
at it before... but Nathan seems okay with that and it is a
deceptively large issue.
Version 2 of the RFC went out last night (I'll have to do v3 after
reading these comments) and clarifies a few things (the changes are
all listed at the top). Most importantly, C"$weather-temp("F")"
was a typo. It should have been C"$weather-temp(\"F\")". Also,
RFCs about interpolation of class methods and subroutines also went
out last night, so I'll let them speak for themselves.
Now, about that context thing. The main conundrum is what to do with
methods that return a list. Would it be best to just let it be scalar
context?
# $inventory-pinatas returns a list of pinatas we have.
# "Yes, El Guapo, I would say I have 23 pinatas\n";
print "Yes, El Guapo, I would say I have $inventory-pinatas pinatas\n";
Or would it be better to expand the returned list, as arrays are
expanded with Cjoin $", @array? Now that I think about it, its
fairly obvious that simple scalar context is best. Why? I can't even
think of a useful example of the list expansion.
Most of the time you want to seperate them with a ", " anyway, not
with $".
So junk that bit about the context weirdness. Simple scalar context it is.
Nathan already covered the questions about evaluating expressions and
arguments. Perl already does it for everything else. Furthermore,
interpolating the expression should be simple, as I realized later
while writing the RFC for interpolatoin of subroutines.
The tokenizer can watch for /[A-Z_]\w*/i. If followed by a '(', then the
parsing becomes the same as for normal subroutine arguments excepting that
it must watch for an unescaped closing string character.
I'm also glad to find out Perl already disallows whitespace for other
interpolated constructs.
I appear to have a new version of the RFC ready without the first even
having made it out to the public!
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Many people think that an UFO is probably propelled by some kind of
antigravity magnetic motor. I have a totally different thinking. I believe
that an UFO is propelled by jet engine. UFO's gyroscopic body rotates and
serves as its wing to keep UFO's body balanced in the air.
--Alex Chiu, Immortality Guy
Re: RFC - Interpolation of method calls
On Sun, Sep 17, 2000 at 08:56:23PM -0600, Tom Christiansen wrote: While you're there, you should fix it to spell piñatas properly. :-( We're not talking about stands of pine trees, presumably. Funny, I know how to type extended characters in MacOS, but I have no idea how to do it in X. Hell, my font doesn't even display them right. *grumble* -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #270: Someone has messed up the kernel pointers
Re: RFC 241 (v1) Pseudo-hashes must die!
On Sun, Sep 17, 2000 at 03:37:07PM -0700, Peter Scott wrote: However, while we've got ways in P6 to do objects better without pseudo-hashes, a major benefit of them to me is nothing to do with objects, and that's the ability to fix the keys of a hash. I would like to see this retained. RFC 122 talks about implementing hashes which are C-like structs in Perl. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Don't ask me, lady. I live in beer. -- fish http://www.goats.com/archive/index.html?000107
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Sat, Sep 16, 2000 at 08:08:06AM -, Perl6 RFC Librarian wrote: There only way to avoid the action at a distance is to prohibit one of these interpretations. Since the other way Cfoo-bar $baz to write this method call is as convenient as the indirect object syntax, the proposal is to prohibit the indirect object method calls altogether. This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. Not that I'd mind seeing it buried (indirect object syntax, not Nathan's RFCs) but you should enumerate the RFCs you're conflicting with. PS Shouldn't this be on perl6-language-objects? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Cheating is often more efficient. - Seven of Nine
Re: RFC 241 (v1) Pseudo-hashes must die!
On Sat, Sep 16, 2000 at 10:31:55AM +0100, Hildo Biersma wrote:
AFAIK, most of the pain in the implementation is caused because any old
array can be 'promoted' into a pseduo-hash at any-time. If
pseudo-hashes always have to be pre-declared (eg, can only be created
through fields::new()) and only support he hash-interface (not array),
much of that pain could go away.
fields::new() does smooth things out a little bit, but it doesn't win
much. It guarantees that $ph-[0] will be filled in with \%{ref
$ph.'::FIELDS'} and also guarantees that $ph will be an object. That
solves the problems of inconsistancies between typed and untyped
access, but little else.
Pseudo-hashes are not a good/clean way to implement typed objects.
Why? Can't do multiple inheritence (without *alot* of contortions).
And there's also the inefficiencies of untyped pseudo-hash access.
Pseudo-hashes made some sense in the restrictions of Perl 5 syntax,
but we've got room now to rethink the problem from scratch.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But unluckily most Germans here are too smart. They all speak good English
and won't be able to speak German to me.
--Alex Chiu, Immortality Guy
Re: RFC 71 (v2) Legacy Perl $pkg'var should die
On Sat, Sep 16, 2000 at 09:18:05AM -0700, Nathan Wiger wrote: "use D'oh" will be missed :-), but sometimes legacy stuff needs to be expunged to get people to modernize. Of all the legacy things which get abused, this is the one I've never seen. Plus, ' is already widely-used as a single-quote, so That's a good argument. Unambiguating the language and simplifying the parser. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse When faced with desperate circumstances, we must adapt. - Seven of Nine
Re: RFC 103 (v2) Fix C$pkg::$var precedence issues with parsing of C::
On Sat, Sep 16, 2000 at 02:57:01PM -0700, Nathan Wiger wrote:
Ooop, didn't even notice and didn't see the discussion. Let me see if
I missed anything... I didn't discuss class methods as opposed to
object methods. Will ponder.
It's really dicey. I think it's probably bad, because there's no way to
tell here:
print "Your name is Class-name";
Whether Class is 'Class' or Class(). The phrase "avoid at all costs"
comes to mind. ;-)
Hmmm... we could require that the trailing parens be there:
print "Your name is Class-name()";
This has precedence in dynamic method calls, ie. C$obj-$meth()
where the parens are used to disambiguage the statement.
!@()*!@@!$(*!_)(@*_!
That should compile cleanly in Perl 6.
Ceval "require $class" isn't that hard, but I wouldn't mind seeing a
more obvious way.
Nothin' leaps out. My brain hurst.
How's about this?
package UNIVERSAL;
sub require {
my($class) = shift;
my $return = eval "CORE::require($class)";
die $@ if $@;
return $return;
}
package main;
my $class = 'CGI';
$class-require;
print $class-header;
It would be nice if there could be a corresponding use() but that
would be in conflicting with the run-time nature of $class and method
calls. Still, this:
BEGIN { $class-require; $class-import } # use $class
is more obvious than this:
BEGIN { eval "require $class"; $class-import } # use $class
and has the virtue of preserving the death if the require() fails.
(Most people forget to check $@ when they use the eval/require trick)
This combines the problems of symbolic references PLUS busting
encapsulation. Shouldn't be easy.
I'd just settle for easiER than this:
{"${mypkg}::do_stuff"}(@a) # {$mypkg.'::'."do_stuff"}(@_) too
It only busts encapsulation if you're using it as an object. If you just
want to get to a function without importing it, then you've gotta type
lots.
OO isn't the only coding style which involves encapsulation, but I'll
concede the point.
However, how often do you find yourself with the name of a package in
a variable and the function hardcoded? Seems a strange occasion since
rarely will two non-OO packages implement interchangable functions.
If you find yourself needing that sort of thing often, perhaps it
should be rewritten as OO.
I'm feelin' an RFC retraction comin' on...
[Schwern rubs his black gloved hands gleefully and cuts another notch
into his black hat.]
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Long, long time ago, in a far away galaxy, cells were formed. Cells are
building blocks of different chemicals.
--Alex Chiu, Immortality Guy
Re: RFC 103 (v2) Fix C$pkg::$var precedence issues with parsing of C::
On Sat, Sep 16, 2000 at 07:26:38PM -0700, Nathan Wiger wrote:
My point was more should that be
'Class'-name
or
Class()-name
I don't get it, lemme start from the beginning:
print "Basset hounds got long Basset::Hounds-thang().";
I'd like that to work out as:
print 'Basset hounds got long '.Basset::Hounds-thang.'.';
but are you suggesting it may do this?
print 'Basset hounds got long '.Basset::Hounds().'-thang.';
Functions don't currently interpolate inside strings. Maybe they
should, but if so definately with a leading .
I dunno, how common is "word-another_word()" in a string?
Since this seems less obvious than object methods, I'm going to RFC it
seperately.
But this is definitely useful:
$r = Apache-request;
print "URI is $r-uri";
Yes, the main concern is that accessor methods work. I can live
without class methods.
How's about this?
BEGIN { $class-require; $class-import } # use $class
I like it. But I'm all RFC'ed out, so it's yours, baby... ;-)
RFC ho!
[Nate drinks a beer to try and ease the pain of 4 RFC retractions and
another 22 that just need updating.]
If you're coming to YAPC::Europe, I definately owe you a few beers.
If nothing else than for the hell I've been giving you over here-docs.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
MORONS!
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
On Sat, Sep 16, 2000 at 03:37:33AM -, Perl6 RFC Librarian wrote:
"%hash" should expand to:
join( $/, map { qq($_$"$hash{$_}) } keys %hash )
So let me get this straight...
%hash = (foo = 42, bar = 13);
print "%hash";
should come out to:
foo 42
bar 13
The idea of interpolating a hash is cool... but is seperating each
pair by $/ really useful? A comma or $" sees to make more sense.
Could you show some examples of practical usage?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
Re: RFC 222 (v1) Interpolation of method calls
On Thu, Sep 14, 2000 at 05:31:44PM -0500, David L. Nicol wrote:
A possibility that does not appear in RFC222.1 is to put tho whole
accessor expression inside curlies:
print "Today's weather will be ${weather-temp} degrees and sunny.";
which would follow the "You want something funny in your interpolated
scalar's name or reference, you put it in curlies" rule. Since the contents
of that expression is not strictly \w+ it does not get interpreted as
the symbol table lookup ${'weather-temp'}, so that is not a problem, nor
are the whitespace situations listed in the CAVEATS section.
Could you write up some practical examples where this might be useful
(slapping whitespace between the - and method name isn't practical or
useful). I'm loathe to muddle the meaning of ${bareword}.
It did make me think of something else. What about by-variable method
calls. That is:
my $meth = 'species';
print "How much is that $pet-$meth() in the window?";
This should deparse to:
my $meth = 'species';
print "How much is that ".$pet-$meth()." in the window?";
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
I'm not cute, I'm evil.
-- Diablo www.goats.com
Fwd: [Re: [FWP] Comic goodness]
I thought you people might need a little break. The first one is particularly... yeah. - Forwarded message from Jim Monty [EMAIL PROTECTED] - From: Jim Monty [EMAIL PROTECTED] Subject: Re: [FWP] Comic goodness To: [EMAIL PROTECTED] Date: Fri, 15 Sep 2000 09:53:48 -0700 (MST) See, regular expression matter to stick people as well as humans. http://www.explodingdog.com/june11/backref.html Cf. http://www.userfriendly.org/cartoons/archives/99feb/uf000342.gif -- Jim Monty [EMAIL PROTECTED] Tempe, Arizona USA Want to unsubscribe from Fun With Perl? Well, if you insist... Send email to [EMAIL PROTECTED] with message _body_ unsubscribe - End forwarded message - -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would be normally be terminated by detonation. -- Larry Wall in [EMAIL PROTECTED]
Re: RFC 238 (v1) length(@ary) deserves a warning
On Sat, Sep 16, 2000 at 04:21:15PM +1100, Damian Conway wrote: I'm surprised there hasn't be a good overhaul of the prototyping system proposeed yet. What exactly didn't you like about RFC 128??? Ummm... the fact that its title doesn't match /proto/. My bad. Okay, its a proposal to overhaul prototyping, cool. But I don't see anything to allow Clength $string and Clength @array live together. Its a big RFC, I probably missed it. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Cheating is often more efficient. - Seven of Nine
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Thu, Sep 14, 2000 at 03:36:10PM -0700, Nathan Wiger wrote:
See, this is just too inflexible. The main complaint that I've heard has
been "You can't have leading or trailing whitespace around your
terminator". This is a very common error made by everyone, and *this* is
where Perl should DWIM.
See, I never understood this. If you're indenting the terminator, it
implies you're also indenting the here-doc text. I mean, this doesn't
make any sense:
{ { { {
print TAG;
I don't know what their
gripe is. A critic is
simply someone paid to
render opinions glibly.
TAG
} } } }
Right? You're not going to just indent the terminator because you
can. Its going to go along with indenting the text.
So indenting the terminator and indenting the text are linked. If you
do one, you want to do the other.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Yet one of these kittens is not prepared to have a good time. It
stands alone, away from the crowd. Its your kind of kitten. And now
the time has come to climb into that car and shake the paw of destiny.
Re: RFC 227 (v1) Extend the window to turn on taint mode
On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote: I'm kinda surfing the edge here. -T is definately an internals issue, but $TAINT? taint()? is_tainted()? I'm not sure if they should be exposed into the language from the internals, or if a superstudly taint.xs in stdlib is more appropriate. perl6-internals is probably the wrong forum for this, it was just convenient. I think Dan's got the right idea, distribute a Taint module with Perl. Shall we drag this discussion on over to perl6-language? (I've CC'd it and added a Reply-To. This is BCC'd to perl6-internals). -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse When faced with desperate circumstances, we must adapt. - Seven of Nine
Re: RFC 227 (v1) Extend the window to turn on taint mode
On Fri, Sep 15, 2000 at 04:01:11PM -0400, Dan Sugalski wrote: Anyhow, however these extra tainting functions are implemented is fine (as long as they work). The simplest thing would be to just merge and patch up Taint.pm and distribute it with perl6. Yup. I know Tom wanted an all-perl version so there wouldn't be any dependencies on having a C compiler around. I took the XS route mainly because I mistrust indirect methods. (Well, that and I'd written several orders of magnitude more C code for perl than perl code at the point I wrote that...) If we move it into the core the availablity of C compilers is no longer an issue. Having had a taste of the hacks one must do to pull off an all-perl version, XS seems the simplest route. PS I've moved this discussion to perl6-language. Reply accordingly. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC 71 (v2) Legacy Perl $pkg'var should die
On Sat, Sep 16, 2000 at 03:20:23AM -, Perl6 RFC Librarian wrote:
Perl used to use $pkg'var instead of the modern $pkg::var. This is still
in Perl 5. It's gotta go.
Aside from "its old", is there any particular reason why $pkg'var
should go? The only reason I saw was that $hash{a'b} doesn't
DWIM... not exactly a stunning problem.
(Yes, I am the author of D'oh::Year ;)
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
An ice cream has its unique frequencyAre you hungry for this ice cream?
Or not? If you are, a certain part of your body is requesting to attract
chemicals from this ice cream. If you don't have the appetite, your body
doesn't need any chemical from the ice cream. Your brain is most conductive
and serves as the middleman.
--Alex Chiu, Immortality Guy
Re: RFC 236 (v1) Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
On Sat, Sep 16, 2000 at 03:36:45AM -, Perl6 RFC Librarian wrote:
Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
I don't think this is enough to repair $SIG{__WARN__} and
$SIG{__DIE__}. I know some people out there have some very strong
feelings about these pseudo-signals. It may even be that we should
kill them and replace them with something better. Has this yet been
discussed?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
- Unknown narrator speaking about Anime
Re: Cross-referencing RFC 186 with RFC 183 and RFC 79
On Wed, Sep 13, 2000 at 11:21:25PM -0700, Glenn Linderman wrote: This RFC also seems to be related to RFC 183... using POD for testing. Now the model of use apparently envisioned for RFC 183 is to have the tests inside the POD, and then use a preprocessor to hack them out and put them in separate files. Wouldn't it be better to skip that step? Just use the "pod helper command line option" mentioned in the above paragraph, or a variation, to cause perl's first pass to (1) obtain the source for the program or module, (2) also obtain the source for the test module, (3) obtain one or more data handles for test input data and validation data, (4) compile 12 as perl source code, and (5) launch the tests, which can then used the appropriate data handles. But when compiled normally (without the test switches), all the test files simply don't get included. RFC 79 would only effect how the tests are extracted from the code. No alteration of the proposed syntax would be necessary, "=for/=begin/=end testing" will still work fine. As for adding the test extraction to the core as a command switch, I think that's unnecessary. Extracting the testing source is trivial, with or without RFC 79. Once extracted, a module can deal with it just as easily, and with much more flexibility, than a core patch to perl can. Besides, .t files aren't going anywhere and we'll still need external (ie. MakeMaker) support to deal with them. There's no compelling reason to muddle the perl core with test switches, it can be done easier as a module. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse BOFH excuse #39: terrorist activities
Re: Cross-referencing RFC 186 with RFC 183 and RFC 79
On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote: 1) why extract it if it could potentially be used in place 2) if it cannot be used in place, then why bundle it So I guess RFC 183 leaves me not understanding its goals. If there is a benefit to the bundling, then RFC 183 would seem to be only half the solution, the other half would be to use it in place. The benefit to allowing inline tests is stated in the RFC. The main reason why I want to extract the tests into a .t file is because then it can benefit from the testing system already in place and that everyone's familiar with (for limited values of everyone) and we know works. Otherwise we'd have to completely rebuild the testing system, and I don't really see any good reason for that. It does its job well and its one less piece of magic to worry about. It also means it will work in Perl 5. Very important, since I don't want to wait two years before I can start using this. Even if we do manage to do it purely as Perl 5, it will still require that certain modules and utilities are installed in order for the tests to be extracted and run. When I distribute my program, I do not want to guarantee that the user has these incidental files (since they have nothing to do with the running of the module itself, and users have little enough tolerance for downloading additional modules as it is). So I can simply run pod2tests over my code, extract the .t files and distribute them directly. Also, because embedded tests are ment to supplement, *not* supplant, traditional tests, if you're going to have .t files around anyway, one more isn't going to hurt. Nothing you've said below makes me think that it would be impossible to use the data in-place, given a unification of the concepts in RFCs 186, 183, and 79. Whether or not it is valuable is another issue, but, in the never-ending quest to eliminate redundancy, I'll claim that if it is valuable to embed the content in the first place (the point of RFC 183), then it would be valuable to use it in-place rather than extracting it. Now, there's no reason pod2tests couldn't have an "inplace" switch which would do what you propose, either by keeping them entirely in memory or by cleaning up after itself afterwards. I've been thinking largely for the case of testing modules, which already have a testing harness around them. You're probably thinking of individual programs. $ pod2tests --inplace foo.pl foo.pl.ok Something like that would make sense. Eliminating redundancy is one thing, eliminating TMTOWTDI is another. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse But why? It's such a well designed cesspool of C++ code. Why wouldn't you want to hack mozilla? -- Ziggy
RFC - Interpolation of method calls
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern [EMAIL PROTECTED]
Date: 14 Sep 2000
Version:1
Mailing List: [EMAIL PROTECTED]
=head1 ABSTRACT
Method calls should interpolate in double-quoted strings, and similar
locations.
print "Today's weather will be $weather-temp degrees and sunny.";
Would deparse to:
print 'Today\'s weather will be '.$weather-temp().' degrees and sunny.';
=head1 DESCRIPTION
=head2 The Current Problem With OO Interpolation
Object-oriented programming encourages data-hiding, and one of the most basic
tool for this is the accessor method. For reasons which should be obvious,
C$obj-foo() is usually better than C$obj-{foo}. However, there are
several barriers to using an accessor method as simply as one does a hash
lookup. Other RFCs deal with most of the current issues, but a basic one
still remains.
print "Today's weather will be $weather-temp degrees and sunny.";
This does not DWIM. Instead of interpolating C$weather-temp as a method
call, it comes out as C$weather.'-temp' and is usually followed immediately
by the question "What does 'Weather=HASH(0x80d4174)-temp' mean??" Most
programmers learning OO Perl expect this to work and are surprised to find
that it does not.
Work arounds abound:
# If I wanted printf(), I'd have written it in C.
printf "Today's weather will be %d degrees and sunny.", $weather-temp;
my $temp = $weather-temp;
print "Today's weather will be $temp degrees and sunny.";
print "Today's weather will be @{[$weather-temp]} degrees and sunny.";
print "Today's weather will be ".$weather-temp." degrees and sunny.";
None are as simple and as obvious as:
print "Today's weather will be $weather-{temp} degrees and sunny.";
and because of this users groan at having to use accessor methods and are
often tempted to violate encapsulation for ease of use.
=head2 Proposed Solution - Interpolate Methods
Therefore, it is proposed that direct object method calls be interpolated
inside double quoted strings and similar constructs.
print "Today's weather will be $weather-temp degrees and sunny.";
should parse out as:
print 'Today\'s weather will be '.$weather-temp().' degrees and sunny.';
thus returning DWIMness to methods and strings and removing one barrier to
accessor method's acceptance over hash lookups for objects.
Methods will be run in scalar context. A method which returns a single scalar
is treated normally. If a list is returned, it should be treated same as
array interpolation. The list seperator will be applied. In effect, the
deparsing will really work out as follows:
print 'Today\'s weather will be '.join($", $weather-temp()).
' degrees and sunny.';
However if temp() calls wantarray(), the result will be FALSE (scalar).
(For the remainder of the RFC, the join() will be assumed when discussing
deparsing for brevity.)
Should it be decided that a formal distinction be made between accessor
methods and other types (RFC 95), method interpolation should interpolate
Bany method.
=head2 Argument passing
Interpolation should also handle passing arguments to methods in a string:
print "Today's weather will be $weather-temp("F") degrees and sunny.";
This should deparse to:
print 'Today\'s weather will be '.$weather-temp("F").
' degrees and sunny.';
The arguments to the method are considered as normal expressions, thus:
print "There is $obj-foo(this = $yar, that = 2 + 2) in my head.";
deparses as:
print 'There is '.$obj-foo(this = $yar, that = 2 + 2). ' in my head.";
=head1 CAVEATS
Indirect object syntax, being already ambiguous, cannot be easily be
distinguished in a string from normal text and should not be interpolated.
This is ok, since accessors are rarely called with indirect object syntax.
Are there any contexts besides double quotes ("", qq{}, "EOF") where this
need be applied? What about inside regexes? And if so, left and/or right
hand side?
Normally, whitespace is allowed between tokens of a method call.
$obj - bar ("this");
and
$obj-bar("this");
are equivalent. Whitespace between the object, '-', method name and opening
paren should be disallowed when interpolated. This will avoid many ambiguous
cases.
Should the method not exist, Perl will throw an exception/die as usual.
C"$var-{this}[2]{is}-{complex}-method" should also be interpolated. Also
C"$obj-method-{key}" for the case where a method returns a reference.
=head1 IMPLEMENTATION
The behavor of the parser to check for embedded variables would have to be
altered, namely the case where an embedded variable is being dereferenced. A
case would be added to allo
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
package Dog;
use fields qw(this night up);
my Dog $ph = [];
$ph-{this} = "that";
That works? I thought you had to do:
my Dog $self = fields::new('Dog');
Nope. fields::new() basically just does Cbless
[\%{"$class\::FIELDS"}], $class, but the current pseudohash
implementation doesn't care if something is an object or not. It just
cares about either A) its type or B) what's in $ph-[0]. I don't know
if this is a good thing or a bad thing, but there's nothing on the
table to change it (yet).
my Dog $ph = [];
$ph-{this} = "that";
deparses at compile-time to:
my Dog $ph = [];
$ph-[$Dog::FIELDS{this}] = "that"; # actually the %FIELDS lookup is also
# done at compile time, but I left
# it in for illustration.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
- Unknown narrator speaking about Anime
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Wed, Sep 13, 2000 at 11:34:20PM -0700, Glenn Linderman wrote:
The rest is handled adequately and consistently today, and Tom's
dequote is adequate to eliminate leading white space... especially
among people who cannot agree that a tab in a file means "mod 8"
(which it does).
Damnit, I'm going to continue beating this horse until it stops twitching.
Tom and I had an extensive off-list discussion about this, and here's
about where it left off (hopefully I'll get everything right).
We have three major problems and three proposed solutions:
Problems:
1 Allowing here-docs to be indented without effecting the ouput.
2 Preserving sub-indentation.
3 Preserving the output of the here-doc regardless of how its
overall indentation is changed (ie. shifted left and right)
Solutions
1 POD =~ s/some_regex//
2 dequote(POD)
3 indentation of the end-tag
Each solution has their strengths and weaknesses. Regexes can handle
problem #1 but only #2 xor #3. However, they cover a wide variety of
more general problems. dequote has the same problem. #1 is fine, but
it can only do #2 xor #3. Not both.
The current stumper, which involves problems 1, 2 and 3 is this:
if( $is_fitting $is_just ) {
die POEM;
The old lie
Dulce et decorum est
Pro patria mori.
POEM
}
I propose that this work out to
"The old lie\n Dulce et decorum est\n Pro patria mori.\n"
and always work out to that, no matter how far left or right the
expression be indented.
{ { { { {
if( $is_fitting $is_just ) {
die POEM;
The old lie
Dulce et decorum est
Pro patria mori.
POEM
} } } } }
Four spaces, two spaces, six spaces. Makes sense, everything lines
up. So far I have yet to see a regex or dequote() style proposal
which can accomdate this.
So solution #1 is powerful, solution #2 is simple, solution #3 solves
a set of common problems which the others do not (but doesn't provide
the other's flexibility). All are orthoganal. All are fairly simple
and fairly obvious. Allow all three.
My most common case for needing indented here-docs is this:
{ { { { # I'm nested
if($error) {
warn "So there's this problem with the starboard warp coupling
and oh shit I just ran off the right margin.";
}
} } } }
Usually I wind up doing this:
{ { { { # I'm nested
if($error) {
warn "So there's this problem with the starboard ".
"warp coupling and oh shit I just ran off the ".
"right margin.";
}
} } } }
I'd love it if I could do this instead:
{ { { { # I'm nested
if($error) {
warn ERROR =~ s/\n/ /;
So there's this problem with the starboard warp
coupling and hey, now I have lots of room to
pummell you with technobabble!
ERROR
}
} } } }
By combining two of the solutions, my problem is solved. I can indent
my here-docs and yet keep the output a single line.
Show me where this fails and I'll shut up about it.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
- Unknown narrator speaking about Anime
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
I've implemented a prototype of the indented here-doc tag I'm proposing.
http://www.pobox.com/~schwern/src/RFC-Prototype-0.02.tar.gz
Its RFC::Prototype::111, which is probably the wrong number.
I'll have to add POD =~ s/// syntax. Also, if anyone's good with
filters I couldn't quite get the prototype working with
Filter::Util::Call. I found myself needing to work line-by-line, and
that whole "build up $_" was getting in my way, so I switched to
Filter::Util::Exec and it works, but it makes debugging really hard.
=head1 NAME
RFC::Prototype::111 - Implements Perl 6 RFC 111
=head1 SYNOPSIS
use RFC::Prototype::111;
if( $is_fitting $is_just ) {
die "POEM";
The old lie
Dulce et decorum est
pro patria mori
POEM
}
=head1 DESCRIPTION
Two changes.
1. Allows POD end tags to be indented. The amount of space a tag is
indented is the amount which will be clipped off of each line of
the here-doc. Tabs will BNOT be expanded.
2. POD end tags may now be followed by trailing whitespace
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
When faced with desperate circumstances, we must adapt.
- Seven of Nine
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Thu, Sep 14, 2000 at 11:49:18AM -0700, Glenn Linderman wrote:
I'm all for solving problems, and this message attempts to specify 3
problems, but it needs more specification. You describe three
problems, but it is not clear what the problems are
Since we've been charging back and forth over this ground like a troop
of doughboys over No Man's Land for the past month, I figured everyone
knew the problem and proposed solutions. Your review accuractely lays
everything out.
{ { { { {
if( $is_fitting $is_just ) {
die dequote_like('!', POEM);
!The old lie
! Dulce et decorum est
! Pro patria mori.
POEM
} # this } had been omitted
} } } } }
Things like this have come up, and to my eyes and fingers its
unacceptable. Some people like the explicit demarcation of the left
boundry, I find it ugly and don't like the extra typing. It doesn't
win me much over:
die
'The old lie'.
' Dulce et decorum est'.
' Pro patria mori.';
I'd prefer if here-docs just DWIM.
So we may want to add Yet Another problem. I forget what number you
got up to, but its basically "You shouldn't have to add anything but
whitespace to the here-doc for indenting".
An additional problem with dequote() style solutions is they are not
as efficient. DOC =~ s/// and the terminator indentation can both
be applied at compile time and deparse the whole mess into a simple
string (as the prototype does), while the dequote() routine must be
run over and over again at run-time. This can get nasty in hot loops.
#!/usr/bin/perl -w
use strict;
use Benchmark;
sub dequote_like {
local $_ = shift;
my ($leader); # common white space and common leading string
if (/^\s*(?:([^\w\s]+).*\n)(?:\s*\1.*\n)+$/) {
$leader = quotemeta($1);
} else {
$leader = '';
}
s/^\s*$leader//gm;
return $_;
}
my $foo;
timethese(shift || -3,
{
dequote = sub {
$foo = dequote_like('!', POEM);
!The old lie
! Dulce et decorum est
! Pro patria mori.
POEM
},
terminator = sub {
use RFC::Prototype::111;
$foo = "POEM";
The old lie
Dulce et decorum est
Pro patria mori.
POEM
},
});
Benchmark: running dequote, terminator, each for at least 3 CPU seconds...
dequote: 2 wallclock secs ( 3.00 usr + 0.01 sys = 3.01 CPU) @ 39857.81/s
(n=119972)
terminator: 3 wallclock secs ( 3.00 usr + 0.02 sys = 3.02 CPU) @ 268209.93/s
(n=809994)
dequote() comes out nearly seven times slower than the terminator
approach (which is basically dequote() vs a plain string).
So that's another problem to add to the list. "here-docs should be no
slower than the equivalent string, indented or otherwise"
The syntax for POEM =~ s/regex/subst/;
generally returns 1, and introducing a special case to make it
return the string if the left hand side is a here-doc seems to be a
pointless inconsistency.
I think its considered closer to the current trick of doing:
print ($var = POEM) =~ s/regex/subst/; # or something like that
Another suggestion was POEM =~ m/re(ge)x/. The match would be run
over each line and $1 used to generate the here-doc.
Honestly, I'm not really the one who should be evangelizing this
technique.
but these subs [dequote] work in perl 5 today, so don't really need
to be part of the RFC
They most definately do. If we're going to propose them as a solution
to the indented here-doc problem, it would be best to distribute a
collection of commonly used ones as a module with perl.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
slick and shiny crust
over my hairy anus
constipation sucks
-- Ken Flagg
Re: Drop here docs altogether? (was Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs))
On Thu, Sep 14, 2000 at 10:52:16AM -0700, Nathan Wiger wrote:
Before you scream "Bloody murder", please read on...
I'll wait patiently for the end...
if( $is_fitting $is_just ) {
die subst /\s{8}(.*?\n)/$1/g, qq/
The old lie
Dulce et decorum est
Pro patria mori.
/;
}
Seems to work for me (and yes I'm working on a prototype of RFC 164's
functions).
No, it still has all the problems of any other regex-based solution.
If you shift the code right or left, it breaks (due to the \s{8}) and
you're back to counting whitespace again. And as Glen pointed out,
what about that leading newline?
Can I scream now?
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
MORONS!
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Thu, Sep 14, 2000 at 02:51:14PM -0700, Glenn Linderman wrote: Michael G Schwern wrote: Well, OK, so now we're talking shades of opinion. You'd agree it works, though, and quite effectively. But you'd disagree about its aesthetics, and its performance. The former is much less interesting to me than the latter. Here-docs are all about aesthetics. Otherwise, we'd just be using regular strings. That's fair, except that they aren't equivalent: you'd need die 'The old lie'."\n". ' Dulce et decorum est'."\n". ' Pro patria mori.'."\n"; Just to be silly... die join "\n", 'The old lie', ' Dulce et decorum est', ' Pro patria mori.',''; Which is somewhat worse, compared to the here doc, even with "!" or other leading demarcation of choice (your choice, is, of course, none). They're all yicky. I'd prefer if here-docs just DWIM. Yes, but... what do you mean vs. what do others mean, and all these problems Others can continue to put the here-doc tag flush left if they don't want this behavior. I'd like to keep it clear that I consider all the proposals orthoganal, each solving a different (yet often overlapping) set of problems. This leads me down another path: wouldn't it be nice to have a function to interpolate a string on demand? Whoa! Hey, yes, great idea! Not so much for his problem, but I can definately see a need for anyone that's writing any sort of templating system. Then you could hoist the here-doc processing above out of the loop, and still get the effects of interpolation inside the loop, which would make the performance of here-doc postprocessing much less critical... but this means defining variables to hold the intermediate results, and moving the here-doc to a different location, which might not be as friendly to the understanding of the script. Right. Moving the text away from the point where it is used has maintenance problems. PS Do you use 132 columns to write mail? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC 226 (v1) Selective interpolation in single quotish context.
I have misgivings. I like single-quote context *because* you don't have to worry about anything magical (except ' and \). On Thu, Sep 14, 2000 at 09:52:12PM -, Perl6 RFC Librarian wrote: print F END; \$! \$! execute a.com, copy and purge \$! \$ \@sys\$login:a.com \$ copy $filename sys\$login:*.* \$ purge sys\$login:$filename \$! \$ exit END Personally, I'd solve this with sprintf(): print F sprintf 'END', $filename; $! $! execute a.com, copy and purge $! $ @sys$login:a.com $ copy %s sys$login:*.* $ purge sys$login:$filename $! $ exit but its not very idiomatic and YMMV. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I worship Satan and Santa likes me better than you. -- Diablo www.goats.com
Re: RFC 217 (v1) POD needs comment command. POD needs a reorder command.
On Wed, Sep 13, 2000 at 07:18:56AM -, Perl6 RFC Librarian wrote: =item Comment out documentation Sometimes I want a chunk of documentation to stick around but not be visible to the casual user. It may be tentative, half-baked, plain wrong, still in development, a comment about the docs. =for nobody Some POD POD readers will currently ignore =for and =begin/=end blocks with a name they don't recognize. =item Reorder the document Sometimes I want a chunk of documentation to hang out near a chunk of code, but the order of the code is not a good order for a man page. All right, so maybe this is really 2 proposals. This part... I regularly intersperse POD with code, and I've always found that where I want the docs is also where I want the code, but YMMV. So if one were to implement this, you could do: =for later blabitty blah ...later that same file... =print later The only change to POD would be to define a =print tag which takes the name of a =for/=being/=end block to output. Multiple blocks with the same name would be concatenated together and outputed as one chunk. =item Multiline comment for Perl I am not formally suggesting this as a multiline comment syntax. I already like Perl's current "multiline comment syntax" because it is so easy to edit-macro-ize. But I'd probably use it if it were there, cuz I am a bad, undisciplined programmer. How is this different than the current? =for comment a block of comments Personally, I've found M-x comment-region in emacs to be Good Enough and never had an urgent need for a multiline comment (but I've heard rumor that still people use lesser editors). The # syntax is simple and doesn't involve any of the nesting or accidentally run-on ambiguities of multi-line comments. Its also alot easier to parse. PS Keep in mind that =for can be replaced with =begin/=end in all cases. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse MORONS!
