[33025] in Perl-Users-Digest
Perl-Users Digest, Issue: 4301 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 24 09:09:16 2014
Date: Fri, 24 Oct 2014 06:09:03 -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 Fri, 24 Oct 2014 Volume: 11 Number: 4301
Today's topics:
A way to disable 5.14 experimental feature <adrien.barreau@live.fr>
Re: A way to disable 5.14 experimental feature <rweikusat@mobileactivedefense.com>
Re: prime <rweikusat@mobileactivedefense.com>
Re: prime <bauhaus@futureapps.invalid>
Re: prime <rweikusat@mobileactivedefense.com>
Re: prime <bauhaus@futureapps.invalid>
Re: prime <rweikusat@mobileactivedefense.com>
Text zerlegen asal@gmx.de
Re: Text zerlegen <news@lawshouse.org>
Re: Text zerlegen <rweikusat@mobileactivedefense.com>
Re: Text zerlegen asal@gmx.de
Re: Text zerlegen <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 22 Oct 2014 10:51:13 +0200
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: A way to disable 5.14 experimental feature
Message-Id: <m27r5s$2gk$1@dont-email.me>
Hello all.
The feature I'm talking about is this one:
http://perldoc.perl.org/5.14.0/perldelta.html#Syntactical-Enhancements
For many reasons, I'm facing code written on 5.14.2 Perl which is run on
Perl 5.10.1.
You can guess that it sometime goes wrong, when somebody uses something like
push $ar, 1;
I took a look at feature.pm, but a I did not find a way to disable these
experimental auto casts.
Is there one?
Thanks.
Adrien.
Ps: The "don't mix versions" option is the good one, but will take time.
Hence the question.
------------------------------
Date: Wed, 22 Oct 2014 15:30:51 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A way to disable 5.14 experimental feature
Message-Id: <877fzs41no.fsf@doppelsaurus.mobileactivedefense.com>
Adrien BARREAU <adrien.barreau@live.fr> writes:
> The feature I'm talking about is this one:
> http://perldoc.perl.org/5.14.0/perldelta.html#Syntactical-Enhancements
>
> For many reasons, I'm facing code written on 5.14.2 Perl which is run
> on Perl 5.10.1.
> You can guess that it sometime goes wrong, when somebody uses something like
> push $ar, 1;
>
> I took a look at feature.pm, but a I did not find a way to disable
> these experimental auto casts.
> Is there one?
The easiest option would seem to be to change this function (in pp.c)
-----------
static AV *
S_deref_plain_array(pTHX_ AV *ary)
{
if (SvTYPE(ary) == SVt_PVAV) return ary;
SvGETMAGIC((SV *)ary);
if (!SvROK(ary) || SvTYPE(SvRV(ary)) != SVt_PVAV)
Perl_die(aTHX_ "Not an ARRAY reference");
else if (SvOBJECT(SvRV(ary)))
Perl_die(aTHX_ "Not an unblessed ARRAY reference");
return (AV *)SvRV(ary);
}
-----------
such that it looks like this
-----------
static AV *
S_deref_plain_array(pTHX_ AV *ary)
{
if (SvTYPE(ary) == SVt_PVAV) return ary;
Perl_die(aTHX_ "Not an ARRAY");
return NULL;
}
-----------
and compile a perl from the modified sources. This should result in a
runtime exception when trying to use array auto-dereferencing.
Changing the 'compiler' part such that it again rejects this also
doesn't seem to be overly complicated but complicated enough that I'm
not comfortable with 'blindly' (without testing it myself) suggesting
anything.
------------------------------
Date: Tue, 21 Oct 2014 23:09:36 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: prime
Message-Id: <87zjcphy73.fsf@doppelsaurus.mobileactivedefense.com>
John Black <jblack@nospam.com> writes:
> rweikusat@mobileactivedefense.com says...
>> This is really no different from
>>
>> $a += $b if $c < 34;
>>
>> $a += $b is a simple statement (based on another binary operator)
>>
>
> Well it appears different because $a and $b are just scalars whereas "$N=0" and "last" look
> more like statements in their own right, than simple components of a statement. It wouldn't
> make sense to write $N=0 += last.
It likely wouldn't do what was intended because the RHS of the
assignment operator is evaluated first, hence, the last would terminate
the loop before the $N=0 was executed, but grammatically, this is
perfectly legitimate. It's arguably somewhat weird that the loop control
verbs count as expressions in Perl but frequently useful (as in this
case).
------------------------------
Date: Wed, 22 Oct 2014 12:51:04 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: prime
Message-Id: <m2826j$o7u$1@dont-email.me>
On 20.10.14 23:52, Rainer Weikusat wrote:
> This is really no different from
>
> $a += $b if $c < 34;
>
> $a += $b is a simple statement (based on another binary operator) and it
> is conditionally executed because of the attached statement
> modifier.
In many cases, there is the expedient of putting parentheses,
as in
($a += $b) if $c < 34;
which might or might not be seen as less confusing than invoking
Perl's grammar. The parentheses do show the borders, which might
be all that counts.
------------------------------
Date: Wed, 22 Oct 2014 14:44:34 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: prime
Message-Id: <87fveg43st.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 20.10.14 23:52, Rainer Weikusat wrote:
>> This is really no different from
>>
>> $a += $b if $c < 34;
>>
>> $a += $b is a simple statement (based on another binary operator) and it
>> is conditionally executed because of the attached statement
>> modifier.
>
> In many cases, there is the expedient of putting parentheses,
> as in
>
> ($a += $b) if $c < 34;
>
> which might or might not be seen as less confusing than invoking
> Perl's grammar. The parentheses do show the borders, which might
> be all that counts.
For this particular example, the assumption that the statement modifier
is not a statement modifier but an operator just doesn't make any
sense: If not $b, what else is it going to add?
I used to be in favour of 'if in doubt, add redundant ()s' but I'm not
anymore: C isn't the be-all and end-all of all programming language and
using some subset(!) aka 'pidgin C' to write code in any sufficiently
similar language just makes things needlessly confusing for people whose
'undocumented, native C dialect' differs from the 'undocumented, native
C-dialect' of the code author: I'm interested in using the features
offered to be by $programming_language productively, not in (endlessly)
documenting that "I had to learn writing Math and if this ain't
sufficient for life, something is wrong with that and it has to adapt"
(because I can't/ won't).
------------------------------
Date: Wed, 22 Oct 2014 20:11:20 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: prime
Message-Id: <m28s03$n1u$1@dont-email.me>
On 22.10.14 15:44, Rainer Weikusat wrote:
>> In many cases, there is the expedient of putting parentheses,
>> as in
>>
>> ($a += $b) if $c < 34;
>>
>> which might or might not be seen as less confusing than invoking
>> Perl's grammar. The parentheses do show the borders, which might
>> be all that counts.
>
> For this particular example, the assumption that the statement modifier
> is not a statement modifier but an operator just doesn't make any
> sense: If not $b, what else is it going to add?
Whether or not "$b if $c < 34" could be an operand will depend on
one's background. E.g., if you had been exposed to the Icon
programming language, you might expect that conditionals can
produce non-Boolean values, as will comparisons (which can be chained…).
So your brain will need to harbour yet another significant set of rules
if work life forces you to work with yet another language.
Time well spent? The combinatorial complexity is foreseeable,
as is the opportunity to specialize. If employers pay for it, good,
enjoy.
The real trouble is, I think, to allow many peculiarities into
the syntax for what is essentially the same thing, conditional
execution. In this case one has to decipher the expression
inside out, first, and know the rules. This works as long as one
is accustomed to just that syntax. It will work better if there are
indicators that let one expect modifiers, I think, as is the
case for Python's built-in filtering ifs.
I'm not that happy adding parentheses around $a += $b because
they are overloaded already. And then, one wonders if they
have an effect like establishing list context. And then, whether
list context makes a difference. But, in Perl there is no real way
to do it if one wishes to invert the control flow grammatically.
There is some stretch of context and implicit grammar, and both
are required of every reader for that convenience of a one-liner.
The density adds a flavor of APL, though ;-)
------------------------------
Date: Thu, 23 Oct 2014 12:32:09 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: prime
Message-Id: <87iojbuime.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 22.10.14 15:44, Rainer Weikusat wrote:
>
>>> In many cases, there is the expedient of putting parentheses,
>>> as in
>>>
>>> ($a += $b) if $c < 34;
>>>
>>> which might or might not be seen as less confusing than invoking
>>> Perl's grammar. The parentheses do show the borders, which might
>>> be all that counts.
>>
>> For this particular example, the assumption that the statement modifier
>> is not a statement modifier but an operator just doesn't make any
>> sense: If not $b, what else is it going to add?
>
> Whether or not "$b if $c < 34" could be an operand will depend on
> one's background. E.g., if you had been exposed to the Icon
> programming language, you might expect that conditionals can
> produce non-Boolean values, as will comparisons (which can be
> chained…).
No. It depends on the programming language in question and while it is
certainly possible to use if as binary operator and define some
semantics which cause an expression
$b if $c < 34
to evaluate to some value if $c is not smaller then 34, eg, 42 (for
hopefully obvious reasons) or special-case this in the parser to mean
circumference / diamater * times average income tax rate in 1977 (any
information which could serve as a hint regarding 'circumeference and
diameter of what' or 'income tax paid where' intentionally omitted to
stress the fact that words are meaningless and communication futile), this
is not the case in Perl.
> So your brain will need to harbour yet another significant set of rules
> if work life forces you to work with yet another language.
> Time well spent?
I don't memoize things, I acquire them as the need arises and gradually
lose them again (sort of) when it goes away. The idea that a human
brain is best used as container for vast amounts of information which is
useless almost all of the time while intelligent computers are needed to
provide the intelligence this arrangement otherwise lacks is - well
- unintelligent (probably came from a guy who never drove a car down a
long slope at maximum acceleration to determine just how fast it can go).
But I realize this doesn't really answer the question.
> The real trouble is, I think, to allow many peculiarities into
> the syntax for what is essentially the same thing, conditional
> execution. In this case one has to decipher the expression
> inside out, first, and know the rules.
Trying to read it from left to right is sufficient, although possibly
not consistent with 'the rules' as dictated (and dutifully internalized)
by some other programming language. But I don't really understand
this. A construct like
if ($c < 34) {
print("Remember the income tax\n");
}
can be said to have an 'inside position' (between the brackets) and also
something which is outside of that but not
print("Remember the income tax\n") if $c < 34;
except as automatic superimposition of a mind expecting to see the
former (Wild guess. I really don't understand it).
[...]
> I'm not that happy adding parentheses around $a += $b because
> they are overloaded already. And then, one wonders if they
> have an effect like establishing list context. And then, whether
> list context makes a difference. But, in Perl there is no real way
> to do it if one wishes to invert the control flow grammatically.
> There is some stretch of context and implicit grammar, and both
> are required of every reader for that convenience of a one-liner.
It's sort of silly to create 'groups of one element', especially if this
means adding yet more strange characters (like {) to a text: The curlies
(or any similar construct) are a sort-of a makeshift approach for
telling the computer that sequence of statements should be controlled by
the if (or a similar construct) instead of just the one it is attached
to. And "ok, that's good enough to express anything and nobody pays me
for thinking about this shit" is the just "pidgin is king" approach I
was criticizing: The more primitive the used language happens to be, the
more complicated does it become to describe a complex circumstance in it
and the more complicated the description, the more cumbersome is it to
understand what it means.
------------------------------
Date: Thu, 23 Oct 2014 10:01:07 -0700 (PDT)
From: asal@gmx.de
Subject: Text zerlegen
Message-Id: <77b51f8b-eb78-42fd-8ccb-8f344b39ceb7@googlegroups.com>
Hallo Gruppe,
ich habe ein Textdokument, das ca wie folgt aussehen k=F6nnte:
~~~~~~~~~~~~~~~~~~~~
erster bla
foo bar bla
zweiter sabbel
gelaber
mehr gelaber
dritter brumm
vierter umpf
jajaja
~~~~~~~~~~~~~~~~~~~~
Nun will ich die Datei in ein Array einlesen. Dabei soll der Text so zerleg=
t werden, dass immer, wenn eine Zeile NICHT mit einem Leerzeichen beginnt, =
ein neues Arrayelement beginnt. Folgendes kommt dem sehr Nahe:
open(DATEI, "liste.txt");
my $response =3D join("", <DATEI>);
close(DATEI);
my @positionen =3D split(/\n\S/, $response);
Dummerweise fehlt nun aber stets der erste Buchstabe je Position. Z.B. sieh=
t $positionen[0] jetzt wie folgt aus:
~~~~~~~~~~~~~~~~~~~~
rster bla
foo bar bla
~~~~~~~~~~~~~~~~~~~~
Wie kann ich die Datei wie gew=FCnscht zerlegen?
Danke f=FCr eure Hilfe
Martin
------------------------------
Date: Thu, 23 Oct 2014 18:41:45 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Text zerlegen
Message-Id: <kO2dndxBrP5HoNTJnZ2dnUVZ8uydnZ2d@giganews.com>
On 23/10/14 18:01, asal@gmx.de wrote:
> my @positionen = split(/\n\S/, $response);
^
|
|
Hier ist der erste Buchstabe; es wurde entfernt
(Forsicht: Ich kann nur ein kleines bischen Deutsch sprechen!)
--
Henry Law Manchester, England
------------------------------
Date: Thu, 23 Oct 2014 19:21:26 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Text zerlegen
Message-Id: <87r3xyfxzt.fsf@doppelsaurus.mobileactivedefense.com>
asal@gmx.de writes:
> ~~~~~~~~~~~~~~~~~~~~
> erster bla
> foo bar bla
> zweiter sabbel
> gelaber
> mehr gelaber
> dritter brumm
> vierter umpf
> jajaja
> ~~~~~~~~~~~~~~~~~~~~
>
> Nun will ich die Datei in ein Array einlesen. Dabei soll der Text so zerlegt werden, dass immer, wenn eine Zeile NICHT mit einem Leerzeichen beginnt, ein neues Arrayelement beginnt. Folgendes kommt dem sehr Nahe:
>
> open(DATEI, "liste.txt");
> my $response = join("", <DATEI>);
> close(DATEI);
>
> my @positionen = split(/\n\S/, $response);
>
>
> Dummerweise fehlt nun aber stets der erste Buchstabe
[...]
> Wie kann ich die Datei wie gewünscht zerlegen?
Eine Moeglichkeit:
my @parts = split(/\n(?!\s)/, $in);
/\n(?!\s)/ bedeutet '\n dem kein Whitespace-Zeichen folgt' aber das
folgende Zeichen ist nicht Bestandteil des gematchten Textes
('zero-width negative look-ahead assertion', perloc perlre)
BTW: Umgangsprache hier ist normalerweise Englisch.
------------------------------
Date: Thu, 23 Oct 2014 11:59:27 -0700 (PDT)
From: asal@gmx.de
Subject: Re: Text zerlegen
Message-Id: <fd5c01f5-244a-4046-94ca-150ac6d5f8ae@googlegroups.com>
Sorry, I just realized I took the wrong group (not the german perl group).
But anyway, thanks for the answers.
Martin
------------------------------
Date: Thu, 23 Oct 2014 13:40:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Text zerlegen
Message-Id: <lqpi4a9c4b3dc0dlf9mbbn3hpjg1fm7lbp@4ax.com>
asal@gmx.de wrote:
[Please limit the length of your lines to ~75 characters as has been a
proven custom in Usenet for the past 3 decades. Thank you.]
>ich habe ein Textdokument, das ca wie folgt aussehen könnte:
>
>~~~~~~~~~~~~~~~~~~~~
>erster bla
> foo bar bla
>zweiter sabbel
> gelaber
> mehr gelaber
>dritter brumm
>vierter umpf
> jajaja
>~~~~~~~~~~~~~~~~~~~~
>
>Nun will ich die Datei in ein Array einlesen. Dabei soll der Text so zerlegt werden, dass immer, wenn eine Zeile NICHT mit einem Leerzeichen beginnt, ein neues Arrayelement beginnt. Folgendes kommt dem sehr Nahe:
my @myarray;
$i = -1;
while (<DATA>) {
$i++ unless /^ /;
$myarray[$i] .= $_;
}
__DATA__
erster bla
foo bar bla
zweiter sabbel
gelaber
mehr gelaber
dritter brumm
vierter umpf
jajaja
jue
------------------------------
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 4301
***************************************
