repository Perl kurila, where Gerard posts a Perl7 idea-of-concept patch

[Gerard Goossen]

I previous posted a Unicode-handling patch and suggested some
development changes. Since then I have made more
changes. Because posting 1MB patches isn't
very convenient I have made a public accessible repository
with my branch.

Currently the experimental branch, Perl kurila, contains:
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)

Except from the Unicode change, the others are obvious, in the sense
that they were already best practices. And probably are good example
of where I would like Perl development to go.
Because I think there was still some misconception about what my Unicode
patch does, I have attached some documentation explaining the new
Unicode handling.


You can obtain the repository using:

git clone git://dev.tty.nl/perl/

The two important branches in the repository are:
- bleadperl
this branch corresponds to bleadperl, I have to run a
script to update it so it might be a few changes behind,
otherwise it should be identical to bleadperl
- gerard (the default branch)
Very experimental branch. Think of it as a suggestion for
Perl7 development. Contains changes which are often not
backward compatible. I use the name Perl kurila in the branch
to refer to the the latest version. Referring to it means you
refer to a moving target.
I try to backport to bleadperl the changes which are backwards
compatibel with Perl 5.


Gerard Goossen, tty.nl


ps. I use git because I have experience
with it and Sam Vilain wrote some very nice scripts which can keep
track of bleadperl in git.
See http://www.kernel.org/pub/software/scm/git/docs/tutorial.html for an
introduction to git.
The Debian git package is called git-core.

pps. Subject by Harm

[Sam Vilain]

Wow. Firstly, thanks Gerard for successfully trying this out. You
called my scripts "nice", which indicates to me that you clearly didn't
read them ;). Nonetheless your work will be an excellent source for
auditing the correctness of mine.

Just beware that there are now *three* people publishing their
conversions of the Perl perforce history, and two of them maintain their
own forks atop of them:

This one:
git://dev.tty.nl/perl/
- publishing "blead", Change 1 .. Change 30371 - converted by my
scripts. Change 1 is the first commit.
- publishing "Gerard's Perl7" based on recent blead.

Alexey's:
git://git.altlinux.org/people/at/packages/perl.git
- converted using a "proper" p4 connection (I assume)
- perl 5.8.0 is the first commit
- Changes 17649 .. 30364 of maint as head "5.8"
- Change 17639 .. 29402 of blead as "5.9"
- ALT linux Perl branch, branched from Change 28854 (5.8.8+a bit) as
"master"

git://git.catalyst.net.nz/git/perl.git
http://git.catalyst.net.nz/git/perl.git
- publishing "restorical" (perl 1 .. perl 5.003_07) - converted by
custom scripts from various archives on history.perl.org
- publishing all Perforce changes as "p4-XXX", where XXX is a simple
translation of the perforce depot path. Change 1 is based atop of the
perl 5.003 commit in the restorical branch.
- re-publishing both Alexey's and Gerard's branches; see
http://git.catalyst.net.nz/gitweb?p=perl.git;a=summary

Right now none of these contain the filelog metadata.

This still isn't ready for general consumption - early adopters only.
I'm still working on revamping the import scripts to make a much more
pristine converstion than was previously possible, including the filelog
data, grafting as much of Chip's pumpkin era onto Change 18 as I can,
and then I'll re-base everyone's forks on top of that and hopefully they
will be more than happy to replace their published repositories with the
cleaned up one. It should end up a little smaller than the 200MB it is
currently, as well. Until this clean-up is done, don't try to merge
between the branches; cherry-pick instead.

Sam.

Post by Gerard Goossen
I previous posted a Unicode-handling patch and suggested some
development changes. Since then I have made more
changes. Because posting 1MB patches isn't
very convenient I have made a public accessible repository
with my branch.
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)
Except from the Unicode change, the others are obvious, in the sense
that they were already best practices. And probably are good example
of where I would like Perl development to go.
Because I think there was still some misconception about what my Unicode
patch does, I have attached some documentation explaining the new
Unicode handling.
git clone git://dev.tty.nl/perl/
- bleadperl
this branch corresponds to bleadperl, I have to run a
script to update it so it might be a few changes behind,
otherwise it should be identical to bleadperl
- gerard (the default branch)
Very experimental branch. Think of it as a suggestion for
Perl7 development. Contains changes which are often not
backward compatible. I use the name Perl kurila in the branch
to refer to the the latest version. Referring to it means you
refer to a moving target.
I try to backport to bleadperl the changes which are backwards
compatibel with Perl 5.
Gerard Goossen, tty.nl
ps. I use git because I have experience
with it and Sam Vilain wrote some very nice scripts which can keep
track of bleadperl in git.
See http://www.kernel.org/pub/software/scm/git/docs/tutorial.html for an
introduction to git.
The Debian git package is called git-core.
pps. Subject by Harm
------------------------------------------------------------------------
=head2 Characters represented by Code points represented by Bytes
According to the Unicode Standard: I<"Characters are the abstract
representations of the smallest components of written language that
have semantic value.">
The Unicode meaning of character is often B<not> the meaning used by
Perl. Characters used to be represented by bytes, for example the C type
C<char> is a byte, or in Perl 5 the function C<chr>, always returned a
byte for values below 256. The Unicode definition of character is also
B<not> the idea of character that most people have.
Code points are numeric values representing Unicode characters. Because
this is normally the only represented, and the term is less ambiguous
then characters, this is the preferred term.
Perl kurila uses the UTF-8 (or UTF-EBCDIC) encoding to store code
points in bytes or 8-bit code units using Unicode terms. Multiple
bytes may be needed to store a single code point.
=head2 Byte and Code points Semantics
Perl kurila uses the lexical scope to determine whether to use byte semantics
or code point semantics. The C<bytes> pragma forces byte semantics, the
C<utf8> pragma forces code points semantics. For compatibility reasons
the default behaviour is byte semantics, but this might change.
The C<bytes> pragma will always, regardless of platform, force byte
semantics in a particular lexical scope. See L<bytes>.
The C<utf8> pragma will force code points semantics in a particular
lexical scope. See L<utf8>. The C<utf8> pragma also set that the
input of the parser is UTF-8. The pragma to force code points semantics
might be changed to C<codepoints>.
Under code points semantics, many operations that formerly operated on
bytes now operate on code points. A code point in Perl is
logically just a number ranging from 0 to 2**31 or so. Larger
code points may encode into longer sequences of bytes internally, but
this internal detail is mostly hidden for Perl code.
=head2 Porting code from perl-5.8.x
=over 4
=item *
Deciding code points or byte semantics
Perl kurila uses the lexical scope to determine to use code points or
byte semantics. Decide which should be used and add the C<utf8> or
C<bytes> pragma accordingly. Currently the default is byte semantics,
but this might change, so it is strongly advised to make the choice
explicit using the C<utf8> or C<bytes> pragmas.
=item *
Handling latin1 text
Latin1 text should be decode upon reading and encoded upon
writing. Using either C<Encode::decode> or using an
C<":encoding(latin1)"> layer.
=item *
Not using the UTF-8 flag
There is no UTF-8 flag anymore, so there is no need to preserve or set
it. Functions to modify the flag have been removed or give an error.
=back
=cut

