Content of the Perl6 talk

[Andreas Kupries]

Dan Kuchler <kuchler at ajubasolutions.com> writes:
 
> Cameron Laird wrote:
> > 
> > <URL:http://deja.com/=dnc/getdoc.xp?AN=651665267> is the most pro-
> > vocative summary I've yet seen of Larry Wall's talk at the O'Reilly
> > Open Source Convention.  Mark-Jason Dominus's typically masterful
> > <URL:http://www.perl.com/pub/2000/07/perl6.html> provides technical
> > details.  I think at least the first of these will reward a quick
> > read by everyone involved in planning the futures of, for example,
> > Python and Tcl.  I applaud Conrad Schneiker for his care in prepar-
> > ing this.
 
> More interesting to me (and perhaps more interesting to some here in
> the comunity) are the notes from the initial brainstorming session
> on July 17th about what Perl 6 will be (what are the reasons for
> making it, what features might be added, etc.)
 
> http://www.perl.org/perl6/pr/initial_meeting.html
> 
> Lots if interesting little tidbits in here.
> 
> They talk of adding stacked IO channels "a l a Tcl"

Gee. How nice :)


Well, there are some other things on these pages which catched my eye
as well beyond stacked channels, both technically and socially.

Lets see:

<quote http://www.perl.org/perl6/initial_meeting.html>
> Syntax separation - multiple syntaxes ?
> Perl6 offers the possibility to ... write Perl programs in multiple
> syntaxes such as Python, JavaScript, and Perl5 ...

This reminds me of Guile, which tried to do the same thing, no ?
Universal lisp engine below, multiple formats for programming it
above. Here just with the perl engine below. A try to unify
interpreters ? See also Jean-Claude's Minotaur, using a forth engine
below and beside interpreters for several scripting languages to allow
them to use each other (and their extensions) hither and fro. With the
long-term goal to make each interpreter a set of routines above the
universal forth engine below. Hm.


<quote http://www.perl.com/pub/2000/07/perl6.html>
> Perl is too big for one person to manage, and the pumpkings burn out
> to quickly. The new model will probably be several separate working
> groups, each charged with the design and implementation of one
> aspect of perl.

This reminds me strongly of Python SIGs and one of the adjunct
proposals to the TCT made here on c.l.t, i.e. grouping several other
teams around the TCT. It is interesting to see that all the major
scripting languages go into very similar directions in their
development models.


<quote http://www.perl.com/pub/2000/07/perl6.html>
> Larry said that the Porters were thinking about ... an RFC-like
> mechanism.

This is something Matt Newman argued eloquently for and for some time
now. The Pythoneers (Pioneers?) have set such a structure up already,
not very long ago, the Python Enhancement Proposals (PEP), see

	http://python.sourceforge.net/peps/

for the first set.

-- 
Sincerely,
	Andreas Kupries <a.kupries at westend.com>
		<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------