Mailing List Archive

@ expansions
can we make perl5.002 more backwards comatible with perl4.036?

one place is this:

foreach $i ( 1 .. 10 ) { $_ ++ }

and another is this

mail "user@host< $file";

those are fatal errors under perl5. i suggest making
the first one a mandatory runtime warning, and the second one a
manadatory compile time warning *AND* if the thing before the
@sign is \w, or at maybe \S, to behave like perl4.

--tom
Re: @ expansions [ In reply to ]
Tom Christiansen writes:
>
> can we make perl5.002 more backwards comatible with perl4.036?
>
> one place is this:
>
> foreach $i ( 1 .. 10 ) { $_ ++ }
>
> and another is this
>
> mail "user@host< $file";
>
> those are fatal errors under perl5. i suggest making
> the first one a mandatory runtime warning, and the second one a
> manadatory compile time warning *AND* if the thing before the
> @sign is \w, or at maybe \S, to behave like perl4.

How about a
use perl4compat;
to hang perl4 compatibility behaviour on? I would have suggested
a new hint name for "use strict" but I can't think of decent wording.
no strict perl5_enforcements_that_break_perl4;
doesn't sound too good. Added to which, the default ought to be "no"
for the way "use strict" works.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
Re: @ expansions [ In reply to ]
> How about a
> use perl4compat;
> to hang perl4 compatibility behaviour on? I would have suggested
> a new hint name for "use strict" but I can't think of decent wording.
> no strict perl5_enforcements_that_break_perl4;
> doesn't sound too good. Added to which, the default ought to be "no"
> for the way "use strict" works.
>
> --Malcolm
>
> --
> Malcolm Beattie <mbeattie@sable.ox.ac.uk>
> Unix Systems Programmer
> Oxford University Computing Services
>

If the user needs to change their perl4 script to because it doesn't work
with perl5 they can just as easily change the first line to:

#!/usr/local/bin/perl4.036

Ultimate compatibility mode.

I think the current solution should stay. I have found that about 10% of the existing
scripts here do not work with perl5 (fail perl -c). Most are very easy to fix, but
the easy solution is to modify the script to point at the old version. That is
why installperl leaves the old version installed...

Wayne

PS: 10% is still over 1000 scripts so we needed to have an easy to automate solution.
Now the only problem is scripts that pass 'perl -c' but still don't execute the same
on perl5.

Half the P6 is written in perl... :)
Re: @ expansions [ In reply to ]
We can't do perl4compat the way Perl 4 did, because Perl 4 used the whole
program to decide whether @foo was an array or not. Perl 5 has to decide
when it sees it.

Larry
Re: @ expansions [ In reply to ]
What about

use strict compatibility

or, you could go with

use perl4

But, I think that most of the changes are good ones. "user@host" is a
big gotcha, but people WILL get over it, and the new behavior is more
reasonable.

-AJS

--
--- Aaron Sherman / "B4 f w+ c kv s+(--)v r p" ---
Phone: (617)321-5100 "I do not speak for THEM."
Email: ajs@ajs.com WWW: http://ajs.com/~ajs/
Re: @ expansions [ In reply to ]
: I wonder whether people here have missed the point I was trying to make:
: backwards compatibility means not modifying the source code. Adding some
: uses or no's makes it useless.

Well, then, we simply won't be backward compatible.

: I suggest that it be close to perl4, but of course we don't want to do a
: twopass. We could in theory do an indirection, but that's not worth it.
: It will be better if we can simply say "if the @sign is preceded by a
: certain set of chars (like alphas) then it's a literal AND A MANDATORY
: WARNING and if it is not, then it's a list." Of course, if there
: is no such list to interpolate known at compile time, that's a severe
: problem too, but too much breakage is getting me in big trouble right now.

How can you be in trouble for Perl's foibles, when Perl's foibles are
what you're getting paid to teach?

: What I hear at customer sites is:
:
: If perl5 won't run perl4 scripts, we won't run perl5.

That's their choice, and in some situations it's the right choice.

: Hence the desire for compat. Don'tyou remember when Larry retrofitted
:
: open FOO || die;
: even though it's broken?

It's not retrofitted. It merely produces a warning. You'll note the above
never calls die.

: Although I admit I still got bit back in the perl2 to perl3 or so,
: from writing too much
:
: open(pipe, "cmd|");

Yes, and Dan Faigin still hasn't forgiven me for changing \(...\) to (...)
between Perl 0 and Perl 1. :-)

I think my skin must be thicker than yours.