[Gerard Goossen]

Sure the scripts had some signs of organic growth, but in general I
found them very clear in what was happening.
But they didn't work flawless, probably because I didn't use them
properly.
My main goal was to track bleadperl, not to get the whole history. So I
modified you scripts a bit to do this.
I added a '--p4branch=perl' option to make-commit-nobranches.pl to only
checkout the p4 'perl' subdirectory.
Attached is the patch adding the --p4branch options, and some other
minor fixes/extensions.

I'll be happy to re-base everything when there is a stable cleaned up
base.


Gerard Goossen

Post by Sam Vilain
Wow. Firstly, thanks Gerard for successfully trying this out. You
called my scripts "nice", which indicates to me that you clearly didn't
read them ;). Nonetheless your work will be an excellent source for
auditing the correctness of mine.
Just beware that there are now *three* people publishing their
conversions of the Perl perforce history, and two of them maintain their
git://dev.tty.nl/perl/
- publishing "blead", Change 1 .. Change 30371 - converted by my
scripts. Change 1 is the first commit.
- publishing "Gerard's Perl7" based on recent blead.
git://git.altlinux.org/people/at/packages/perl.git
- converted using a "proper" p4 connection (I assume)
- perl 5.8.0 is the first commit
- Changes 17649 .. 30364 of maint as head "5.8"
- Change 17639 .. 29402 of blead as "5.9"
- ALT linux Perl branch, branched from Change 28854 (5.8.8+a bit) as
"master"
git://git.catalyst.net.nz/git/perl.git
http://git.catalyst.net.nz/git/perl.git
- publishing "restorical" (perl 1 .. perl 5.003_07) - converted by
custom scripts from various archives on history.perl.org
- publishing all Perforce changes as "p4-XXX", where XXX is a simple
translation of the perforce depot path. Change 1 is based atop of the
perl 5.003 commit in the restorical branch.
- re-publishing both Alexey's and Gerard's branches; see
http://git.catalyst.net.nz/gitweb?p=perl.git;a=summary
Right now none of these contain the filelog metadata.
This still isn't ready for general consumption - early adopters only.
I'm still working on revamping the import scripts to make a much more
pristine converstion than was previously possible, including the filelog
data, grafting as much of Chip's pumpkin era onto Change 18 as I can,
and then I'll re-base everyone's forks on top of that and hopefully they
will be more than happy to replace their published repositories with the
cleaned up one. It should end up a little smaller than the 200MB it is
currently, as well. Until this clean-up is done, don't try to merge
between the branches; cherry-pick instead.
Sam.

Post by Gerard Goossen
I previous posted a Unicode-handling patch and suggested some
development changes. Since then I have made more
changes. Because posting 1MB patches isn't
very convenient I have made a public accessible repository
with my branch.
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)
Except from the Unicode change, the others are obvious, in the sense
that they were already best practices. And probably are good example
of where I would like Perl development to go.
Because I think there was still some misconception about what my Unicode
patch does, I have attached some documentation explaining the new
Unicode handling.
git clone git://dev.tty.nl/perl/
- bleadperl
this branch corresponds to bleadperl, I have to run a
script to update it so it might be a few changes behind,
otherwise it should be identical to bleadperl
- gerard (the default branch)
Very experimental branch. Think of it as a suggestion for
Perl7 development. Contains changes which are often not
backward compatible. I use the name Perl kurila in the branch
to refer to the the latest version. Referring to it means you
refer to a moving target.
I try to backport to bleadperl the changes which are backwards
compatibel with Perl 5.
Gerard Goossen, tty.nl
ps. I use git because I have experience
with it and Sam Vilain wrote some very nice scripts which can keep
track of bleadperl in git.
See http://www.kernel.org/pub/software/scm/git/docs/tutorial.html for an
introduction to git.
The Debian git package is called git-core.
pps. Subject by Harm
------------------------------------------------------------------------
=head2 Characters represented by Code points represented by Bytes
According to the Unicode Standard: I<"Characters are the abstract
representations of the smallest components of written language that
have semantic value.">
The Unicode meaning of character is often B<not> the meaning used by
Perl. Characters used to be represented by bytes, for example the C type
C<char> is a byte, or in Perl 5 the function C<chr>, always returned a
byte for values below 256. The Unicode definition of character is also
B<not> the idea of character that most people have.
Code points are numeric values representing Unicode characters. Because
this is normally the only represented, and the term is less ambiguous
then characters, this is the preferred term.
Perl kurila uses the UTF-8 (or UTF-EBCDIC) encoding to store code
points in bytes or 8-bit code units using Unicode terms. Multiple
bytes may be needed to store a single code point.
=head2 Byte and Code points Semantics
Perl kurila uses the lexical scope to determine whether to use byte semantics
or code point semantics. The C<bytes> pragma forces byte semantics, the
C<utf8> pragma forces code points semantics. For compatibility reasons
the default behaviour is byte semantics, but this might change.
The C<bytes> pragma will always, regardless of platform, force byte
semantics in a particular lexical scope. See L<bytes>.
The C<utf8> pragma will force code points semantics in a particular
lexical scope. See L<utf8>. The C<utf8> pragma also set that the
input of the parser is UTF-8. The pragma to force code points semantics
might be changed to C<codepoints>.
Under code points semantics, many operations that formerly operated on
bytes now operate on code points. A code point in Perl is
logically just a number ranging from 0 to 2**31 or so. Larger
code points may encode into longer sequences of bytes internally, but
this internal detail is mostly hidden for Perl code.
=head2 Porting code from perl-5.8.x
=over 4
=item *
Deciding code points or byte semantics
Perl kurila uses the lexical scope to determine to use code points or
byte semantics. Decide which should be used and add the C<utf8> or
C<bytes> pragma accordingly. Currently the default is byte semantics,
but this might change, so it is strongly advised to make the choice
explicit using the C<utf8> or C<bytes> pragmas.
=item *
Handling latin1 text
Latin1 text should be decode upon reading and encoded upon
writing. Using either C<Encode::decode> or using an
C<":encoding(latin1)"> layer.
=item *
Not using the UTF-8 flag
There is no UTF-8 flag anymore, so there is no need to preserve or set
it. Functions to modify the flag have been removed or give an error.
=back
=cut

