[32934] in Perl-Users-Digest
Perl-Users Digest, Issue: 4105 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 12 12:56:14 2014
Date: Mon, 30 Dec 2013 13:09:04 -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 Mon, 30 Dec 2013 Volume: 11 Number: 4105
Today's topics:
Re: How does the perl debugger find the source lines <rweikusat@mobileactivedefense.com>
Re: How does the perl debugger find the source lines <rweikusat@mobileactivedefense.com>
Re: How does the perl debugger find the source lines <ben@morrow.me.uk>
Re: PDL Questions - Dec. 21, 2013 <cwilbur@chromatico.net>
Re: PDL Questions - Dec. 21, 2013 <cwilbur@chromatico.net>
Re: PDL Questions - Dec. 21, 2013 <rweikusat@mobileactivedefense.com>
Re: Question about language setting - 2nd question <ben@morrow.me.uk>
Re: Question about language setting - 2nd question <dave@invalid.invalid>
Re: Question about language setting - 2nd question <hjp-usenet3@hjp.at>
Re: Question about language setting - 2nd question <bjoern@hoehrmann.de>
Re: Question about language setting - 2nd question <ben@morrow.me.uk>
Re: Question about language setting <ben@morrow.me.uk>
Re: Syntax understanding problem (Tim McDaniel)
Re: Syntax understanding problem (Tim McDaniel)
Re: Syntax understanding problem <rweikusat@mobileactivedefense.com>
Re: Syntax understanding problem <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 30 Dec 2013 14:28:00 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <877gamv2fj.fsf@sable.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
[...]
>> "Devel::REPL - a modern perl interactive shell"
>>
>> As usual, modern means "It prints 'Hello, world!'" but it needs six
>> order of magnitude more infrastructure code than a simple
>>
>> perl -e 'print "Hello, World!\n"'
>>
>> would require" ...
>
> Yup. It also gets all the hard things right, like running pieces of code
> read separately in the same lexical context (or not, as you like).
I've actually casually read through the 'core' of the implementation
which is 123 lines of code and seems to be little more than a wrapper
around Term::Readline (the perl debugger will use that as well if
available) with a moose chained to its ankle because someone considered
that a fashionably pet in 2007. If the author is really convinced to
have solved any 'hard problems' (minus getting his head around the issue
in the first place) in there, I seriously hope that he doesn't ever
encounter a hard problem as this will probably blow a fuse in his head.
OTOH, even the most trivial problem can be made to look very commanding
by a suitably obfuscated solution, eg use
sub wrap_as_sub {
my ($self, $line, %args) = @_;
return qq!sub {\n!. ( $args{no_mangling} ? $line : $self->mangle_line($line) ).qq!\n}\n!;
}
instead of
sprintf('sub { %s }', $args{no_mangling} ? $line : $self->mangle_line($line));
minus any of the fancy features (including sensible handling of
exceptions thrown by the executed code), this is
----------
use Term::ReadLine;
sub run
{
eval($_[0]);
print STDERR ("XX: $@") if $@;
}
my ($term, $line);
$term = Term::ReadLine->new('Perl ERPL');
print(run($line), "\n") while defined($line = $term->readline('Perl ERPL>'));
print("\n");
----------
(Erpel is the German word for a male duck)
------------------------------
Date: Mon, 30 Dec 2013 15:02:35 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <8738lav0tw.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> sub run
> {
> eval($_[0]);
> print STDERR ("XX: $@") if $@;
> }
The 2nd line was a 'last second' addition to make this print compiler
errors encountered during eval which eats the return value of the
former. Slightly more complicated demo which deals with that:
----------
sub dorun
{
eval($_[0]);
}
sub run
{
my @r;
@r = &dorun;
return @r unless $@;
print STDERR ("XX: $@");
return;
}
-----------
A supposed-to-be-reusable class providing such a feature should probably
take some more pain in order to provide a clean execution environment
than just using an 'empty sub', eg, it should localize all or at least
some of the global variables affecting execution of Perl code in order
to avoid leaking parts of the 'executor' environment into the executed
code and the same in the opposite direction (especially @_ and $_).
------------------------------
Date: Mon, 30 Dec 2013 16:07:59 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How does the perl debugger find the source lines
Message-Id: <vbi8pa-v1a1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
>
> I played around with it a bit more, but I am just becoming more
> confused. It's not like eval never fills in @{"_<$filename"}. In this
> simple test script:
>
> #!/usr/bin/perl
> use v5.10;
>
> eval ('
> #line 1 "3a"
> use v5.10;
>
> sub foo {
> say "bla";
> }
> ');
>
> foo();
> say;
>
> @{"_<3a"} is filled with the correct lines and I can singlestep into foo().
>
> So, sometimes the lines are there and sometimes they aren't.
Ah, I was going to ask if you were using #line. The only case I can come
up with where the debugger sees no lines at all is
eval <<'PERL';
#line 1 evil
PERL
eval <<'PERL';
#line 1 evil
sub bar {
$DB::single = 1;
return;
}
PERL
bar();
It seems that the first time the compiler sees a given logical file, it
creates @{"_<FILE"} and starts populating it. If it created this @_< as
the result of a #line directive, it starts inserting lines at the
correct index. After that, all lines from there until the end of the
current compilation unit (file or eval) go into successive indices of
that @_<, regardless of any further #line directives.
In particular, several #lines in the same file giving different
filenames will cause the lines to be put into multiple @_< arrays. If
perl sees a given logical file again, it ignores that fact and doesn't
change which @_< arrays it's recording lines into.
What this adds up to is that doing anything at all with #line beyond
putting a single directive at the top of a file giving a unique filename
and a starting line number will cause the debugger to display entirely
incorrect listings.
I don't know whether this loading mechanism is something you have any
control over, but in the past I've found it's easier to load a 'file' of
generated code like this:
sub fakerequire {
my ($name, $code) = @_;
local @INC = (sub {
if ($_[1] eq $name) {
open my $CODE, "<", \$code;
return $CODE;
}
return;
}, @INC);
require $name;
}
This invokes the whole of perl's load-a-file mechanism, and avoids
needing to muck about with %INC or #line or anything else.
Ben
------------------------------
Date: Mon, 30 Dec 2013 10:41:56 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <8761q64a7v.fsf@new.chromatico.net>
>>>>> "MV" == Michael Vilain <vilain@NOspamcop.net> writes:
MV> The perl group seems to be particularly prickly about people
MV> doing their homework before posting.
The culture of the Perl group was formed in the days when every moron
who could spell HTML considered himself an experienced web developer and
posted idiotic FAQs here, or expected free sysadmin support for his
broken web hosting setup.
MV> The fact that people haven't plonked you yet just means they
MV> like poking you with a stick just to see you react.
There's also an element of abnormal psychology combined with
rubbernecking: nobody can really be that consistently clueless, can
they?
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 30 Dec 2013 10:39:29 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <87a9fi4aby.fsf@new.chromatico.net>
>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
EDG> So, we are now considering Fortran and Julia for future
EDG> work. Python is attractive but doesn't by itself do extremely
EDG> high speed calculations. Julia is being checked. But I get the
EDG> impression that it is still in some early stages of
EDG> development. So far there isn't even a Julia language
EDG> Newsgroup. I did suggest to those people that they might
EDG> create one.
EDG> For my purposes, working with Perl to a large degree
EDG> might have one last chance.
Enjoy Python.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 30 Dec 2013 17:10:08 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: PDL Questions - Dec. 21, 2013
Message-Id: <87vby6tgcv.fsf@sable.mobileactivedefense.com>
"E.D.G." <edgrsprj@ix.netcom.com> writes:
> "E.D.G." <edgrsprj@ix.netcom.com> wrote in message
> news:yoOdnUBR--ONSiDPnZ2dnUVZ_o2dnZ2d@earthlink.com...
[...]
> However, for general usage by the international scientific
> community a programming language also needs to have one or several of
> the following three things. And unfortunately, Perl doesn't meet
> those requirements in my opinion.
>
> 1. It needs to be able to run "out of the box" with no problems.
> That means that when it is installed there aren't any additional steps
> that need to be done to start using it.
[...]
> However, there have been some problems with getting new modules
> to work. And PDL is the most important of them so far.
>
> PPM did not seem to get the job done by itself though I plan to
> try using it again and see if I might have missed something.
>
> Doing everything else possible and following all of the
> instructions on the PDL instruction pages got the module installed and
> running for some commands but not others.
>
> This means that the PDL module did not run "out of the box" for
> my installation. And if people cannot get something to run
> immediately like that then the programming language has a major
> limitation. Individual scientists don't have time to spend an entire
> week trying to get a computer language to work.
PDL is an external module (or set of external modules) for Perl and as
such, it is only accidentally related to the language itself, IOW, your
criticism of the PDL installation procedure and documentation may well
be justified BUT that's something to be directed at the people who
develop PDL.
------------------------------
Date: Mon, 30 Dec 2013 14:36:22 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Question about language setting - 2nd question
Message-Id: <60d8pa-mb91.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> Now the first problem is solved, see elseehere in this tree, on to the
> next :-)
>
> I have two input files the creation of which I have no control over.
> One has been written, from C, using whatever codepage the user has.
> The other file is encoded utf8.
>
> Both files contain a file name. One of the consistancy checks is to
> see if they match. I can read in the second file with open my $FILE2,
> '<:encoding(utf8)", .......
>
> So how to open the first?
>
> open my $FILE1, '<', .....
> open my $FILE1, <:raw', ....
> open my $FILE1, '<', .........
> binmode $FILE;
>
> All seem to do exactly the same thing - except for \r\n processing.
Yes.
> or
>
> open my $FILE1, '<:encoding(whatever)', ......
>
> When perl converts to internal utf8 how does it decide to map code
> points > 127 when it is not told the cp?
It reads bytes and maps them directly to Unicode codepoints; which,
because of the way Unicode is defined, means it's effectively using
ISO8859-1.
> It does not default to
> current as I run with 850 and opening '<:encoding(cp850)' gives a
> different result for points > 127 than does open '<'.
No. Perl doesn't know anything about OS/2 codepages. (It could, perhaps,
be taught; that is, it would be possible to write a :codepage layer
which looked up the current codepage and used that; but it would be
highly unportable to do something like that unless it was explicitly
requested.)
> It's complicated
> by the fact that the field separator on the first file is hex DE that
> will get mangled in the former case. But my $sep = decode("cp$cp",
> "\xDE"); where $cp is the codepage seems to get around that one.
When dealing with binary separators it's better to handle the data as
binary first, then decode to Unicode afterwards. That is, open the file
in :raw mode, split into fields on /\xDE/, and only then decode each
field from CP850 with decode().
What you were doing was effectively treating the file as 'fields
separated by I-grave' rather than 'fields separated by binary 0xDE'.
Those things happen to come out looking the same in a CP850 file,
because CP850 is a 1-byte encoding and 0xDE is a byte with defined
semantics, but in general you can't assume binary separators can be
meaningfully decoded from any given encoding.
Ben
------------------------------
Date: Mon, 30 Dec 2013 15:19:09 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Question about language setting - 2nd question
Message-Id: <fV45K0OBJxbE-pn2-pKoZU6CtDD7Y@paddington.bear.den>
On Mon, 30 Dec 2013 14:36:22 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
> > Now the first problem is solved, see elseehere in this tree, on to the
> > next :-)
> >
> > I have two input files the creation of which I have no control over.
> > One has been written, from C, using whatever codepage the user has.
> > The other file is encoded utf8.
> >
> > Both files contain a file name. One of the consistancy checks is to
> > see if they match. I can read in the second file with open my $FILE2,
> > '<:encoding(utf8)", .......
> >
> > So how to open the first?
> >
> > open my $FILE1, '<', .....
> > open my $FILE1, <:raw', ....
> > open my $FILE1, '<', .........
> > binmode $FILE;
> >
> > All seem to do exactly the same thing - except for \r\n processing.
>
> Yes.
>
> > or
> >
> > open my $FILE1, '<:encoding(whatever)', ......
> >
> > When perl converts to internal utf8 how does it decide to map code
> > points > 127 when it is not told the cp?
>
> It reads bytes and maps them directly to Unicode codepoints; which,
> because of the way Unicode is defined, means it's effectively using
> ISO8859-1.
>
> > It does not default to
> > current as I run with 850 and opening '<:encoding(cp850)' gives a
> > different result for points > 127 than does open '<'.
>
> No. Perl doesn't know anything about OS/2 codepages. (It could, perhaps,
> be taught; that is, it would be possible to write a :codepage layer
> which looked up the current codepage and used that; but it would be
> highly unportable to do something like that unless it was explicitly
> requested.)
>
> > It's complicated
> > by the fact that the field separator on the first file is hex DE that
> > will get mangled in the former case. But my $sep = decode("cp$cp",
> > "\xDE"); where $cp is the codepage seems to get around that one.
>
> When dealing with binary separators it's better to handle the data as
> binary first, then decode to Unicode afterwards. That is, open the file
> in :raw mode, split into fields on /\xDE/, and only then decode each
> field from CP850 with decode().
>
> What you were doing was effectively treating the file as 'fields
> separated by I-grave' rather than 'fields separated by binary 0xDE'.
> Those things happen to come out looking the same in a CP850 file,
> because CP850 is a 1-byte encoding and 0xDE is a byte with defined
> semantics, but in general you can't assume binary separators can be
> meaningfully decoded from any given encoding.
Many thanks Ben. As I said I didn't "design" the 0xDE bit :-) This
code is checking files of a program that only runs on OS/2 so
portability is not a question.
--
Regards
Dave Saville
------------------------------
Date: Mon, 30 Dec 2013 16:50:08 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Question about language setting - 2nd question
Message-Id: <slrnlc35hg.1f8.hjp-usenet3@hrunkner.hjp.at>
On 2013-12-30 14:36, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Dave Saville" <dave@invalid.invalid>:
>> It does not default to current as I run with 850 and opening
>> '<:encoding(cp850)' gives a different result for points > 127 than
>> does open '<'.
>
> No. Perl doesn't know anything about OS/2 codepages. (It could, perhaps,
> be taught; that is, it would be possible to write a :codepage layer
> which looked up the current codepage and used that; but it would be
> highly unportable to do something like that unless it was explicitly
> requested.)
There is the Encode::Locale module, which allows you to do something
like
open(my $fh, '<:encoding(locale)', $filename);
I don't think it works on OS/2 (A colleague recently told me it doesn't
even work on Windows), but I think it would be better to extend an
existing module to work on more platforms than to add another
platform-specific module.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 30 Dec 2013 17:01:45 +0100
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: Question about language setting - 2nd question
Message-Id: <1663c9dqrk0ohqs9ui5ps4d89mah3n7fnj@hive.bjoern.hoehrmann.de>
* Peter J. Holzer wrote in comp.lang.perl.misc:
>There is the Encode::Locale module, which allows you to do something
>like
> open(my $fh, '<:encoding(locale)', $filename);
>
>I don't think it works on OS/2 (A colleague recently told me it doesn't
>even work on Windows), but I think it would be better to extend an
>existing module to work on more platforms than to add another
>platform-specific module.
http://www.nntp.perl.org/group/perl.i18n/2008/07/msg214.html has some
thoughts about Windows support in that area.
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
------------------------------
Date: Mon, 30 Dec 2013 16:33:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Question about language setting - 2nd question
Message-Id: <asj8pa-hba1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2013-12-30 14:36, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Dave Saville" <dave@invalid.invalid>:
> >> It does not default to current as I run with 850 and opening
> >> '<:encoding(cp850)' gives a different result for points > 127 than
> >> does open '<'.
> >
> > No. Perl doesn't know anything about OS/2 codepages. (It could, perhaps,
> > be taught; that is, it would be possible to write a :codepage layer
> > which looked up the current codepage and used that; but it would be
> > highly unportable to do something like that unless it was explicitly
> > requested.)
>
> There is the Encode::Locale module, which allows you to do something
> like
> open(my $fh, '<:encoding(locale)', $filename);
>
> I don't think it works on OS/2 (A colleague recently told me it doesn't
> even work on Windows), but I think it would be better to extend an
> existing module to work on more platforms than to add another
> platform-specific module.
It looks like it's been recently extended to support retrieving the
console codepage on Windows, and to understand that there might be a
difference between 'console charset' and 'filesystem charset'. (It
doesn't yet make any sensible decision about what the filesystem charset
might be on Unix, but that's a standardisation problem rather than a
programming problem.)
On non-Windows systems it uses nl_langinfo to find the charset to use,
so if OS/2 / EMX / whatever libc Dave is using supports that function
(and it gives, or can be persuaded to give, correct results)
Encode::Locale should work correctly. If not, then assuming OS/2 exposes
some API to find the current codepage, support could be added fairly
easily; probably some sort of OS2::Console extension would be needed to
bind the relevant API to perl, unless one of the Win32 modules already
works.
Ben
------------------------------
Date: Mon, 30 Dec 2013 16:16:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Question about language setting
Message-Id: <6ri8pa-v1a1.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Mon, 30 Dec 2013 00:55:03 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>
> > Since your broken locales are causing feature.pm to fail, you get weird
> > failures if it gets loaded, but not otherwise. Carp loads feature.pm
> > (unintentionally) on 5.16 or later, but not on earlier versions.
> >
>
> A clever man (ie not me) has found the problem.
>
> perl is built with locale.h
> libc is built with unidef.h
>
> The definitions of LC_NUMERIC and LC_MONETARY are reversed between
> the two. Correcting locale.h to match unidef.h results in the posted C
> testcase to work as expected. Our perl porter is rebuilding a version
> with this change.
>
> > It might be worth reporting a bug about this: broken locales are Not
> > Good, but they shouldn't cause perl to fail unless you explicitly try to
> > invoke locale functions.
>
> Would you mind doing this please? I am not sure I can write a ticket
> that others could act on.
Now that you've identified the problem, I don't think it's something
perl could do anything about. I was assuming the problem was some sort
of broken locale definition, which perl was activating when it shouldn't
be, but if it's the whole locale mechanism which is broken there isn't
really anything perl can do.
I've checked the code and perl already DTRT: it explicitly sets
LC_NUMERIC to "C" before parsing or formatting numbers. If that doesn't
do what it's supposed to do you're going to get weird number formatting
bugs somewhere. (I'm slightly surprised perl is the only thing affected
by this, but maybe you aren't using anything else that calls setlocale
at all.)
Ben
------------------------------
Date: Mon, 30 Dec 2013 17:09:32 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Syntax understanding problem
Message-Id: <l9s9cc$nte$1@reader1.panix.com>
In article <3264pa-g15.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> >/^Relayed message/ and $discard = 0, next;
>>
>> the assignment gets done and $discard is set to 0. It's just that the
>> 0 return value coming out of the assignment is discarded.
>
>Specifically, that = operator returns $discard, as a modifiable
>lvalue.
So far as I understand the rules,
- a list assignment in a LIST environment returns the left-hand side
as a modifiable lvalue
- a list assignment in a SCALAR environment returns the number of
elements in the RIGHT-hand side. Hence the goatse operator, =()=.
- an assignment to a scalar in a LIST environment returns the
left-hand side as a modifiable lvalue
- an assignment to a scalar in a SCALAR environment returns 1, the
number of "elements" on the right-hand-side?
print (scalar (($a = 23) = 45), "\n");
Do I have that right?
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 30 Dec 2013 17:20:20 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Syntax understanding problem
Message-Id: <l9sa0k$4bs$1@reader1.panix.com>
In article <l9s9cc$nte$1@reader1.panix.com>,
Tim McDaniel <tmcd@panix.com> wrote:
>In article <3264pa-g15.ln1@anubis.morrow.me.uk>,
>Ben Morrow <ben@morrow.me.uk> wrote:
>>
>>Quoth tmcd@panix.com:
>>> >/^Relayed message/ and $discard = 0, next;
>>>
>>> the assignment gets done and $discard is set to 0. It's just that the
>>> 0 return value coming out of the assignment is discarded.
>>
>>Specifically, that = operator returns $discard, as a modifiable
>>lvalue.
>
>So far as I understand the rules,
>
>- a list assignment in a LIST environment returns the left-hand side
> as a modifiable lvalue
>
>- a list assignment in a SCALAR environment returns the number of
> elements in the RIGHT-hand side. Hence the goatse operator, =()=.
>
>- an assignment to a scalar in a LIST environment returns the
> left-hand side as a modifiable lvalue
>
>- an assignment to a scalar in a SCALAR environment returns 1, the
> number of "elements" on the right-hand-side?
>
> print (scalar (($a = 23) = 45), "\n");
>
>Do I have that right?
Of course, as written, that would obviously simplify into two cases.
But I don't understand what's going on.
print (scalar (($a = 23)), "\n");
print (scalar (($a = 23) = 45), "\n");
prints
23
1
... unless the parentheses around the second assignment, which I added
merely for precedence, make it considered a list assignment. But that
would be so insanely stupid -- there would be no way to get a scalar
assignment as in case 1, except maybe with an intervening sub call or
somewhting.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 30 Dec 2013 17:44:47 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Syntax understanding problem
Message-Id: <87ob3yter4.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
[...]
> print (scalar (($a = 23) = 45), "\n");
>
> prints
>
> 1
>
> ... unless the parentheses around the second assignment, which I added
> merely for precedence, make it considered a list assignment.
Ehh ... well ... ($a = 23) is obviously a list with a single elementy so
($a = 23) = 45
is obviously a list assignment.
------------------------------
Date: Mon, 30 Dec 2013 19:50:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Syntax understanding problem
Message-Id: <0ev8pa-mbh1.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <l9s9cc$nte$1@reader1.panix.com>,
> Tim McDaniel <tmcd@panix.com> wrote:
> >
> >So far as I understand the rules,
> >
> >- a list assignment in a LIST environment returns the left-hand side
> > as a modifiable lvalue
Yes. (Or, 'as a list of modifiable lvalues'.)
> >- a list assignment in a SCALAR environment returns the number of
> > elements in the RIGHT-hand side. Hence the goatse operator, =()=.
(Language!) Yes. This is the weird case, added because the logical
return would be 'the last element of the LHS as a modifiable lvalue',
and a count is more useful (when you remember you can do that).
> >- an assignment to a scalar in a LIST environment returns the
> > left-hand side as a modifiable lvalue
Yes.
> >- an assignment to a scalar in a SCALAR environment returns 1, the
> > number of "elements" on the right-hand-side?
No, a scalar assignment in scalar context returns the LHS as a
modifiable lvalue, again:
say \my $x;
say \scalar($x = 3);
> Of course, as written, that would obviously simplify into two cases.
> But I don't understand what's going on.
>
> print (scalar (($a = 23)), "\n");
> print (scalar (($a = 23) = 45), "\n");
>
> prints
>
> 23
> 1
>
> ... unless the parentheses around the second assignment, which I added
> merely for precedence, make it considered a list assignment.
Yes, an assignment whose LHS is explicitly parenthesised is always a
list assignment. Otherwise there's no way to perform a list assignment
to a list of one element; this is the difference between
$x = /(...)/;
and
($x) = /(...)/;
for example.
> But that
> would be so insanely stupid -- there would be no way to get a scalar
> assignment as in case 1, except maybe with an intervening sub call or
> somewhting.
There's no simple way to perform a scalar assignment into the result of
another scalar assignment, no; but why would you want to do that?
Ben
------------------------------
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 4105
***************************************
