Re: Perl 6
by neophyte (Curate) on Nov 02, 2000 at 16:54 UTC
|
As far as I understand, backward compatibility with Perl5 (not Perl4) is an issue in develloping Perl6 and the RFC process. Those things that went into Perl5 for backward compatibility with Perl4 will surely disappear. The latest doc mentions which commands are depreciated. Also if you post code, the monks will tell you if you use such code. So by the time Perl6 will come, you should be able to use it with only minor changes here & there, as little already pointed out.
neophyte | [reply] [Watch: Dir/Any] |
|
Unfornatly, that turns out not to be the case. You can convert perl5 to perl6 fairly easily in terms of code flow and such. However, changes like . to _ for concatanation and -> to '.' mean that you'll have to change all you code.
Have hope, though. Perl6 should be powerful enough to redefine operators. That means "use perl5" should be able to be written in fairly simple perl6 and be able to provide the perl5 semantic of -> (mostly) and '.'.
Thanks,
James Mastros,
Just Another Perl Scribe
| [reply] [Watch: Dir/Any] |
|
Rumor control time.
Perl 6 will, for the most part, work just fine if you
accidentally feed it Perl 5. Larry Wall made this design
decision clear right from
Apocalypse 1.
This is, in fact, not an optional decision. There is a
tremendous installed Perl 5 code base, and it would be
suicide for Perl 6 to not support it in a natural and
direct fashion.
| [reply] [Watch: Dir/Any] |
|
|
|
Re: Perl 6
by little (Curate) on Nov 02, 2000 at 15:16 UTC
|
Shouldn't be a problem as you can have more than one perl installed and require the proper one.
On the other hand there are recommendations about those functions and constructs that will be deprecated and usage is not recommended any more, so keep to the advice of those coders and don't use them anymore to enable you to port your code easier. Here it seems to me a good idea to get used to clear procedural and/or OO-programming to help you easily maintain a lot of code with minor changes.
Have a nice day
All decision is left to your taste | [reply] [Watch: Dir/Any] |
(tye)Re: Perl 6
by tye (Sage) on Nov 02, 2000 at 20:59 UTC
|
My big concern is that the shift in garbage collection
methodologies will mean that destructors don't fire in
a timely manner. There is no automated way to "fix" a
script that makes good use of good destructor behavior
in the face of delayed destructors.
-
tye
(but my friends call me "Tye")
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Several people have been talking about Perl6 not using reference counting. I've also heard that they want Perl6 to work with the Java Virtual Machine which won't support reference counting.
In my research, I find that the only way to get timely destructors (other than the near trivial case of lexical variables that you never take a reference of) is via reference counting.
In C++, timely destructors for lexical variables (where "taking a reference" does not cause the variable to live longer) is almost enough. In Perl, having timely destructors only for lexical variables would make certain hard problems that are easy to solve in Perl 5 become extremely hard in Perl 6.
It would boil down to building your own reference counting system on top of Perl. And anyone who has done much work with C++ knows that bolting on "ref-counted poiners" really sucks compared to native timely destructors.
The other risk with a new garbage collection system in Perl 6 is that destructors may not be well-ordered either. That is, if $a has a reference to $b, you want $a to get destroyed _before_ $b. I can't recall if the garbage collection systems under consideration are able to ensure that.
But I haven't heard any news on this since I posted the node you replied to.
Um, so, sorry, no new resources.
-
tye
(but my friends call me "Tye")
| [reply] [Watch: Dir/Any] |
|
The parrot people have gone to a lot of effort to ensure that destructors will get called at the right time, even if the memory isn't neccessarly freed immedetly.
As to how exactly this is going to happen, I'm not clear on the details... both because I don't have the background or the inclination to learn it, and because (last I looked) they weren't ironed out yet.
Thanks,
James Mastros,
Just Another Perl Scribe
| [reply] [Watch: Dir/Any] |
Re: Perl 6
by mirod (Canon) on Nov 02, 2000 at 17:27 UTC
|
There are also talks to create a translator, based on
the Perl 5 interpreter I would guess, that would take
a Perl 5 script and spit out a Perl 6 one, by "just"
converting modified constructs (such as tests on
system returning 0).
In any case plenty of cool projects for Larry, Damian...
| [reply] [Watch: Dir/Any] |
Re: Perl 6
by swiftone (Curate) on Nov 02, 2000 at 19:24 UTC
|
I think it's good that they're willing to throw away problem issues rather than to try to work around them (Working around them in later Perl 5 versions is good,
it builds stability. Keeping the crud in Perl6 is stupidity).
As far as I can tell, Perl6 is (will be) to Perl5 as C++ is to C (not in terms of functionality, but in terms of...oh, nevermind. But it's cool).
I'm looking forward to some of the byte-code translations and some of the syntax improvements. (Let's make Perl scripts shorter yet!)
| [reply] [Watch: Dir/Any] |
Re: Perl 6
by Nitsuj (Hermit) on Jul 18, 2001 at 08:58 UTC
|
I think that this is actually a good thing.
To read the FAQ, one would come across a quote saying that
perl, as it stands, cannot be reduced to BNF. This is what
we in academics call a "bad thing"(tm). Of course, this is similar to the arguments that make C++ "bad," which is not to say that it is bad, but that it could be "better."
If they rewrite perl from the ground up, they can plan the grammar and semantics
to be more uniform and correct, which will only help the
language in the long run, and guarantee it a place in future
useage. Perl has also developed in ways that require the next
development to sort of regroup and bring the code a bit more together.
The way I see it, perl is a great language, and Larry Wall
hasn't done us wrong yet. This can only be a good thing. Besides
this sort of thing happens often as the needs of programmers change.
There is old Ada and Ada95, a hundred cousins of LISP, and so forth.
Change is inevitable, and this can only make a good thing better.
Just Another Perl Backpacker | [reply] [Watch: Dir/Any] |
Re: Perl 6
by IraTarball (Monk) on Jan 15, 2002 at 03:39 UTC
|
I'm a little late to the party, but I don't think the
problem of compatability will be as bad as you think. In
the first Apocalypse Larry says
"..the default in the main program (and in one liners) is Perl 5..."
It isn't clear yet what will clearly declare a program as Perl 6. He suggests maybe a 'use 6.0;' pragma or a more general 'use Policy;' pragma, but he left it up in the air. The section of Apocalypse one on "Keep Perl free of constraints" has some more on this and Larry seems completely aware of the fact that it's a pain in the ass to port scripts. Not to mention all the one liners that have made thier way into shell scripts.
Tye's comment on garbage collection sounds like much more of a concern to me.
Ira,
"So... What do all these little arrows mean?"
~unknown | [reply] [Watch: Dir/Any] |
Re: Perl 6
by Fastolfe (Vicar) on Nov 02, 2000 at 20:53 UTC
|
Given that Perl 6 is meant to have 'meta-language' support, in that the interpreter can be capable of parsing just about anything written for it, turning it into a neutral state, and outputting things in various forms, I suspect Perl 5 (and even Perl 4) syntax will be supported "natively". All someone would have to do is write (or modify) a parser. | [reply] [Watch: Dir/Any] |