[32326] in Perl-Users-Digest
Perl-Users Digest, Issue: 3593 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jan 18 14:14:24 2012
Date: Wed, 18 Jan 2012 11:14:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 18 Jan 2012 Volume: 11 Number: 3593
Today's topics:
Re: When is @_ undefined? (Tim McDaniel)
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Re: When is @_ undefined? (Tim McDaniel)
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Re: When is @_ undefined? (Tim McDaniel)
Re: When is @_ undefined? <NoSpamPleaseButThisIsValid3@gmx.net>
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? <ben@morrow.me.uk>
Re: When is @_ undefined? (Seymour J.)
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 17 Jan 2012 23:36:21 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: When is @_ undefined?
Message-Id: <jf50lk$ck7$1@reader1.panix.com>
In article <87aa5m3pua.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>tmcd@panix.com (Tim McDaniel) writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>>Ben Morrow <ben@morrow.me.uk> writes:
>
>[...]
>
>>>> ...no...? I don't understand what you're trying to say. AFAICS the
>>>> principle differences between
>>>>
>>>> sub doURI ($$$$$$$) {
>>>>
>>>> and
>>>>
>>>> sub doURI {
>>>> @_ == 7 or croak "doURI needs 7 arguments";
>>>>
>>>> are whether the check happens at compile- or runtime, whether it
>>>> has any weird effects on the contexts of the arguments, and whether
>>>> the programmer has any control over the error message.
>>>
>>>The main difference is that the runtime check needs to be coded
>>>explicitly.
>>
>> Hm, that's an interesting ambiguity in "needs" in English. If you
>> mean "the runtime check needs to be coded explicitly; in contrast, a
>> non-runtime check doesn't need to be coded explicitly", then I
>> consider "($$$$$$$)" to be an explicit coding,
>
>But it isn't. It's a declaration which modifies the behaviour of the
>compiler based on stating an intent ('When calling this subroutine,
>seven parameters have to be supplied
which is indeed an explicit coding that causes a check on the number
of arguments, along with the other effects you mentioned.
Unfortunately, in Perl 5, the prototype is not always obeyed (object
method calls, is that right?), which brings in my second
interpretation, "because of Perl 5's design, you need to code the
runtime check explicitly or you're in danger".
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 17 Jan 2012 15:44:40 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f15ddb8$4$fuzhry+tra$mr2ice@news.patriot.net>
In <87zkdm3ypw.fsf@sapphire.mobileactivedefense.com>, on 01/17/2012
at 07:39 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>That's obvious to you and you only because you wrote it.
It was obvious to me when I read it.
>And you can't have it both ways: Either, prototypes are bad
>because they can (among other things) enforce scalar context in a
>situation when the language defaults to list context. Then, they
>are always bad and not bad when someone else uses them to
>accomplish something different (call checking at compile time)
>and good when you use them to enforce scalar context.
I'm having trouble parsing what you wrote. What are the two ways that
you claim Ben wants it? To me he seemed to be saying that, like any
tool, prototypes should be used when they make things easier and not
used when they make things harder.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 17 Jan 2012 15:34:43 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f15db63$3$fuzhry+tra$mr2ice@news.patriot.net>
In <jf499l$88v$1@softins.clara.co.uk>, on 01/17/2012
at 04:57 PM, tony@mountifield.org (Tony Mountifield) said:
>When you call doURI, are any of the arguments themselves undefined or
>absent?
Yes, and I take different paths depending on which arguments are
present. In fact, the first thing after the debugging message is such
code:
if ($NumericDomain) {
my $intIP = $NumericDomain =~ /^0/o ? oct $NumericDomain :
$NumericDomain;
msg("\n\$host=$host, \$intIP=$intIP\n");
return if localIP($intIP);
$_ = inet_ntoa pack "N", $intIP;
$host="[$_]";
msg("\ndoURI \$host=$host\n");
return if ($host_info{$host}{URL}{$URI});
$host_info{$host}{URL}{$URI} = $rawhost;
msg("\nobfuscated host $rawhost is $host in $URI\n");
msg("\n\$URI \$host $URI at host $host\n");
push @{$host_info{$host}{msg}},
": spam site $URI is at host $host in your IP space.\n";
} else {
>You might also want to define doURI with a prototype:
>sub doURI($$$$$$$) {
> ...etc...
>}
That wouldn't help in this case, since some could be legitimately
undefined. What I need to do is to replaced undefined with null
string; something like
my @arglist=[];
for (@_) {push @arglist, $_ // ''}'
msg("\ndoURI(", join(', ',@arglist),")\n");
That hack should work, although there may be a cleaner way.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 17 Jan 2012 15:17:36 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f15d760$2$fuzhry+tra$mr2ice@news.patriot.net>
In <msjgu8-hor1.ln1@anubis.morrow.me.uk>, on 01/17/2012
at 04:23 PM, Ben Morrow <ben@morrow.me.uk> said:
>This may seem like a silly question, but what do you get if you add
> defined $_[$_] or warn "\$_[$_] undefined!"
> for 0..$#_;
>at this point?
After reading Willem's article, I would expect that one of them is
undefined.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Tue, 17 Jan 2012 15:15:23 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f15d6db$1$fuzhry+tra$mr2ice@news.patriot.net>
In <slrnjhb7fg.11o1.willem@toad.stack.nl>, on 01/17/2012
at 04:12 PM, Willem <willem@toad.stack.nl> said:
>I guess you called 'doUri' with too few arguments, or with an undef
>argument.
That makes sense.
>Why do you say the value was changed?
I read it as saying that @_ was undefined. They say that the mind is
the second thing to go. Thanks.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 18 Jan 2012 01:48:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <q0lhu8-5g22.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
>
> Unfortunately, in Perl 5, the prototype is not always obeyed (object
> method calls, is that right?),
Yes, that's right: method calls don't honour prototypes. They can't, in
fact, since it isn't known at compile time which method will be called.
> which brings in my second
> interpretation, "because of Perl 5's design, you need to code the
> runtime check explicitly or you're in danger".
...and I hadn't even remembered that as a disadvantage of prototypes :).
However, c.f. Method::Signatures, again.
Ben
------------------------------
Date: Wed, 18 Jan 2012 01:59:03 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <7klhu8-5g22.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>
> That wouldn't help in this case, since some could be legitimately
> undefined. What I need to do is to replaced undefined with null
> string; something like
>
> my @arglist=[];
This doesn't do what you think it does...
> for (@_) {push @arglist, $_ // ''}'
> msg("\ndoURI(", join(', ',@arglist),")\n");
>
> That hack should work, although there may be a cleaner way.
Write it as
my @arglist = map $_ // '', @_;
and I wouldn't even call it a hack. Of course, if you only need this for
the msg() you can do it inline:
msg("\ndoURI(", join(", ", map($_ // "", @_)), ")\n");
or just
{
no warnings "uninitialized";
msg(...);
}
(I must admit I tend to leave warnings "uninitialized" off a lot of the
time. I find the warnings more irritating than helpful. (I also find it
irritating that 'uninitialized' is so long, has so many 'iX'
combinations, and has an s/z I have to think about every time... I
would've called it no warnings "undef".))
Ben
------------------------------
Date: Wed, 18 Jan 2012 02:25:17 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <8762g9u4qa.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>tmcd@panix.com (Tim McDaniel) writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>>>Ben Morrow <ben@morrow.me.uk> writes:
>>
>>[...]
>>
>>>>> ...no...? I don't understand what you're trying to say. AFAICS the
>>>>> principle differences between
>>>>>
>>>>> sub doURI ($$$$$$$) {
>>>>>
>>>>> and
>>>>>
>>>>> sub doURI {
>>>>> @_ == 7 or croak "doURI needs 7 arguments";
>>>>>
>>>>> are whether the check happens at compile- or runtime, whether it
>>>>> has any weird effects on the contexts of the arguments, and whether
>>>>> the programmer has any control over the error message.
>>>>
>>>>The main difference is that the runtime check needs to be coded
>>>>explicitly.
>>>
>>> Hm, that's an interesting ambiguity in "needs" in English. If you
>>> mean "the runtime check needs to be coded explicitly; in contrast, a
>>> non-runtime check doesn't need to be coded explicitly", then I
>>> consider "($$$$$$$)" to be an explicit coding,
>>
>>But it isn't. It's a declaration which modifies the behaviour of the
>>compiler based on stating an intent ('When calling this subroutine,
>>seven parameters have to be supplied
>
> which is indeed an explicit coding that causes a check on the number
> of arguments, along with the other effects you mentioned.
The difference is that the declaration is used to _declare_ a piece of
information about the code and this causes the compiler to perform an
action with a specific effect in an unspecified way while otherwise,
code needs to be written which performs an action supposed to have the
indended effect in some specific way.
> Unfortunately, in Perl 5, the prototype is not always obeyed (object
> method calls, is that right?), which brings in my second
> interpretation, "because of Perl 5's design, you need to code the
> runtime check explicitly or you're in danger".
Because of the design of Perl 5, overloaded methods need not have
identical signatures: A method is called by looking for a particular
symbol in some set of packages and the first subroutine found by this
search is expected to do 'something' with the arguments passed to it
in some 'sensible way'. This is actually much more 'object oriented'
than C++ because it amounts to sending a message and some arguments to
an object and it is up to the sole discretion of the object how to
react to this message with this particular set of arguments,
completely independentely of the behaviour of any base classes of this
object: Inheritance can be used for code reuse where this makes sense
but it doesn't imply mandatory design reuse.
The Perl object system is actually one of those things which make perl
a great language.
------------------------------
Date: Wed, 18 Jan 2012 05:31:05 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: When is @_ undefined?
Message-Id: <jf5lep$e9d$1@reader1.panix.com>
In article <q0lhu8-5g22.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>>
>> Unfortunately, in Perl 5, the prototype is not always obeyed
>> (object method calls, is that right?),
>
>Yes, that's right: method calls don't honour prototypes. They can't,
>in fact, since it isn't known at compile time which method will be
>called.
Just off the top of my head, you'd have to accomodate any possible
signature at compile time, which sounds ugly and/or difficult. ...
hmm, except that the callee already can take advantage of aliasing
provided by @_, so at least some caller info is being passed ...
Anyone know offhand how Perl 6 handles/will handle it?
>However, c.f. Method::Signatures, again.
Thank you for the reference.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 18 Jan 2012 14:42:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <mb2ju8-1sc2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <q0lhu8-5g22.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth tmcd@panix.com:
> >>
> >> Unfortunately, in Perl 5, the prototype is not always obeyed
> >> (object method calls, is that right?),
> >
> >Yes, that's right: method calls don't honour prototypes. They can't,
> >in fact, since it isn't known at compile time which method will be
> >called.
>
> Just off the top of my head, you'd have to accomodate any possible
> signature at compile time, which sounds ugly and/or difficult. ...
It's impossible. Given a call like
my $o = build_an_object();
my @x;
$o->method(@x, 1, 2, 3);
you'd need to know when that method call is compiled whether ->method is
prototyped (\@@) or not (at least). Since you don't even know what class
$o is in at compile time, there's no way to find out.
> hmm, except that the callee already can take advantage of aliasing
> provided by @_, so at least some caller info is being passed ...
I'm not sure what you mean here. Turning the callee's @_ into an alias
for its arguments happens at runtime, after method resolution has been
done and we know which method we're calling.
> Anyone know offhand how Perl 6 handles/will handle it?
Perl 6 has a (rather flexible, and mostly optional) static type system.
This means that in the example above perl would be able to infer from
build_an_object's signature that it would return an object of class Foo,
and from that would get some information about Foo->method's signature.
However, I don't think there is anything like Perl 5 prototypes in any
case. Something like push, which was effectively equivalent to
sub push (\@@) {...}
in Perl 5, is written
Array multi method push (@array: *@values) {...}
in Perl 6, which, among other things, makes it effectively a method call
on @array. (Don't ask me to explain it any further, though, since I
don't really understand Perl 6 yet...)
Ben
------------------------------
Date: Wed, 18 Jan 2012 16:23:30 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <8762g9asjh.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth tmcd@panix.com:
>> In article <q0lhu8-5g22.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >
>> >Quoth tmcd@panix.com:
>> >>
>> >> Unfortunately, in Perl 5, the prototype is not always obeyed
>> >> (object method calls, is that right?),
>> >
>> >Yes, that's right: method calls don't honour prototypes. They can't,
>> >in fact, since it isn't known at compile time which method will be
>> >called.
>>
>> Just off the top of my head, you'd have to accomodate any possible
>> signature at compile time, which sounds ugly and/or difficult. ...
>
> It's impossible. Given a call like
>
> my $o = build_an_object();
> my @x;
> $o->method(@x, 1, 2, 3);
>
> you'd need to know when that method call is compiled whether ->method is
> prototyped (\@@) or not (at least). Since you don't even know what class
> $o is in at compile time, there's no way to find out.
It is entirely conceivable that no applicable subroutine exists
anywhere by the time the code is compiled, the most straight-forward
example being that methods are generated on demand via AUTOLOAD[*]
and even if it exists it could be changed at any later time. It is
also possible that no subroutine with the name in question will ever
exist.
Somewhat stupid example
------------------------
package Messenger;
sub new
{
my $self;
return bless(\$self, $_[0]);
}
sub AUTOLOAD
{
our $AUTOLOAD;
my $tag;
($tag) = $AUTOLOAD =~ /([^:]*$)/;
return if $tag eq 'DESTROY';
shift;
print STDERR ($tag, ":\t", @_, "\n");
}
package main;
my $m = new Messenger;
$m->urgent('cut the crap');
$m->afterwards('meet at the concrete doughnut ...');
----------------------
[*] Whoever might feel inclined to cry something like "But
J. Random Windows Loser has outlawed that in 2005 !!1' is
hereby requested to shout out of the nearest window instead.
I don't care what features of Perl you, your idols, your
grandma, your girl friend or the random guy from Belfast
really *hate* if they are useful to me.
------------------------------
Date: Wed, 18 Jan 2012 17:15:51 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: When is @_ undefined?
Message-Id: <jf6uo7$c9u$1@reader1.panix.com>
In article <mb2ju8-1sc2.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <q0lhu8-5g22.ln1@anubis.morrow.me.uk>,
>> Ben Morrow <ben@morrow.me.uk> wrote:
>> >
>> >Quoth tmcd@panix.com:
>> >>
>> >> Unfortunately, in Perl 5, the prototype is not always obeyed
>> >> (object method calls, is that right?),
>> >
>> >Yes, that's right: method calls don't honour prototypes. They can't,
>> >in fact, since it isn't known at compile time which method will be
>> >called.
>>
>> Just off the top of my head, you'd have to accomodate any possible
>> signature at compile time, which sounds ugly and/or difficult. ...
>> hmm, except that the callee already can take advantage of aliasing
>> provided by @_, so at least some caller info is being passed ...
>
>I'm not sure what you mean here.
Just groping towards notions relating to Perl not doing a simple
pass-by-value as in C, but is passing references behind the scenes at
the least, and therefore could conceivably pass more info as needed.
>It's impossible.
Well, it's not *impossible*, but in the worst case in Perl 5, you'd
have to eval the call at runtime!
My first thought was that, at a minimum, you'd have to pass more data
and make some decisions at run time that would normally be done at
compile time. In your example of
> $o->method(@x, 1, 2, 3);
>
>you'd need to know when that method call is compiled whether ->method
>is prototyped (\@@) or not (at least).
for example, it would have to pass a reference to @x as an item to be
able to implement (\@@), but still know to dereference it if it's (@).
Since it's already passing references to each element of @x so as to
implement mutability of @_, that doesn't seem a barrier.
Then I realized a more fundamental problem: parsing. In Perl 5, a sub
prototype affects the parsing of the statement: "," can be either the
comma operator or a list separator depending on the context.
#! /usr/bin/perl
use strict;
use warnings;
sub proto($) { return "(", join(";", @_), ")"; }
sub notproto { return "(", join(";", @_), ")"; }
print proto 3, 5, "\n";
print notproto 9, 11, "\n";
print "*\n";
exit 0;
outputs
(3)5
(9;11;
)*
That is, proto eats only the argument 3, but notproto eats all the
arguments after, including the newline.
If "," were unambiguous in Perl 5 -- either by requiring parens in all
sub calls, or by making an invariant interpretation of "," when there
were no parens -- then not knowing the prototype at compile time could
have been handled at run time. TOo late for that.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 18 Jan 2012 18:37:17 +0100
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: When is @_ undefined?
Message-Id: <4f17034e$0$6634$9b4e6d93@newsspool2.arcor-online.net>
Am 18.01.2012 18:15, schrieb Tim McDaniel:
> Just groping towards notions relating to Perl not doing a simple
> pass-by-value as in C, but is passing references behind the scenes at
> the least, and therefore could conceivably pass more info as needed.
Well, a "simple pass-by-value" might not really be simple. Look at C++
when passing an object by value. You (or the compiler) will then need to
copy-construct it and you somehow need do decide if you want a deep copy
or or a shallow copy. "Simple" pass-by-value only works for "simple" types.
Wolf
------------------------------
Date: Wed, 18 Jan 2012 09:36:45 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f16d8fd$6$fuzhry+tra$mr2ice@news.patriot.net>
In <7klhu8-5g22.ln1@anubis.morrow.me.uk>, on 01/18/2012
at 01:59 AM, Ben Morrow <ben@morrow.me.uk> said:
>This doesn't do what you think it does...
Okay. Does this work?
my @arglist=();
>Write it as
> my @arglist = map $_ // '', @_;
Thanks.
>I find the warnings more irritating than helpful.
I find that if I already no that there's a problem, the warnings of
uninitialized variables sometimes help me to find it. Where there's a
clean way to avoid irrelevant warnings, I'll do it to avoid clutter.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 18 Jan 2012 17:56:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <mmdju8-fme2.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <mb2ju8-1sc2.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >
> >Quoth tmcd@panix.com:
> >>
> >> Just off the top of my head, you'd have to accomodate any possible
> >> signature at compile time, which sounds ugly and/or difficult. ...
> >> hmm, except that the callee already can take advantage of aliasing
> >> provided by @_, so at least some caller info is being passed ...
> >
> >I'm not sure what you mean here.
>
> Just groping towards notions relating to Perl not doing a simple
> pass-by-value as in C, but is passing references behind the scenes at
> the least, and therefore could conceivably pass more info as needed.
That's a good point, and that's a concept that IIRC's been picked up in
Perl 6. They have the notion of a 'Capture', which is a list of
arguments like (@x, 1, 2, 3), stored in such a way as it can be
decomposed into a single list or something else as appropriate later.
> >It's impossible.
>
> Well, it's not *impossible*, but in the worst case in Perl 5, you'd
> have to eval the call at runtime!
OK, not 'impossible'. 'Not possible without redesigning how Perl does
sub and method calls' might be closer...
> My first thought was that, at a minimum, you'd have to pass more data
> and make some decisions at run time that would normally be done at
> compile time. In your example of
>
> > $o->method(@x, 1, 2, 3);
> >
> >you'd need to know when that method call is compiled whether ->method
> >is prototyped (\@@) or not (at least).
>
> for example, it would have to pass a reference to @x as an item to be
> able to implement (\@@), but still know to dereference it if it's (@).
> Since it's already passing references to each element of @x so as to
> implement mutability of @_, that doesn't seem a barrier.
>
> Then I realized a more fundamental problem: parsing. In Perl 5, a sub
> prototype affects the parsing of the statement: "," can be either the
> comma operator or a list separator depending on the context.
No, a comma is always the comma operator. In list context it builds a
list, in scalar context it returns it's RH argument. It's not
fundamentally different from any other operator with list and scalar
versions, as you can see from
sub foo {
return 1, 2, 3;
}
say foo;
say scalar foo;
At the point where that sub was compiled, perl knew it had a comma
operator but not what context it was in. At runtime it applied the
context appropriately and gave the right result.
> #! /usr/bin/perl
> use strict;
> use warnings;
> sub proto($) { return "(", join(";", @_), ")"; }
> sub notproto { return "(", join(";", @_), ")"; }
> print proto 3, 5, "\n";
> print notproto 9, 11, "\n";
> print "*\n";
> exit 0;
>
> outputs
>
> (3)5
> (9;11;
> )*
>
> That is, proto eats only the argument 3, but notproto eats all the
> arguments after, including the newline.
Yes, the difference here is one of precedence.
proto 3, 5, "\n"; => (proto(3), 5, "\n");
noproto 3, 5, "\n"; => noproto(3, 5, "\n");
> If "," were unambiguous in Perl 5 -- either by requiring parens in all
> sub calls, or by making an invariant interpretation of "," when there
> were no parens -- then not knowing the prototype at compile time could
> have been handled at run time. TOo late for that.
But that *is* already the case for methods. Setting aside the dative
call syntax (new Foo 1, 2, 3) since it has parsing problems anyway, a
method call is always one of
$o->proto(3), 5, "\n";
$o->noproto(3, 5, "\n");
with no ambiguity about which arguments go to the method and which
don't. This would mean deferring the prototype check to runtime, of
course, at which point we're back to there being very little advantage
of ($$$$$$$) over '@_ == 7 or die'.
Ben
------------------------------
Date: Wed, 18 Jan 2012 13:01:30 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: When is @_ undefined?
Message-Id: <4f1708fa$1$fuzhry+tra$mr2ice@news.patriot.net>
In <7klhu8-5g22.ln1@anubis.morrow.me.uk>, on 01/18/2012
at 01:59 AM, Ben Morrow <ben@morrow.me.uk> said:
>This doesn't do what you think it does...
Okay. Does this work?
my @arglist=();
>Write it as
> my @arglist = map $_ // '', @_;
Thanks.
>I find the warnings more irritating than helpful.
I find that if I already no that there's a problem, the warnings of
uninitialized variables sometimes help me to find it. Where there's a
clean way to avoid irrelevant warnings, I'll do it to avoid clutter.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 18 Jan 2012 18:13:46 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <87k44oanfp.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> The Perl object system is actually one of those things which make perl
> a great language.
A small, practical demonstration of that: I have a small Perl script
here which is used to put a certificate and corresponding private into
a database table after performing some sanity checks on them (ie,
checking that the moduli of certificate and key are identical). Since
the Perl OpenSSL modules are too incomplete to be used for that, all
'certificate operations' are performed by invoking the openssl command
line tool with its output going to a pipe and its input coming from a
temporary file. Because more than one operation is performed with this
file, I want to write it only once. Further, I don't want to keep the
file name around in the filesystem but want it to be removed as soon
as the file has been opened so that it goes away automatically when
the script exists (or the filehandle of the temp file is
destroyed). In order to use it as input to openssl, it must
nevertheless be possible to access this file by name. On Linux, provided the
file descriptor number referring to this file is known, this can be
done by opening the path
/proc/<pid>/fd/<fd>
with <pid> being the process id of a process which has access to the
file descriptor and <fd> being the file descriptor number. Lastly, I
want 'something' I can pass around as argument which both causes the
file to remain open while it exists and provides easy access to the
corresponding /proc path name.
In Perl, a file handle is usually a glob reference and since this is a
reference, it can be blessed into a package in order to become an
object. Access the the /proc-name can then be provided by overloading
the 'stringification' operation for this package. As code, this looks
like this ((c) my employer, quoted for educational purposes):
---------
package TempFile;
use File::Temp qw(tempfile);
use overload '""' => \&fd_name_of;
use constant FD_NAME_TMPL => '/proc/%u/fd/%u';
sub fd_name_of
{
return sprintf(FD_NAME_TMPL, $$, fileno($_[0]));
}
sub new
{
my ($fh, $fn, $rc);
$fh = tempfile();
$rc = syswrite($fh, $_[1]);
$rc // die("syswrite: $!");
$rc == length($_[1]) || die("short write");
return bless($fh, $_[0]);
}
----------
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3593
***************************************