[Alexey Tourbin]

Post by Sam Vilain
git://git.altlinux.org/people/at/packages/perl.git
- converted using a "proper" p4 connection (I assume)

Nope, I didn't use any p4 connection. I used ONLY patches from
rsync activestate.com archive. The import looks sane because I spent
some time to develop scripts that sanitize the patches and, roughly
speaking, double check everything that is possible to check (without
real p4 connection).

Post by Sam Vilain
- perl 5.8.0 is the first commit

I believe I couldn't find earlier changes in activestate.com rsync
archive. On the other hand, perl is not that small, so I felt like
that starting with 5.8.0 is reasonable tradeoff (well, for me).

Post by Sam Vilain
- Changes 17649 .. 30364 of maint as head "5.8"
- Change 17639 .. 29402 of blead as "5.9"
- ALT linux Perl branch, branched from Change 28854 (5.8.8+a bit) as
"master"

[Demerphq]

Post by Alexey Tourbin

Post by Sam Vilain
git://git.altlinux.org/people/at/packages/perl.git
- converted using a "proper" p4 connection (I assume)

Nope, I didn't use any p4 connection. I used ONLY patches from
rsync activestate.com archive. The import looks sane because I spent
some time to develop scripts that sanitize the patches and, roughly
speaking, double check everything that is possible to check (without
real p4 connection).

Now theres a wheel that seems to get reinvented a lot*. It would be
nice if these various scripts were all collected somewhere. Like maybe
in the perl distro itself.

Even providing documentation for the various README's/pod files would
be a good start.

Cheers,
Yves
* I think i know of four or five seperate people and implementations
of this, excluding my own meagre and crappy synchronization scripts.

[Alexey Tourbin]

Post by Demerphq

Post by Alexey Tourbin

Post by Sam Vilain
git://git.altlinux.org/people/at/packages/perl.git
- converted using a "proper" p4 connection (I assume)

Nope, I didn't use any p4 connection. I used ONLY patches from
rsync activestate.com archive. The import looks sane because I spent
some time to develop scripts that sanitize the patches and, roughly
speaking, double check everything that is possible to check (without
real p4 connection).

Now theres a wheel that seems to get reinvented a lot*. It would be
nice if these various scripts were all collected somewhere.

git://git.altlinux.org/people/at/packages/APC.git

Basically I download patches along with source trees, apply the patches
that's not been applied; and check that the tree after applying the
patches is (almost) exactly the same as prisitine source tree. (There
are \r\n issues; I make automatic \r\n -> \n conversion.)

Post by Demerphq
* I think i know of four or five seperate people and implementations
of this, excluding my own meagre and crappy synchronization scripts.

Mine are crappy, too. Sometimes they require hand-hacking, like empty
changes (without diff) or changes which affect both //depot/perl and
//depot/maint-5.8. This is why I can't run these scripts as cron jobs.

[Alexey Tourbin]

Post by Gerard Goossen
git://dev.tty.nl/perl/
git://git.altlinux.org/people/at/packages/perl.git
git://git.catalyst.net.nz/git/perl.git
Right now none of these contain the filelog metadata.

What is filelog metadata?

[Alexey Tourbin]

Post by Sam Vilain
git://git.catalyst.net.nz/git/perl.git
http://git.catalyst.net.nz/git/perl.git

I've just fetched p4-perl branch at change 30900. Looks like you
never checked that actually it yields zero diff against prisitine
snapshot! Guys, don't use it, at least for now. It really differs.

$ git-diff -b --stat 20c3dd0937576a89adaf23ec22ca33e7a76527a9..p4-perl
Artistic | 2 +-
Changes.Conf | 2686 ++++++++++++++++++++
Copying | 6 +-
cflags.SH | 2 +-
config_H | 1582 ++++++++++++
configure | 108 +
ext/B/t/b.t | 2 +-
ext/Cwd/Changes | 13 -
ext/DynaLoader/DynaLoader.pm | 593 +++++
ext/DynaLoader/dl_os2.xs | 188 ++
ext/File/Glob/Glob.pm | 2 +-
ext/FileHandle/FileHandle.pm | 467 ++++
ext/FileHandle/FileHandle.xs | 177 ++
ext/FileHandle/Makefile.PL | 7 +
ext/ODBM_File/Makefile.PL | 2 +-
ext/SDBM_File/sdbm/dba.c | 15 +-
ext/SDBM_File/sdbm/dbd.c | 19 +-
ext/SDBM_File/sdbm/dbe.c | 34 +-
ext/SDBM_File/sdbm/dbu.c | 19 +-
ext/SDBM_File/sdbm/hash.c | 5 +-
ext/SDBM_File/sdbm/pair.h | 12 -
ext/SDBM_File/sdbm/readme.ps | 2225 ++++++++++++++++
ext/SDBM_File/sdbm/sdbm.3 | 133 +-
ext/SDBM_File/sdbm/util.c | 7 +-
ext/Safe/Makefile.PL | 7 +
ext/Safe/Safe.pm | 670 +++++
ext/Safe/Safe.xs | 131 +
ext/Storable/t/sig_die.t | 45 +
ext/re/t/regop.t | 2 +-
ext/util/extliblist | 155 ++
hints/3b1.sh | 4 +-
hints/aux.sh | 20 +
hints/convexos.sh | 8 +
hints/dnix.sh | 1 +
hints/irix_6_2.sh | 28 +
hints/mips.sh | 4 +-
hints/sco_2_3_3.sh | 4 +-
hints/sco_2_3_4.sh | 4 +-
hints/sunos_4_0.sh | 1 -
interp.sym | 152 ++
lib/CGI.pm | 9 +-
lib/CGI/Changes | 6 -
lib/CGI/Cookie.pm | 4 +-
lib/CPANPLUS/Backend.pm | 1065 +--------
lib/CPANPLUS/Backend/RV.pm | 148 +--
lib/CPANPLUS/Configure.pm | 605 +-----
lib/CPANPLUS/Dist/Base.pm | 253 +--
lib/CPANPLUS/Dist/Sample.pm | 20 +-
lib/CPANPLUS/Error.pm | 205 +--
lib/CPANPLUS/Hacking.pod | 146 +-
lib/CPANPLUS/Internals/Constants/Report.pm | 361 +---
lib/CPANPLUS/Internals/Extract.pm | 240 +--
lib/CPANPLUS/Internals/Fetch.pm | 376 +---
lib/CPANPLUS/Internals/Search.pm | 320 +---
lib/CPANPLUS/Module/Author/Fake.pm | 84 +-
lib/CPANPLUS/Module/Fake.pm | 90 +-
lib/CPANPLUS/Module/Signature.pm | 69 +-
lib/CPANPLUS/Selfupdate.pm | 451 +----
lib/CPANPLUS/Shell.pm | 318 +---
lib/CPANPLUS/Shell/Classic.pm | 1240 +---------
lib/CPANPLUS/Shell/Default/Plugins/Remote.pm | 192 +--
lib/CPANPLUS/inc.pm | 526 +----
.../t/dummy-CPAN/authors/id/E/EU/EUNOXS/CHECKSUMS | 34 +-
.../authors/id/E/EU/EUNOXS/CHECKSUMS | 34 +-
.../authors/id/M/MB/MBNOXS/CHECKSUMS | 24 +-
.../id/M/MB/MBNOXS/Foo-Bar-0.01.tar.gz.packed | 39 +-
lib/File/Spec.pm | 2 +-
lib/File/Spec/Cygwin.pm | 8 +-
lib/File/Spec/Unix.pm | 19 +-
lib/Module/Load/t/to_load/config_file | 2 +-
lib/chat2.inter | 495 ++++
lib/find.pl | 85 +-
lib/finddepth.pl | 83 +-
lib/open2.pl | 58 +-
lib/open3.pl | 110 +-
lib/splain | 503 ++++
lib/timelocal.pl | 109 +-
myconfig | 43 +
opcode.h | 121 +-
opcode.pl | 41 +-
opnames.h | 524 ++--
os2/README | 229 ++
os2/README.old | 529 ++++
os2/diff.db_file | 15 +
os2/notes | 28 +
perlio.c | 2 -
perlsh | 2 +-
perly.c.diff | 423 +++
pod/perldiag.pod | 14 -
pod/perlovl.pod | 15 +
pp.sym | 24 +-
pp_proto.h | 24 +-
pp_sys.c | 8 -
t/TEST | 2 +-
t/lib/Test/Simple/sample_tests/too_few_fail.plx | 2 +-
t/lib/safe.t | 96 +
t/lib/warnings/pp_sys | 26 -
t/op/chdir.t | 3 -
t/op/overload.t | 267 ++
t/re_tests | 3 +
utils/cpanp-run-perl.PL | 55 +-
vms/Makefile | 1374 ++++++++++
vms/config.vms | 1647 ++++++++++++
vms/descrip.mms | 1525 +++++++++++
vms/ext/Stdio/0README.txt | 23 +-
vms/fndvers.com | 113 +
vms/mms2make.pl | 6 +-
vms/myconfig.com | 10 +-
x2p/a2p.man | 183 ++
x2p/handy.h | 172 ++
x2p/s2p.man | 92 +
111 files changed, 18048 insertions(+), 7468 deletions(-)
$

