[ruby-talk:04244] Perl6: seeking a better Perl than Perl the hard way.

Hi,

Here are some items about the Perl6 project that may be of interest to
Ruby-minds.

http://www.perl.org/perl6/ is the homepage for the Perl 6 effort.

Larry said that since the Porters had decided to bite the bullet of
backward incompatibility anyway and require translation of Perl 5 to
Perl 6 code, they would consider any change at all, as long as it could
be translated. He said that if 95% of all scripts could be translated
95% accurately, and if 80% of scripts could be translated 100%
accurately, that was probably good enough. Larry [Wall] said that
everything [feature-wise] was negotiable.

Which languages will you borrow from this time? "All of them."

Some people using Perl to develop large software want features like
strong type checking. Is there a possibility of providing this? Larry
said there was, and suggested a use strict 'typechecking' directive, or
maybe use stricter. He also said that perl 6 should get rid of many of
the stranger global variables, such as $#.

Perl6 offers us an opportunity to examine Python's model of saving
compiled bytecode before executing a program, as well as performing code
optimizations on the internal representation of Perl programs.

While POD can be used in a fashion reminiscent of Literate Programming,
other languages like Lisp and Java provide deeper support with the
language, environment or idiomatic use for documenting code. POD could
be extended to provide a better framework for documenting programs,
libraries and modules. POD can be extended, cleaned up, or more widely
adopted. Wishlist items include adding a consistent but minor amount of
structure to README files; clearly identifying module licensing and
clearly specifying authorship and email addresses.

Module installation and use is an instance of the "DLL Hell"
anti-pattern; that is, upgrading a module for one program may break
other programs. Mechanisms for installing multiple versions of a shared
library resource are well known and should be incorporated into Perl
module installation.

One reason why new work is being done in Java and Python may be due to
support for component architectures. Perl's support for reusing
component software should improve.

As CORBA becomes more popular, especially with KDE and Gnome, Perl needs
to support it in order to maintain its status as a glue language. This
is also true for other object frameworks like COM and Mozilla's XPCOM.

The basic Perl package should include common database, HTML, XML, and
other common features. The core Perl module library does not reflect how
most users expect to use Perl out of the box.
[Hint. Hint. Hint. :-)]

Many software developers like Java in part because Java programs can
ship without source code. Adding capabilities to ship Perl programs in a
binary format is an area Perl6 can address.
[Hint. Hint. Hint. :-)]

Perl's syntax for handling objects can be improved with changes to the
core language. Object support in Perl should be made more natural.
[Use Ruby!]

Perl's internal functions borrow heavily from C, and their behavior is
now counterintuitive and obscure to new Perl users. Two examples of this
are localtime() returning the year - 1900, and system() not returning
true on success.

Languages like SNOBOL have interesting regex features that are not
present in Perl. This is a possible source for new, interesting
features. [Look at Icon, SNOBOL's much more modern successor.]

Tom Christansen made a series of observations recently on where Perl and
Python differ, and where Python offers improvements over Perl. This list
of points should be considered when designing the Perl6 language.
[Look at Ruby Tom!]

Providing support for an event model would ease certain kinds of
programming, such as TK programs and (XML) parsing.

The I/O subsystem can stand a rewrite; implementing stackable I/O
filters (a la TCL) will make many jobs easier.

Many special variables are largely unused, irrelevant today or
deprecated. They should be removed since they clutter up both the
language and implementation.

Unicode should be supported from the ground up; hacking Unicode support
into Perl5 is proving very difficult and problematic. Perl5.6.x/Perl5.8
will feature improved Unicode support, but Perl6 should surpass that.

Mark-sweep garbage collectors should be investigated to clean up Perl's
reference counting garbage collection.

The ideas behind 'microperl' need to be investigated and extended. Using
Perl programs to configure Perl would be much easier than maintaining
metaconfig units. Keeping the memory footprint low and targeting embeded
systems like the Palm Pilot would also be nice.

Juding by the amount of time it took to implement Perl5.000 from
Perl4.035, Perl6 should ship in roughly 18 months.

Perl already has an extensive acceptance test. This test should be
extended and better integrated into the development of Perl6. This
includes using CPAN as an acceptance test.

Provisions for preserving, improving and increasing integration with
CPAN and Perl will be considered during the development process. Issues
include better language support for versioning, binary distributions,
and more community review processes.

"Let the sheep be sheep, let the sharks be sharks" -- Larry. Squeezing
out experimentalists at the hand of traditionalists and compatibility
police does not encourage people to extend Perl into interesting new
directions. There's benefit from having the compatibility police, the
experimentalists, high priests and traditionalists. The community is
better off from having differing personalities, differing approaches,
and different points of view in our community.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)