[32222] in Perl-Users-Digest
Perl-Users Digest, Issue: 3487 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 1 21:09:26 2011
Date: Thu, 1 Sep 2011 18:09:07 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 1 Sep 2011 Volume: 11 Number: 3487
Today's topics:
Re: Generating functions with Macros in Perl <kebabklubben.emp@gmail.com>
Re: Generating functions with Macros in Perl <rvtol+usenet@xs4all.nl>
Re: Generating functions with Macros in Perl <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Generating functions with Macros in Perl <bugbear@trim_papermule.co.uk_trim>
Re: Generating functions with Macros in Perl <jurgenex@hotmail.com>
Hey who here read modern perl? What do you think? aweso <gavcomedy@gmail.com>
Re: Why does sort return undef in scalar context ? (Alan Curry)
Re: Why does sort return undef in scalar context ? <rvtol+usenet@xs4all.nl>
Re: Why does sort return undef in scalar context ? <tzz@lifelogs.com>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? <rweikusat@mssgmbh.com>
Re: Why does sort return undef in scalar context ? (David Canzi)
Re: Why does sort return undef in scalar context ? <willem@toad.stack.nl>
Re: Why does sort return undef in scalar context ? (Alan Curry)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 1 Sep 2011 04:09:27 -0700 (PDT)
From: Andreas Lundgren <kebabklubben.emp@gmail.com>
Subject: Re: Generating functions with Macros in Perl
Message-Id: <f8da98a3-a15c-4ba0-b9e6-074473ae72fd@n35g2000yqf.googlegroups.com>
> print $addTwo->(5), "\n"; #prints 7
> print $addFour->(5), "\n"; #prints 9
Hi!
This is a way to get close, but I would need generate a real function
in runtime. Something called exactly like a function. I guess that a
pre processor is needed in order to first generate code before
executing the code... Is there no such thing in Perl?
BR,
Andreas
------------------------------
Date: Thu, 01 Sep 2011 13:40:59 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Generating functions with Macros in Perl
Message-Id: <4e5f6f4b$0$2411$e4fe514c@news2.news.xs4all.nl>
On 2011-09-01 13:09, Andreas Lundgren wrote:
> ATTRIBUTION DAMMIT - Wolf wrote:
>> print $addTwo->(5), "\n"; #prints 7
>> print $addFour->(5), "\n"; #prints 9
>
> This is a way to get close, but I would need generate a real function
> in runtime. Something called exactly like a function. I guess that a
> pre processor is needed in order to first generate code before
> executing the code... Is there no such thing in Perl?
Explore Perl's compile phase. Plenty support for lambda there.
--
Ruud
------------------------------
Date: Thu, 01 Sep 2011 13:47:26 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: Generating functions with Macros in Perl
Message-Id: <4e5f70cf$0$6556$9b4e6d93@newsspool4.arcor-online.net>
Am 01.09.2011 13:09, schrieb Andreas Lundgren:
>> print $addTwo->(5), "\n"; #prints 7
>> print $addFour->(5), "\n"; #prints 9
>
> Hi!
>
> This is a way to get close, but I would need generate a real function
> in runtime. Something called exactly like a function.
Why? What is the problem with calling it the way I have shown? It is a
"real" function. Just that you have a ref to it in a scalar variable.
> I guess that a
> pre processor is needed in order to first generate code before
> executing the code... Is there no such thing in Perl?
Again, why do you want that?
You could do:
*addTwo = \&$addTwo;
and then call addTwo(2). But still, what is wrong with calling a coderef
with $coderef->();
- Wolf
------------------------------
Date: Thu, 01 Sep 2011 12:48:50 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Generating functions with Macros in Perl
Message-Id: <_YWdnQ5Xp6G-7MLTnZ2dnUVZ8mCdnZ2d@brightview.co.uk>
Andreas Lundgren wrote:
>> print $addTwo->(5), "\n"; #prints 7
>> print $addFour->(5), "\n"; #prints 9
>
> Hi!
>
> This is a way to get close, but I would need generate a real function
> in runtime. Something called exactly like a function. I guess that a
> pre processor is needed in order to first generate code before
> executing the code... Is there no such thing in Perl?
You can put Andreas's functions into the global symbol table
if that's what you want.
BugBear
------------------------------
Date: Thu, 01 Sep 2011 07:09:03 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Generating functions with Macros in Perl
Message-Id: <ge4v57ti4ok14p2etar45h841uh4eh14n5@4ax.com>
Andreas Lundgren <kebabklubben.emp@gmail.com> wrote:
>> print $addTwo->(5), "\n"; #prints 7
>> print $addFour->(5), "\n"; #prints 9
>
>This is a way to get close, but I would need generate a real function
>in runtime. Something called exactly like a function. I guess that a
>pre processor is needed in order to first generate code before
>executing the code... Is there no such thing in Perl?
Maybe you are looking for something as simple as eval()?
jue
------------------------------
Date: Wed, 31 Aug 2011 21:38:56 -0700 (PDT)
From: gavino <gavcomedy@gmail.com>
Subject: Hey who here read modern perl? What do you think? awesome?
Message-Id: <175cb697-74ad-4325-b04e-2d5d28462c49@glegroupsg2000goo.googlegroups.com>
curious?
http://www.onyxneon.com/books/modern_perl/index.html
------------------------------
Date: Wed, 31 Aug 2011 22:08:09 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3mbc9$f8p$1@speranza.aioe.org>
In article <86hb4xn3ne.fsf@red.stonehenge.com>,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>
>The only serious proposals for scalar sort that I've seen are (a) a
>boolean to say "yes, this list is already sorted", or perhaps (b) a
>value between 0 and 1 as to "how sorted" the list already was, based on
>a single pass of the sort comparator against adjacent elements. Not
>sure when I would have used either one though.
In void context:
sort @foo;
the obvious intent is to sort the array in place. It could even apply to
arbitrary lists:
sort $x, $y; # Equivalent to: ($x,$y) = ($y,$x) if $x gt $y
Apply the same rule in non-void scalar context, but add: returns true if the
list was changed.
if(sort $x, $y) {
# redisplay the user interface elements that depend on $x and/or $y
}
Trying to decide on a scale of 0 to 1 "how serious" I am...
--
Alan Curry
------------------------------
Date: Thu, 01 Sep 2011 12:31:39 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <4e5f5f0a$0$2504$e4fe514c@news2.news.xs4all.nl>
On 2011-09-01 00:08, Alan Curry wrote:
> Randal L. Schwartz:
>> The only serious proposals for scalar sort that I've seen are (a) a
>> boolean to say "yes, this list is already sorted", or perhaps (b) a
>> value between 0 and 1 as to "how sorted" the list already was, based on
>> a single pass of the sort comparator against adjacent elements. Not
>> sure when I would have used either one though.
>
> In void context:
>
> sort @foo;
>
> the obvious intent is to sort the array in place. It could even apply to
> arbitrary lists:
>
> sort $x, $y; # Equivalent to: ($x,$y) = ($y,$x) if $x gt $y
>
> Apply the same rule in non-void scalar context, but add: returns true if the
> list was changed.
>
> if(sort $x, $y) {
> # redisplay the user interface elements that depend on $x and/or $y
> }
>
> Trying to decide on a scale of 0 to 1 "how serious" I am...
One obvious thing to return in scalar context, is the last element of
the sorted list.
That can also be done by: @foo ? (sort {...} @foo)[-1] : undef.
It can be used to implement max() and min(), but I have not met similar
code much, so I consider it a waste to make it so.
--
Ruud
------------------------------
Date: Thu, 01 Sep 2011 06:19:42 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <874o0wldbl.fsf@lifelogs.com>
On Wed, 31 Aug 2011 05:53:25 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
RLS> The only serious proposals for scalar sort that I've seen are (a) a
RLS> boolean to say "yes, this list is already sorted", or perhaps (b) a
RLS> value between 0 and 1 as to "how sorted" the list already was, based on
RLS> a single pass of the sort comparator against adjacent elements. Not
RLS> sure when I would have used either one though.
RLS> if (sort { $a <=> $b } @list) { # this is already numerically sorted
RLS> ...
RLS> }
I don't like it, because it differentiates between
$x = scalar sort @y;
and
@x = sort @y;
$x = scalar @x;
I don't see any practical gain from the first one, so why break
transitivity? To add yet more syntactic sugar we don't need, perhaps
good for Perl golfing but discouraged in production code?
Much better would be to provide a sorted-p predicate that can be used
generally without forcing a scalar context, and with a clear purpose.
That would actually be useful and can't be done as easily or as
efficiently in pure Perl as it would be on the interpreter side.
Fractional degrees of sort order are perhaps useful but they are much
more expensive to calculate.
Ted
------------------------------
Date: Thu, 01 Sep 2011 13:58:41 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <877h5ss9ku.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
[...]
> ) Errr, having sort() return the number of elements is overloading
> ) it to do something *not related* but different.
>
> I have already explained why this is false.
> Simply restating it is not going to make it any less false.
>
> Having sort() return the number of elements is logical and
> consistent. See the arguments I presented crossthread, none of which
> have been refuted (only blatantly dismissed).
You claimed that the sort routine would take an array as input and
return an array as output. This is wrong. Sort takes a list as input
and returns a list as ouput. Evaluating a list in scalar context
returns the last element of the list, NOT the number of members.
Besides being wrong, this is also besides the point: You expect that
sort behaves as if it was context-agnostic but it isn't: The behaviour
of sort in a scalar context is whatever the person who implemented it
considered sensible. And it is not sensible to expect a subroutine
whose purpose is to create a permutation of its inputs to count these
inputs instead. That's a completely arbitrary descisions which has no
inherent relation to the purpose of the routine: It's just based on
your original misassumption that sort would return an array and your
desire that this sort-returning-an-array which doesn't exist should
also be context-agnostic.
> To hammer in the last nail: It works exactly that way in Perl6.
So fucking what?
------------------------------
Date: Thu, 01 Sep 2011 14:54:13 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87vctcqsfu.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Willem <willem@toad.stack.nl> writes:
>
> [...]
>
>> ) Errr, having sort() return the number of elements is overloading
>> ) it to do something *not related* but different.
>>
>> I have already explained why this is false.
>> Simply restating it is not going to make it any less false.
>>
>> Having sort() return the number of elements is logical and
>> consistent. See the arguments I presented crossthread, none of which
>> have been refuted (only blatantly dismissed).
>
> You claimed that the sort routine would take an array as input and
> return an array as output. This is wrong. Sort takes a list as input
> and returns a list as ouput.
Addition: Provided that sort got a list as input, the implementation
actually sorts (as far as I understood it from a fairly cursory look
at it) the contents of the call stack in place and 'returns' the
sorted stack contents as output list. The closest simple approxmiation
to that in Perl (AFAIK) looks like this:
sub agnostic_sort
{
return eval('('.join(',', sort(@_)).')');
}
------------------------------
Date: Thu, 1 Sep 2011 19:44:14 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5vo4e.1otl.willem@toad.stack.nl>
Rainer Weikusat wrote:
) Willem <willem@toad.stack.nl> writes:
)
) [...]
)
)> ) Errr, having sort() return the number of elements is overloading
)> ) it to do something *not related* but different.
)>
)> I have already explained why this is false.
)> Simply restating it is not going to make it any less false.
)>
)> Having sort() return the number of elements is logical and
)> consistent. See the arguments I presented crossthread, none of which
)> have been refuted (only blatantly dismissed).
)
) You claimed that the sort routine would take an array as input and
) return an array as output. This is wrong.
I claimed that the sort routine *conceptually* is a function from arrays
to arrays. This is correct.
) Sort takes a list as input
) and returns a list as ouput. Evaluating a list in scalar context
) returns the last element of the list, NOT the number of members.
Can you show a piece of perl code that 'evaluates a list in scalar
context', but without using a comma to build the list?
If not, then one could just as well say that the comma operator returns
the concatenation of its operands in list context, and the rightmost
operand in scalar context, and the whole concept of 'evaluating a list
in scalar context' can be dropped altogether.
As you argue below, this is irrelevant because functions are aware
of the context they are in. Several functions that return lists
will return the list count in scalar context. I don't know a single
one that will return the last item of the list.
All this is evidence that it is quite sensible to expect a function
that returns a list, to return an item count in scalar context.
) Besides being wrong, this is also besides the point: You expect that
) sort behaves as if it was context-agnostic but it isn't:
I am trying to argue that sort *should* behave as if it was
context-agnostic, because that is the most sensible option.
The person implementing it did not find *any* sensible scalar
to return, and therefore decided to return nothing.
) of sort in a scalar context is whatever the person who implemented it
) considered sensible. And it is not sensible to expect a subroutine
) whose purpose is to create a permutation of its inputs to count these
) inputs instead.
I am trying to argue that it *is* sensible to expect that. Simply claiming
the opposite of that fact does nothing to further the discussion.
To reiterate: I am trying to have a theoretical discussion on the merits of
having sort return an item count in scalar context.
)> To hammer in the last nail: It works exactly that way in Perl6.
)
) So fucking what?
Apparently nothing to people who are stuck programming in one language.
Those of us who use multiple languages have higher expectations.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 01 Sep 2011 21:19:18 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <87ippcqam1.fsf@sapphire.mobileactivedefense.com>
Willem <willem@toad.stack.nl> writes:
> Rainer Weikusat wrote:
> ) Willem <willem@toad.stack.nl> writes:
> )
> ) [...]
> )
> )> ) Errr, having sort() return the number of elements is overloading
> )> ) it to do something *not related* but different.
> )>
> )> I have already explained why this is false.
> )> Simply restating it is not going to make it any less false.
> )>
> )> Having sort() return the number of elements is logical and
> )> consistent. See the arguments I presented crossthread, none of which
> )> have been refuted (only blatantly dismissed).
> )
> ) You claimed that the sort routine would take an array as input and
> ) return an array as output. This is wrong.
>
> I claimed that the sort routine *conceptually* is a function from arrays
> to arrays. This is correct.
The perl sort is defined based on lists.
> ) Sort takes a list as input) and returns a list as
> ouput. Evaluating a list in scalar context) returns the last element
> of the list, NOT the number of members.
>
> Can you show a piece of perl code that 'evaluates a list in scalar
> context', but without using a comma to build the list?
>
> If not, then one could just as well say that the comma operator returns
> the concatenation of its operands in list context, and the rightmost
> operand in scalar context, and the whole concept of 'evaluating a list
> in scalar context' can be dropped altogether.
No, it can't, because, again, the 'theoretical model' you like to use
here is in conflict with the Perl documentation:
List value constructors
List values are denoted by separating individual values by
commas (and enclosing the list in parentheses where precedence
requires it):
(LIST)
In a context not requiring a list value, the value of what
appears to be a list literal is simply the value of the final
element, as with the C comma operator. For example,
@foo = ('cc', '-E', $bar);
assigns the entire list value to array @foo, but
$foo = ('cc', '-E', $bar);
assigns the value of variable $bar to the scalar variable $foo.
[perldata(1)]
> As you argue below, this is irrelevant because functions are aware
> of the context they are in. Several functions that return lists
> will return the list count in scalar context.
Several functions which *happen* to generate an output list from an
input list where the number of elements on the output list cannot be
predicted without performing the operation on the input list return
this number when used in scalar context. The sort operation does not
have this property: Since it permutes the elements from the input
list, the number of elements of the output list is identical to the
number of elements on the input list.
[...]
> ) Besides being wrong, this is also besides the point: You expect that
> ) sort behaves as if it was context-agnostic but it isn't:
>
> I am trying to argue that sort *should* behave as if it was
> context-agnostic, because that is the most sensible option.
That's the most sensible option FOR YOU because you happen to have
written some code based on the assumption that sort would behave in
this way despite it actually doesn't.
------------------------------
Date: Thu, 1 Sep 2011 20:23:34 +0000 (UTC)
From: dmcanzi@remulak.uwaterloo.ca (David Canzi)
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3opk6$hh8$1@rumours.uwaterloo.ca>
Willem <willem@toad.stack.nl> wrote:
>Jim Gibson wrote:
>) I do not think that your use case is valid. It is silly to sort an
>) array when all you want is the number of elements in the array. The
>) subroutine that you wrote to do this is not a good example of good
>) design. That could be why nobody on this groups agrees that what you
>) want is desirable.
>
>Well, the fact that you call it a subroutine, and not a function, clearly
>shows that you're stuck in the old perl4 days.
Script started on Thu Sep 1 16:19:13 2011
dmcanzi@tribulation $
dmcanzi@tribulation $ perl -e 'print $^V, "\n"'
v5.10.1
dmcanzi@tribulation $
dmcanzi@tribulation $ man perlsub | head
PERLSUB(1) Perl Programmers Reference Guide
PERLSUB(1)
NAME
perlsub - Perl subroutines
SYNOPSIS
To declare subroutines:
dmcanzi@tribulation $
dmcanzi@tribulation $ exit
Script done on Thu Sep 1 16:19:32 2011
--
David Canzi | Life is too short to point out every mistake. |
------------------------------
Date: Thu, 1 Sep 2011 20:40:52 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <slrnj5vrek.20gn.willem@toad.stack.nl>
Rainer Weikusat wrote:
) Willem <willem@toad.stack.nl> writes:
)> Rainer Weikusat wrote:
)> I claimed that the sort routine *conceptually* is a function from arrays
)> to arrays. This is correct.
)
) The perl sort is defined based on lists.
Yes, so you reiterated several times.
What does that have to do with conceptual interpretations ?
)> ) Sort takes a list as input) and returns a list as
)> ouput. Evaluating a list in scalar context) returns the last element
)> of the list, NOT the number of members.
)>
)> Can you show a piece of perl code that 'evaluates a list in scalar
)> context', but without using a comma to build the list?
)>
)> If not, then one could just as well say that the comma operator returns
)> the concatenation of its operands in list context, and the rightmost
)> operand in scalar context, and the whole concept of 'evaluating a list
)> in scalar context' can be dropped altogether.
)
) No, it can't, because, again, the 'theoretical model' you like to use
) here is in conflict with the Perl documentation:
)
) List value constructors
) List values are denoted by separating individual values by
) commas (and enclosing the list in parentheses where precedence
) requires it):
)
) (LIST)
)
) In a context not requiring a list value, the value of what
) appears to be a list literal is simply the value of the final
) element, as with the C comma operator. For example,
)
) @foo = ('cc', '-E', $bar);
)
) assigns the entire list value to array @foo, but
)
) $foo = ('cc', '-E', $bar);
)
) assigns the value of variable $bar to the scalar variable $foo.
) [perldata(1)]
I'm not seeing "a list evaluated in scalar context returns the last
element". What you quoted above supports my intepretation, that
'what appears to be a list' (i.e. values separated by commas), when
in scalar context, is *not* a list, but the last value.
For example, what is the result of the following Perl code:
my @a1 = qw(a b c); my @a2 = qw(d e f); my $s = @a1,@a2; say $s;
(Without looking it up).
So, as it appears, the documentation does not back up your claim
that 'evaluating a list in scalar context returns the last element'.
Instead, 'the operator that creates a list in list context, returns
the last element in scalar context'. Which is a special case to
accomodate the expectations of C programmers about the comma operator.
In other words: in that case, there is a *good reason* why the
comma-operator is not context-agnostic, and *instead* returns the
last element. In case of sort(), there is no good reason not to
be context-agnostic, and return the argument count.
)> As you argue below, this is irrelevant because functions are aware
)> of the context they are in. Several functions that return lists
)> will return the list count in scalar context.
)
) Several functions which *happen* to generate an output list from an
) input list where the number of elements on the output list cannot be
) predicted without performing the operation on the input list return
) this number when used in scalar context. The sort operation does not
) have this property: Since it permutes the elements from the input
) list, the number of elements of the output list is identical to the
) number of elements on the input list.
Why did you snip the part where I said that *no* function that returns
a list returns the last item in scalar context ? It was the juxtaposition
of the two which formed my argument, and by snipping that part, you
effectively changed my argument into something that you could attack.
)
) [...]
)
)> ) Besides being wrong, this is also besides the point: You expect that
)> ) sort behaves as if it was context-agnostic but it isn't:
)>
)> I am trying to argue that sort *should* behave as if it was
)> context-agnostic, because that is the most sensible option.
)
) That's the most sensible option FOR YOU because you happen to have
) written some code based on the assumption that sort would behave in
) this way despite it actually doesn't.
Yes. That's what I just said. Does it not occur to you that when somebody
expects something to happen a certain way, they have good reasons for that?
And in case you had missed it, this whole thread I have been presenting the
very reasons I have for these expectations.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Thu, 1 Sep 2011 23:59:10 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: Why does sort return undef in scalar context ?
Message-Id: <j3p68e$99c$1@speranza.aioe.org>
In article <slrnj5vrek.20gn.willem@toad.stack.nl>,
Willem <willem@toad.stack.nl> wrote:
>
>I'm not seeing "a list evaluated in scalar context returns the last
> element". What you quoted above supports my intepretation, that
>'what appears to be a list' (i.e. values separated by commas), when
>in scalar context, is *not* a list, but the last value.
>
>For example, what is the result of the following Perl code:
> my @a1 = qw(a b c); my @a2 = qw(d e f); my $s = @a1,@a2; say $s;
>(Without looking it up).
That's a bad demonstration, since it doesn't really show the "last value"
result of the comma operator. It seems to be showing that you think $s got
the size of @a2 because @a2 is the last operand of the comma operator.
What actually happens, since assignment has higher precedence,
is $s=@a1 and a useless evaluation of @a2 in void context.
Make @a1 and @a2 different lengths and you'll see the difference.
--
Alan Curry
------------------------------
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 3487
***************************************