Here the 20c3dd0937576a89adaf23ec22ca33e7a76527a9 commit from my 5.9
branch is guaranteed to (almost) exactly match 30900 snapshot.
("Almost" means except for \r\n -> \n transition; also note that
I used git-diff with -b option).

There's no Changes.Conf in perl-current snapshot anyway.

And here is how my 5.9 branch differs from perl-current snapshot:

$ git-checkout 5.9
$ diff --exclude .git --exclude .patch -ur -ab . ../APC/perl-current/
$

[H.Merijn Brand]

Post by Gerard Goossen
I previous posted a Unicode-handling patch and suggested some
development changes. Since then I have made more
changes. Because posting 1MB patches isn't
very convenient I have made a public accessible repository
with my branch.
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)
Except from the Unicode change, the others are obvious, in the sense

"obvious"? the C<format> keyword removed? That is one of the reasons I stick
to perl5. I need it. I use it. Often.

Post by Gerard Goossen
that they were already best practices. And probably are good example
of where I would like Perl development to go.
Because I think there was still some misconception about what my Unicode
patch does, I have attached some documentation explaining the new
Unicode handling.
git clone git://dev.tty.nl/perl/
- bleadperl
this branch corresponds to bleadperl, I have to run a
script to update it so it might be a few changes behind,
otherwise it should be identical to bleadperl
- gerard (the default branch)
Very experimental branch. Think of it as a suggestion for
Perl7 development. Contains changes which are often not
backward compatible. I use the name Perl kurila in the branch
to refer to the the latest version. Referring to it means you
refer to a moving target.
I try to backport to bleadperl the changes which are backwards
compatibel with Perl 5.
Gerard Goossen, tty.nl
ps. I use git because I have experience
with it and Sam Vilain wrote some very nice scripts which can keep
track of bleadperl in git.
See http://www.kernel.org/pub/software/scm/git/docs/tutorial.html for an
introduction to git.
The Debian git package is called git-core.
pps. Subject by Harm

[Rafael Garcia-Suarez]

Post by H.Merijn Brand

Post by Gerard Goossen
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)
Except from the Unicode change, the others are obvious, in the sense

"obvious"? the C<format> keyword removed? That is one of the reasons I stick
to perl5. I need it. I use it. Often.

And I use the indirect object syntax quite often... (every time I
write "print STDERR $foo" for example). Apart from loosing the ability
to run lots of CPAN code, I see no points in those changes... remember
that Perl 6 will be able to run Perl 5 code.

[Gerard Goossen]

Post by Rafael Garcia-Suarez

Post by H.Merijn Brand

Post by Gerard Goossen
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)
Except from the Unicode change, the others are obvious, in the sense

"obvious"? the C<format> keyword removed? That is one of the reasons I stick
to perl5. I need it. I use it. Often.

And I use the indirect object syntax quite often... (every time I
write "print STDERR $foo" for example). Apart from loosing the ability
to run lots of CPAN code, I see no points in those changes... remember
that Perl 6 will be able to run Perl 5 code.

"print STDERR $foo" is NOT indirect object syntax. And it still works.


About indirect object syntax, from perlobj: "[...] you still have the
same potential problem if there happens to be a function named move in
the current package. The -> notation suffers from neither of these
disturbing ambiguities, so we recommend you use it exclusively. However,
you may still end up having to read code using the indirect object notation,
so it's important to be familiar with it."

One of the ideas is to remove those unfortunate features. And yes that
might break some CPAN code.


Gerard Goossen

[Rafael Garcia-Suarez]

Post by Gerard Goossen
"print STDERR $foo" is NOT indirect object syntax. And it still works.

Well, it sure follows the same pattern. (Note that I strongly dislike
indirect object syntax myself.)

Post by Gerard Goossen
One of the ideas is to remove those unfortunate features. And yes that
might break some CPAN code.