Larry
Re: @ expansions [ In reply to ]
> We can't do perl4compat the way Perl 4 did, because Perl 4 used the whole
> program to decide whether @foo was an array or not. Perl 5 has to decide
> when it sees it.

I wonder whether people here have missed the point I was trying to make:
backwards compatibility means not modifying the source code. Adding some
uses or no's makes it useless.

I suggest that it be close to perl4, but of course we don't want to do a
twopass. We could in theory do an indirection, but that's not worth it.
It will be better if we can simply say "if the @sign is preceded by a
certain set of chars (like alphas) then it's a literal AND A MANDATORY
WARNING and if it is not, then it's a list." Of course, if there
is no such list to interpolate known at compile time, that's a severe
problem too, but too much breakage is getting me in big trouble right now.

What I hear at customer sites is:

If perl5 won't run perl4 scripts, we won't run perl5.


Hence the desire for compat. Don'tyou remember when Larry retrofitted

open FOO || die;
even though it's broken?

Although I admit I still got bit back in the perl2 to perl3 or so,
from writing too much

open(pipe, "cmd|");

--tom

--tom
Re: @ expansions [ In reply to ]
My take on this is simple. People will get over it. Hand them a script

(eg.

#!/usr/bin/perl

while(<>) {
warn "Possible boo boo at line $. of $ARGV\n:\t$_"
if /\".*\w+\@\w+/;
}
)

and tell them to take a pill.

If you can get all of the great features of perl 5, and remain as
backward compatible as it is, then:

a. There is a God (and her name rhymes with Larry)
b. You should be thanking your lucky stars this isn't TCL (no
offense, John, but TCL really isn't GP, stop putting tabs
in your Cheerios).
c. You should throw that crap out that you hacked together
with perl4, and start writing some real programs.

On the other hand, I've worked in large, hairy environments with
Change Management meetings every other time you turn around, and can
understand where these people are coming from. My advice? Form a
committee, draw doodles on your day-timers, and call Tom or me and
we'll be glad to come over and show you how to convert to perl5 with
as little pain as possible (hell, it won't even cost as much as those
three SS2000's that Sun talked you into buying ;-)

-AJS

--
--- Aaron Sherman / "B4 f w+ c kv s+(--)v r p" ---
Phone: (617)321-5100 "I do not speak for THEM."
Email: ajs@ajs.com WWW: http://ajs.com/~ajs/
Re: @ expansions [ In reply to ]
> Well, then, we simply won't be backward compatible.

sigh. i dont' see why not, but i'm sure i'm just thick.

> How can you be in trouble for Perl's foibles, when Perl's foibles are
> what you're getting paid to teach?

I don't believe that being paid matters a whit: I get the same beef when I
give free user-group talks or classes at CU. When folks ask about whether
perl5 is compatible with perl4, I say "nearly" and they freak out. They
tell me that perl is as evil as tcl, which has a long history of breaking
code.

> : What I hear at customer sites is:
> :
> : If perl5 won't run perl4 scripts, we won't run perl5.

> That's their choice, and in some situations it's the right choice.

I want their not to be a perl4. I want to be perl. I don't like numbers
in the name. It's silly.

How come people don't insist on shipping and maintaining on their system
perl1, perl2, and perl3, but theey do keep perl4 and perl5?

But I know what you mean.

i agree it's borken code, but i don't want to maintain old exectuables
forever.

--tom
Re: @ expansions [ In reply to ]
Here's the request as related to me:

If in a DQ string, like
system "mail user@host";
rather than unconditionally aborting the execution, if the @ sign is
preceded by a \w char and there is no @host list variable, that it
should emit a literal as perl4 did. a mandatory warning
is acceptabe [tchrist adds: and desirable]

I explained that this is asking to create yet MORE hard-to-explain little
once-in-a-bluemoon context dependency, but the retort was "but perl is
always trying to guess what you mean and do it".

This is, however, the same class of people who think
that

$x = @a;

means

$x = \@a;

and that

@a = $x;

means

$a = split ' ', $x;

which while perhaps makes sense in some worldviews,
wouldn't seem to be a great idea at this point.

--tom
Re: @ expansions [ In reply to ]
Tom Christiansen writes:
>
> Here's the request as related to me:
>
> If in a DQ string, like
> system "mail user@host";
> rather than unconditionally aborting the execution, if the @ sign is
> preceded by a \w char and there is no @host list variable, that it
> should emit a literal as perl4 did. a mandatory warning
> is acceptabe [tchrist adds: and desirable]
>

All this maillist discussion!

Why not feed output of
perl -wc
to a 10-line script that will patch the source?

Ilya