As some people wiser than me have said, CPAN is perl's killer app. I
should have made that more clear in my previous terse mail... but one
of the most important points in making a new perl release is to not
break CPAN. Or only the part of it that abuses bugs :) That's why I
made that remark about Perl 6 : while it changes Perl in much more
profound ways than anything based on Perl 5 could achieve, it will
still have a Perl 5 compatibility mode. You can't afford to loose
CPAN, because nobody is going to rewrite CPAN for you...

[Demerphq]

Post by Rafael Garcia-Suarez

Post by Gerard Goossen
One of the ideas is to remove those unfortunate features. And yes that
might break some CPAN code.

As some people wiser than me have said, CPAN is perl's killer app. I
should have made that more clear in my previous terse mail... but one
of the most important points in making a new perl release is to not
break CPAN. Or only the part of it that abuses bugs :) That's why I
made that remark about Perl 6 : while it changes Perl in much more
profound ways than anything based on Perl 5 could achieve, it will
still have a Perl 5 compatibility mode. You can't afford to loose
CPAN, because nobody is going to rewrite CPAN for you...

I just wanted to say that I agree with this pretty much, except that I
dont believe it should apply to XS code that violates the documented
API in perlapi/perlguts.

I actually discussed this with Nicholas at the GPW and he pointed out
that it hasnt always been clear what the API has been, so there is
some difficulty there, but IMO our back-compat guarantees should be
restricted to pure perl code only. Breaking XS is a potentially
necessary part of progress in my eyes.

Yves

[Jesse]

Post by Gerard Goossen
About indirect object syntax, from perlobj: "[...] you still have the
same potential problem if there happens to be a function named move in
the current package. The -> notation suffers from neither of these
disturbing ambiguities, so we recommend you use it exclusively. However,
you may still end up having to read code using the indirect object notation,
so it's important to be familiar with it."
One of the ideas is to remove those unfortunate features. And yes that
might break some CPAN code.

As an exercise, it might be worth seeing just how much of CPAN uses

"my $x = new Some::Class::Name;"

Your feelings about "unfortunate features" don't really mesh well with
mine. One of the things Audrey Tang and I have spent a lot of the last
six months doing is exploring ways to bend (abuse) the interpreter to
allow us to build gorgeous domain specific languages that are also pure,
valid Perl. Walking through and removing features that you don't like
is a very good way to ensure that applications like RT and frameworks
like Jifty are never ported to your fork of Perl.

If you're going to build something that's similar to, but intentionally
not compatible with Perl, don't call it Perl. It's going to hurt users.
The world of gemology provides many possible names for things that might
be more reasonable.

Do tell me when you get rid of tie() and formats, though.

Jesse

[Sam Vilain]

Post by Jesse
If you're going to build something that's similar to, but
intentionally not compatible with Perl, don't call it Perl. It's going
to hurt users.
The world of gemology provides many possible names for things that might
be more reasonable.

Agreed; I hope my republishing isn't seen as endorsement of this
decision. I consider this to be being published into a Perl6-like
namespace such as "perl-7-kurila" or perhaps "Perl7-*-kurila". It seems
odd to fork Perl 5 and place it into your namespace as Perl 7, but hey,
it's your namespace so who am I to judge, and more forks can mean more
chance for cross-pollenation of ideas anyway.

If this is being published as "Perl 7", then in my eyes you're stomping
on Larry's artistic license, so you'd need to collapse the license files
to only mention the GPL. But I'm guessing that's not really your intention.

Sam.

[Michael G Schwern]

Post by Jesse
Walking through and removing features that you don't like
is a very good way to ensure that applications like RT and frameworks
like Jifty are never ported to your fork of Perl.

I agree with Jesse, as an application developer there is not enough benefit in your proposed fork to make me consider losing CPAN. Hell, I have enough trouble moving commercial apps from 5.6 to 5.8. As a CPAN author I do *not* want to have to maintain a Perl 5 and a Perl 7 version. And then a Perl 8 and a Perl 9...

OTOH not everything is intended to be released in production. It would be interesting to see what would happen if you removed some of the hairier features of Perl and jiggered the internals to take advantage of their absence. Indirect object syntax complicates parsing. tie() (and probably object overloading) winds its way through everything. Maintaining the current XS interface can hold back all sorts of interesting changes. Threading, unicode... all sorts of complicated subsystems could be torn out and completely redone to see what happens. Once that's done and the benefits are known they can be weighed against any loss of compatibility, or a clever compatibility plan can be worked out.

Just don't plant a flag at the start and call it the next Perl when you're still at the bottom of the mountain. [1]


[1] Larry can get away with this because he's Larry and its his damn language. He's also got a plan for backwards compat.

[Gerard Goossen]

Post by Michael G Schwern

Post by Jesse
Walking through and removing features that you don't like
is a very good way to ensure that applications like RT and frameworks
like Jifty are never ported to your fork of Perl.

I agree with Jesse, as an application developer there is not enough benefit in your proposed fork to make me consider losing CPAN. Hell, I have enough trouble moving commercial apps from 5.6 to 5.8. As a CPAN author I do *not* want to have to maintain a Perl 5 and a Perl 7 version. And then a Perl 8 and a Perl 9...
OTOH not everything is intended to be released in production. It would be interesting to see what would happen if you removed some of the hairier features of Perl and jiggered the internals to take advantage of their absence. Indirect object syntax complicates parsing. tie() (and probably object overloading) winds its way through everything. Maintaining the current XS interface can hold back all sorts of interesting changes. Threading, unicode... all sorts of complicated subsystems could be torn out and completely redone to see what happens. Once that's done and the benefits are known they can be weighed against any loss of compatibility, or a clever compatibility plan can be worked out.
Just don't plant a flag at the start and call it the next Perl when you're still at the bottom of the mountain. [1]

I agree. If my branch was interpreted as a finished proposal
for Perl 7, then that is my fault, it was meant merely as an initial
step.
I want to climb the mountain.

Most of the hairier features, not only make the backend must more
complicated, they also complicate working with Perl. Having code with
ties, with indirect object syntax, without use strict, are much more difficult to
maintain, read or port to a new version. Removing them will break some
existing code, but at least they will clearly broken, and not continue
working almost correctly, as you mentioned that you already have
problems moving from 5.6 to 5.8, and so do I. Therefore I think it is
better to declare a new major version, which clearly breaks on some points,
then try to make an almost compatible version.


Gerard Goossen

[Chromatic]

Therefore I think it is better to declare a new major version

Last I checked, the one person who gets to decide how to name Perl versions is
still working on Perl 6. Seems a bit rude to me to leapfrog Larry to stick
this particular flag in the ground.

What if you took "Perl" out of the name?

-- c

[Rafael Garcia-Suarez]

Post by Chromatic

Therefore I think it is better to declare a new major version

Last I checked, the one person who gets to decide how to name Perl versions is
still working on Perl 6. Seems a bit rude to me to leapfrog Larry to stick
this particular flag in the ground.
What if you took "Perl" out of the name?

I agree entirely. In the past, forks or reimplentations attempts of
Perl 5 have used non-Perl names. Topaz, for example. This was
necessary to make clear that they were experiments, not ready for
production, and not related to the main product line. Using "Perl 7"
for an experiment is just confusing people out there and will
certainly have a very negative impact on how Perl's development is
perceived.

(Moreover I think "Perl 7" is a silly name. It's not an improvement
over Perl 6, so why use a number > 6 ? actually it's not even an
improvement over Perl 5, since it's Perl 5 with less features...)

[Sam Vilain]

Post by Rafael Garcia-Suarez
I agree entirely. In the past, forks or reimplentations attempts of
Perl 5 have used non-Perl names. Topaz, for example. This was
necessary to make clear that they were experiments, not ready for
production, and not related to the main product line. Using "Perl 7"
for an experiment is just confusing people out there and will
certainly have a very negative impact on how Perl's development is
perceived.
(Moreover I think "Perl 7" is a silly name. It's not an improvement over Perl 6, so why use a number > 6 ? actually it's not even an improvement over Perl 5, since it's Perl 5 with less features...)

"Perl 7" is only a correct name for this if you've already done the 'use
namespace XXX' or contextually semantic equivalent, where XXX is the
namespace under which Gerard is placing his implementation. All's fair
if you predeclare.

Of course when you're posting as yourself to a mailing list, there is
something of a "with $self" implicitly in effect (to borrow semantics
from Pascal temporarily), so we should have no problem if everyone who
isn't Gerard refers to this as Perl-7-email:***@tty.nl

Like I said, it's a poor choice of namespace, given that people replying
later on people reading old posts might not have the capability for
date-sensitive namespace adjusting. My guess is that by the time that
"Perl-7-*" matches any releases originating from the line of succession
of the Pumpkin, that this is unlikely to be a problem.

Of course a less ambiguous namespace might solve these problems up front
- Gerard, how about a codename?

Sam.

[Gerard Goossen]

Post by Sam Vilain

Post by Rafael Garcia-Suarez
I agree entirely. In the past, forks or reimplentations attempts of
Perl 5 have used non-Perl names. Topaz, for example. This was
necessary to make clear that they were experiments, not ready for
production, and not related to the main product line. Using "Perl 7"
for an experiment is just confusing people out there and will
certainly have a very negative impact on how Perl's development is
perceived.
(Moreover I think "Perl 7" is a silly name. It's not an improvement over Perl 6, so why use a number > 6 ? actually it's not even an improvement over Perl 5, since it's Perl 5 with less features...)

"Perl 7" is only a correct name for this if you've already done the 'use
namespace XXX' or contextually semantic equivalent, where XXX is the
namespace under which Gerard is placing his implementation. All's fair
if you predeclare.
Of course when you're posting as yourself to a mailing list, there is
something of a "with $self" implicitly in effect (to borrow semantics
from Pascal temporarily), so we should have no problem if everyone who
Like I said, it's a poor choice of namespace, given that people replying
later on people reading old posts might not have the capability for
date-sensitive namespace adjusting. My guess is that by the time that
"Perl-7-*" matches any releases originating from the line of succession
of the Pumpkin, that this is unlikely to be a problem.
Of course a less ambiguous namespace might solve these problems up front
- Gerard, how about a codename?

I already use "kurila" in the documentation (or "Perl Kurila" when refering
to the language). And was actually a bit surprised by Sam already calling
the branch Perl 7. Although I hope we will end up there eventually.


Gerard

[Sam Vilain]

Post by Gerard Goossen

Post by Sam Vilain
"Perl 7" is only a correct name for this if you've already done the 'use
namespace XXX' or contextually semantic equivalent, where XXX is the
namespace under which Gerard is placing his implementation. All's fair
if you predeclare.
Of course when you're posting as yourself to a mailing list, there is
something of a "with $self" implicitly in effect (to borrow semantics
from Pascal temporarily), so we should have no problem if everyone who
Like I said, it's a poor choice of namespace, given that people replying
later on people reading old posts might not have the capability for
date-sensitive namespace adjusting. My guess is that by the time that
"Perl-7-*" matches any releases originating from the line of succession
of the Pumpkin, that this is unlikely to be a problem.
Of course a less ambiguous namespace might solve these problems up front
- Gerard, how about a codename?

I already use "kurila" in the documentation (or "Perl Kurila" when refering
to the language). And was actually a bit surprised by Sam already calling
the branch Perl 7. Although I hope we will end up there eventually.

I didn't call it "Perl7", the head is called "gerard/Perl7". So, kurila
it is and I'll rename those heads - but just realise the point I was
making was that it would not be unqualified "Perl 7" to most of us
without, well, widespread community approval, as judged by our
benevolent dictator.

You said you want to climb the mountain to the top of Perl 7, an
admirable goal, but you appear to be walking along a perpendicular road
towards a set of peaks off to the side, the ranges that feed PHP valley.
I bet it's a beautiful view from those mountains, and that Kurila Perl
would be a fine name for them. We don't know exactly where the top of
the Perl 7 mountain is, but we're fairly sure that we'll get a view to
spot it from the top of the gargantuan Perl 6. That's little dot in the
air near the top is Audrey hangliding in from Haskell crag. Look below,
that little hive of activity is the base camp, Jesse's there running the
kitchen, Larry's off leading the day-walkers and there's Patrick and co
laying the railway system. Sure there aren't any trains running yet, not
all the way to the top anyway.

Maybe one day Larry will look at the view from the top and look back
towards the Kurila ranges and dub it Perl 7. He's done crazier things in
the past. So by all means, climb!

Sam.

[Michael G Schwern]

Post by Sam Vilain
You said you want to climb the mountain to the top of Perl 7, an
admirable goal, but you appear to be walking along a perpendicular road
towards a set of peaks off to the side, the ranges that feed PHP valley.
I bet it's a beautiful view from those mountains, and that Kurila Perl
would be a fine name for them. We don't know exactly where the top of
the Perl 7 mountain is, but we're fairly sure that we'll get a view to
spot it from the top of the gargantuan Perl 6. That's little dot in the
air near the top is Audrey hangliding in from Haskell crag. Look below,
that little hive of activity is the base camp, Jesse's there running the
kitchen, Larry's off leading the day-walkers and there's Patrick and co
laying the railway system. Sure there aren't any trains running yet, not
all the way to the top anyway.
Maybe one day Larry will look at the view from the top and look back
towards the Kurila ranges and dub it Perl 7. He's done crazier things in
the past. So by all means, climb!

That was very poetic. :)

[Rafael Garcia-Suarez]

Post by Michael G Schwern
That was very poetic. :)

While we are in poetry... Might I quote Larry on this subject ?

I agree that it takes a certain amount of vision to see the promised
land before we get there. I suppose it's only natural that people
wandering in the desert for 40 years will grumble a bit and maybe
set up a golden calf or two, or attempt to march into the promised
land on their own when they think it's right. But I must confess to
feeling a great deal of sympathy for Moses occasionally.

http://www.nntp.perl.org/group/perl.perl6.language/2007/02/msg27152.html

(More allusions to the Torah in the original mail:)

[Abigail]

Post by Michael G Schwern

Post by Jesse
Walking through and removing features that you don't like
is a very good way to ensure that applications like RT and frameworks
like Jifty are never ported to your fork of Perl.

Yes, and? RT and Jifty haven't been ported to Python or Java, but that
doesn't mean Python or Java aren't useful languages.

Post by Michael G Schwern
I agree with Jesse, as an application developer there is not enough
benefit in your proposed fork to make me consider losing CPAN. Hell,
I have enough trouble moving commercial apps from 5.6 to 5.8. As a CPAN
author I do *not* want to have to maintain a Perl 5 and a Perl 7 version.
And then a Perl 8 and a Perl 9...

Noone is forcing you.

[ Snip ]

Post by Michael G Schwern
Just don't plant a flag at the start and call it the next Perl when you're
still at the bottom of the mountain. [1]

Yes, but let us also not shoot people who are willing to climb that
mountain. The point of open source is that someone who can take the
source, patch it, and release the thing with their patches.

I wish Gerard all the luck with his fork. If he manages to pull it off,
fork perl, change it significantly and make it production ready, and get
a user base then he earns my respect.


Abigail

[Jesse]

Post by Abigail

Post by Jesse
Walking through and removing features that you don't like
is a very good way to ensure that applications like RT and frameworks
like Jifty are never ported to your fork of Perl.

Yes, and? RT and Jifty haven't been ported to Python or Java, but that
doesn't mean Python or Java aren't useful languages.

I agree entirely. But doing it and calling it Perl seems like a Really
Bad Idea. I never said "don't work on the code" or "Forking Perl 5 is a
crime against humanity." And I was serious about wanting to see it once
he'd removed tie() and formats.

[Gerard Goossen]

Post by Jesse
[...]
Do tell me when you get rid of tie() and formats, though.
Jesse

The format keyword is already gone, and the formline will probably
be gone very soon.
I was planning to remove some magic. I am just don't know yet how much,
and what to replace it with (if it needs to be replaced).
Some of the options:
* Remove magic completely, probably a bit too enthusiastic
* Magic only for magic table, this would remove tied arrays,
hashes and filehandles, but keep tied scalars.
* Also remove the magic 'get' function, and allow 'set' only
for side effect.


Gerard Goossen

ps. I'm on vacation next week. When I'm back I probably first
gonna try some MAD or PPI to see how automatic translation
goes (but there can't be any automatic translation for removing tie).

[Ovid]

Post by Gerard Goossen
The format keyword is already gone, and the formline will probably
be gone very soon.
I was planning to remove some magic. I am just don't know yet how much,
and what to replace it with (if it needs to be replaced).
* Remove magic completely, probably a bit too enthusiastic
* Magic only for magic table, this would remove tied arrays,
hashes and filehandles, but keep tied scalars.
* Also remove the magic 'get' function, and allow 'set' only
for side effect.

Just noticed this thread. While I think it would be great if you
hacked on regular Perl itself, this is clearly a fork which Perl cannot
take. If you're going to go here, I also vote for killing 'tie', but
adding autoboxing.

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

[Rafael Garcia-Suarez]

Post by Gerard Goossen
The format keyword is already gone, and the formline will probably
be gone very soon.
I was planning to remove some magic. I am just don't know yet how much,
and what to replace it with (if it needs to be replaced).
* Remove magic completely, probably a bit too enthusiastic
* Magic only for magic table, this would remove tied arrays,
hashes and filehandles, but keep tied scalars.
* Also remove the magic 'get' function, and allow 'set' only
for side effect.

Well, since you seem you have a pretty good understanding of the perl
internals, why not try to contribute something useful instead ? You're
wasting time and talent in this dead end... perltodo.pod is a good
place to find good ideas for a start.

[Nicholas Clark]

Post by Rafael Garcia-Suarez

Post by Gerard Goossen
The format keyword is already gone, and the formline will probably
be gone very soon.
I was planning to remove some magic. I am just don't know yet how much,
and what to replace it with (if it needs to be replaced).
* Remove magic completely, probably a bit too enthusiastic
* Magic only for magic table, this would remove tied arrays,
hashes and filehandles, but keep tied scalars.
* Also remove the magic 'get' function, and allow 'set' only
for side effect.

Well, since you seem you have a pretty good understanding of the perl
internals, why not try to contribute something useful instead ? You're
wasting time and talent in this dead end... perltodo.pod is a good
place to find good ideas for a start.

Maybe I'm heretical here, but if Gerard (or anyone else) is either going to
work on a fork of Perl, or something completely different (and completely
unrelated), but working on core Perl (as it is currently developed) is not
an option, then I'd much prefer work on a fork, as it might throw up
interesting results that I'd not thought of, or thought practical.

But this goes with the warning that usually at least most of the work of at
least one branch of a fork goes to waste, which makes it an expensive way
to search for progress.

Nicholas Clark

[Gerard Goossen]

Post by Jesse
[...]
Do tell me when you get rid of tie() and formats, though.

The format keyword is already gone, and the formline will probably
be gone very soon.
I was planning to remove some magic. I am just don't know yet how much,
and what to replace it with (if it needs to be replaced).
Some of the options:
* Remove magic completely, probably a bit too enthusiastic
* Magic only for magic table, this would remove tied arrays,
hashes and filehandles, but keep tied scalars.
* Also remove the magic 'get' function, and allow 'set' only
for side effect.


Gerard Goossen

ps. I'm on vacation next week. When I'm back I probably first
gonna try some MAD or PPI to see how automatic translation
goes (but there can't be any automatic translation for removing tie).

[Nicholas Clark]

Post by Gerard Goossen

Post by Rafael Garcia-Suarez
And I use the indirect object syntax quite often... (every time I
write "print STDERR $foo" for example). Apart from loosing the ability
to run lots of CPAN code, I see no points in those changes... remember
that Perl 6 will be able to run Perl 5 code.

"print STDERR $foo" is NOT indirect object syntax. And it still works.

You might want to consider taking it out.

IIRC Artur says that the code needed to make it possible to call methods on
bareword filehandles slows down other operations that don't have alternative
syntax. (But I forget which)

Nicholas Clark

[Ben Morrow]

Post by Nicholas Clark

Post by Gerard Goossen

Post by Rafael Garcia-Suarez
And I use the indirect object syntax quite often... (every time I
write "print STDERR $foo" for example). Apart from loosing the ability
to run lots of CPAN code, I see no points in those changes... remember
that Perl 6 will be able to run Perl 5 code.

"print STDERR $foo" is NOT indirect object syntax. And it still works.

You might want to consider taking it out.
IIRC Artur says that the code needed to make it possible to call methods on
bareword filehandles slows down other operations that don't have alternative
syntax. (But I forget which)

Is that not the code that allows you to say

use IO::Handle;

STDERR->print($foo);

with STDERR treated as an object rather than a class name? The

print STDERR $foo;

syntax was in Perl 1, so I doubt that's slowing anything down much :).

Ben

[Anatoly Vorobey]

Post by Ben Morrow
The
print STDERR $foo;
syntax was in Perl 1, so I doubt that's slowing anything down much :).

That's a curious conclusion. Does code go faster as it gets older?

Sure thing, as CPUs get used to it; after a while they remember all the
moves and hardly need the actual instructions.

Why did you think scientists still use all those ancient FORTRAN
libraries?

--
avva

[Michael G Schwern]

Post by Anatoly Vorobey

Post by Ben Morrow
The
print STDERR $foo;
syntax was in Perl 1, so I doubt that's slowing anything down much :).

That's a curious conclusion. Does code go faster as it gets older?

Sure thing, as CPUs get used to it; after a while they remember all the
moves and hardly need the actual instructions.
Why did you think scientists still use all those ancient FORTRAN
libraries?

I thought it was because as more versions are piled on top it squeezes all
the inefficiencies out, like cheddar cheese.

[Michael G Schwern]

Post by Ben Morrow
The
print STDERR $foo;
syntax was in Perl 1, so I doubt that's slowing anything down much :).

That's a curious conclusion. Does code go faster as it gets older?

[Gerard Goossen]

Post by Rafael Garcia-Suarez

Post by H.Merijn Brand

Post by Gerard Goossen
- C<use strict qw"refs subs"> is default active
- removal of indirect object syntax (eq: C<new Foobar>)
- The old Unicode handling change
- removal of C<format> keyword (C<formline> still works)
Except from the Unicode change, the others are obvious, in the sense

"obvious"? the C<format> keyword removed? That is one of the reasons I stick
to perl5. I need it. I use it. Often.

And I use the indirect object syntax quite often... (every time I
write "print STDERR $foo" for example). Apart from loosing the ability
to run lots of CPAN code, I see no points in those changes... remember
that Perl 6 will be able to run Perl 5 code.

I don't follow Perl 6 very close, so please correct me if I am wrong.

I am told there will be a Perl5-to-Perl6 translator, which converts most of Perl 5
code. How much is most? But XS code won't work.

Much of the translator can also be used for the changes I made. Using
the Perl5-to-Perl5 translator it should be very simple to remove indirect
object syntax.
The translator will probably be easier to develop for the incremental changes
I made (relatively small compared to Perl 6), but it will
sometimes fail.


Does somebody know the state of the Perl5-to-Perl(5|6) translator? May I
have it?


Gerard Goossen

[Michael G Schwern]

Post by Gerard Goossen
I don't follow Perl 6 very close, so please correct me if I am wrong.
I am told there will be a Perl5-to-Perl6 translator, which converts most of Perl 5
code. How much is most? But XS code won't work.

That was the old plan. I don't know how far the translator got or if it ever existed. And you're right that it wouldn't quite work.

The new plan is to simply embed the existing Perl 5 interpreter into Perl 6. This is what Pugs currently does. Bug for bug compatibility! It even cheats in places and uses Perl 5 to implement Perl 6 ops.

Your best bet would be to use something like the PPI module to refactor code.

[Michael G Schwern]

Post by Michael G Schwern
The new plan is to simply embed the existing Perl 5 interpreter into Perl 6. This is what Pugs currently does. Bug for bug compatibility! It even cheats in places and uses Perl 5 to implement Perl 6 ops.

I thought a small demonstration was in order:

$ pugs -we 'use perl5:Text::Soundex; say Text::Soundex.soundex("foo")'
T232F000

More info at:
http://pugs.blogs.com/pugs/perl5/index.html

[Jesse]

Post by Michael G Schwern

Post by Gerard Goossen
I don't follow Perl 6 very close, so please correct me if I am wrong.
I am told there will be a Perl5-to-Perl6 translator, which converts most of Perl 5
code. How much is most? But XS code won't work.

That was the old plan. I don't know how far the translator got or if it ever existed. And you're right that it wouldn't quite work.

There are a number of different plans. All of them unproven at this
point. I believe that the avenues being pursued (in rough order of
bugwards-compatibility):

* Building a Perl 6 implementation using Perl5 as the VM

* Porting the Perl 5 engine to Parrot, so that Perl 5 is another
first-class Parrot langauge.

* Using Larry's MADPROPS work to generate a full, annotated p5 AST and
transforming that into Perl 6

* Implementing a Perl5-like language as a new Parrot language.

Each has different tradeoffs. Each has different proponents. Which one
are you interested in?

(Have I missed any?)

Jesse

[Michael G Schwern]

Post by Gerard Goossen
I agree. If my branch was interpreted as a finished proposal
for Perl 7, then that is my fault, it was meant merely as an initial
step.
I want to climb the mountain.

Stop calling it Perl 7. Really. By calling it Perl 7 and declaring a grand upgrade scheme now, before the benefits are seen, you've started a whole huge debate about compatibility and production release that doesn't have to be considered for months and months and might not even happen. Its a huge distraction that's not helping anyone get any coding done.

Just fork and code. Just call it "Gerard's Experiment" or something. Or "GUTS GUTS GUTS!" [1] The name does not matter for now, names can change. Then all the pushback from p5p would go away and folks would probably gladly help you out in toying with the guts of Perl 5 unrestricted by backwards compat. And you can code and climb the mountain and leave arguing about how many stripes to put on the flag when you get to the top.


[1] Loading Image...