Re: Parrot FAQ

[Nathan Torkington]

Piers Cawley writes:
> I got some mail from a publisher off the back of my 'Not Just for
> Damians' article asking if I'd like to write a perl 6 book for them.
> Must reply really.

"Sure, I'd be glad to write about perl 6.  Do you also want to know
the next Lotto numbers, who'll win the Grand National, and when you'll
die while I've got my crystal ball warmed up?" :-)

Nat

Re: Parrot FAQ

[Nathan Torkington]

Simon Cozens writes:
> As mentioned in my other mail, I also edit perl.com for O'Reilly and
> Associates, who probably do have commercial interest in the development
> of Perl.

The other ORA editors keep asking me "should we sign more Perl 5
books?  Is Perl 6 going to kill our sales?" and I keep sobbing into
the phone "we have three of thirty-something parts of the design done.
Publish all you want!" :-)/2

Nat

Re: What is wrong with GCC's register transfer language?

[Nathan Torkington]

Terrence Brannon writes:
> And then just write a RTL->JVM and RTL->CRL converter?

I think it's time to collet these questions into a FAQ.  Any volunteers?

Nat

Re: Schedule of things to come

[Nathan Torkington]

John Siracusa writes:
> > I think we're due out in reasonably good alpha/beta shape for the summer.
> Heh, the phrase "suitable vague" springs to mind... :)

There's a good reason for that, for why I've tried hard to avoid
giving promises of when things would be ready.  Have you seen Apache 2
and Mozilla slip their schedules?  I'm making everyone take things
feature-by-feature, and we'll give a release schedule when we can see
the end in sight and not before.  What would be the point of naming an
arbitrary date when we don't even know when Larry will finish his
Apocalypses?  It seems crazy to have dates before you have
specifications of the final system.

Nat 

Re: Schedule of things to come

[Nathan Torkington]

Dan Sugalski writes:
> Okay, here's a tentative list 'o stuff that is in the works for Parrot 0.03 
> (and possibly 0.04):
> 
> *) Scalar PMCs
> *) Simple I/O
> *) Multiple interpreter & thread creation
> *) A simple arena allocation system
> *) Garbage collection

Sweet!  I guess Simon and you should work out which go into 0.03 and
which in 0.04.

Is there a good reason to delay allocation until after the things that
allocate memory have been written?

Nat

Re: Twist and shout

[Nathan Torkington]

Dan Sugalski writes:
> >   * push_c_i_i_i_v has to be a varop (see my recent posting with
> > print_s_v.
> 
> Nope. No vararg ops! :)

It might help forestall future flamewars if you explained why.

> We'll be introspective, but probably differently. We at least need
> to do things in ways both perl and python can easily stomach, and I
> think that's going to end up looking different than this will.

Do you have any current thinking on how this will work, or is that a
bridge you'll burn when you get to it? :-)

Nat

Re: Using int32_t instead of IV for code

[Nathan Torkington]

Dan Sugalski writes:
> Speaking from on high here, bytecode is strictly identifiable as to its 
> characteristics. It will be as portable as a platform implementer wants it 
> to be. The only 'required' types of bytecode that need to be read are 
> 32-bit integer (both big and little endian) with 8-byte IEEE floats for FP 
> constants. Everything else is optional, though if the code's small I fully 
> expect we'll ship with a full complement of translators.

Here's what I want.  In the real world, I want the reference C
implementation of Parrot to read and write a bytecode that will be
portable to other people using the reference C implementation.  If
someone wants to implement a faster, smaller, non-portable bytecode,
then that's cool.  But I really really really want the default out of
the box to be able to let us distribute compiled Perl programs.

Is that how the system you're describing will work?  (Apologies if
it's blindingly obvious, it's not so to thicky old me)

Nat

Re: run

[Nathan Torkington]

Here's what I use ...

#!/usr/bin/perl -w
# parrot - compile and run parrot assembly language

$srcfile = shift or die "usage: $0 PASMFILE\n";
($pbcfile = $srcfile) =~ s{\.pasm$}{.pbc}i;

system("perl assemble.pl $srcfile > $pbcfile && ./test_prog $pbcfile");

-- 

Re: [COMMIT] disassemble.pl

[Nathan Torkington]

Simon Cozens writes:
> I've just checked this in because the disassembler has come adrift
> from the assembler. I don't know if this is the right fix, because
> it feels like a hack, but it seems to work well enough for me to
> debug some failing tests.

Maybe one of the tests should be to disassemble every test pasm file
and compare it against the original code.  (Difficult because of
whitespace, etc, but perhaps not impossible if the assembler also has
a 'normalize' option that emits the code that the disassembler should
emit)

Nat

Re: The core platforms list

[Nathan Torkington]

Simon Cozens writes:
> On Wed, Sep 19, 2001 at 01:22:04PM +0200, H. Merijn Brand wrote:
> > Can't open perl script "t/harness": No such file or directory
> > MANIFEST? (using most recent parrot-nightly)
> 
> Don't use parrot-nightly; use the snapshots from cvs.perl.org

So parrot-nightly will only be useful when we have many more features
implemented, and there's a high probability that most features in a
snapshot will actually be working (for some value of working)?

Perhaps we need to more loudly disclaim parrot-nightly on the website
and docs, or maybe even put it on hold until there's more chance it'll
be useful?

Nat

RE: Constant comparisons

[Nathan Torkington]

Gibbs Tanton - tgibbs writes:
> It seems to me that this might eventually get out of hand...could there
> possibly be some way to automate the generation of a family of opcodes?  For
> example:

Hear hear, the same thing occurred to me.  The way that there are
separate functions for each argument type is really adding to the
number of functions.  What was the reasoning behind that again, Dan?

Nat

Re: coding standards

[Nathan Torkington]

Gibbs Tanton - tgibbs writes:
> I will try to watch things as they go in and make coding standard
> changes immediately from now on so we don't have such a massive
> change.

Alternatively, pumpkings could refuse to apply patches that don't
conform.  One or two goes around and people will learn to submitting
correct patches.

Nat

Constant comparisons

[Nathan Torkington]

I wanted to be able to say

eq I1, 15, label1, label2

That is, to compare against a constant.  I've implemented versions of
the comparison opcodes that let you compare against constants.  This
is my first patch to Parrot.  Be merciful :-)

Nat
(also working on test system ... stay tuned)


Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.15
diff -u -d -r1.15 basic_opcodes.ops
--- basic_opcodes.ops   2001/09/14 14:08:00 1.15
+++ basic_opcodes.ops   2001/09/15 21:52:38
@@ -56,6 +56,15 @@
   }
 }
 
+/* EQ Ix, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_ic_ic {
+  if (INT_REG(P1) == P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* NE Ix, Iy, NE_BRANCH, EQ_BRANCH */
 MANUAL_OP ne_i_ic {
   if (INT_REG(P1) != INT_REG(P2)) {
@@ -65,6 +74,15 @@
   }
 }
 
+/* NE Ix, CONSTANT, NE_BRANCH, EQ_BRANCH */
+MANUAL_OP ne_ic_ic {
+  if (INT_REG(P1) != P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* LT Ix, Iy, LT_BRANCH, GE_BRANCH */
 MANUAL_OP lt_i_ic {
   if (INT_REG(P1) < INT_REG(P2)) {
@@ -74,6 +92,15 @@
   }
 }
 
+/* LT Ix, CONSTANT, LT_BRANCH, GE_BRANCH */
+MANUAL_OP lt_ic_ic {
+  if (INT_REG(P1) < P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* LE Ix, Iy, LE_BRANCH, GT_BRANCH */
 MANUAL_OP le_i_ic {
   if (INT_REG(P1) <= INT_REG(P2)) {
@@ -83,6 +110,15 @@
   }
 }
 
+/* LE Ix, CONSTANT, LE_BRANCH, GT_BRANCH */
+MANUAL_OP le_ic_ic {
+  if (INT_REG(P1) <= P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* GT Ix, Iy, GT_BRANCH, LE_BRANCH */
 MANUAL_OP gt_i_ic {
   if (INT_REG(P1) > INT_REG(P2)) {
@@ -92,6 +128,15 @@
   }
 }
 
+/* GT Ix, CONSTANT, GT_BRANCH, LE_BRANCH */
+MANUAL_OP gt_ic_ic {
+  if (INT_REG(P1) > P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* GE Ix, Iy, GE_BRANCH, LT_BRANCH */
 MANUAL_OP ge_i_ic {
   if (INT_REG(P1) >= INT_REG(P2)) {
@@ -101,6 +146,15 @@
   }
 }
 
+/* GE Ix, CONSTANT, GE_BRANCH, LT_BRANCH */
+MANUAL_OP ge_ic_ic {
+  if (INT_REG(P1) >= P2) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
 /* IF IXx, TRUE_BRANCH, FALSE_BRANCH */
 MANUAL_OP if_i_ic {
   if (INT_REG(P1)) {
@@ -193,6 +247,15 @@
 /* EQ Nx, Ny, EQ_BRANCH, NE_BRANCH */
 MANUAL_OP eq_n_ic {
   if (NUM_REG(P1) == NUM_REG(P2)) {
+RETURN(P3);
+  } else {
+RETURN(P4);
+  }
+}
+
+/* EQ Nx, CONSTANT, EQ_BRANCH, NE_BRANCH */
+MANUAL_OP eq_nc_ic {
+  if (NUM_REG(P1) == P2) {
 RETURN(P3);
   } else {
 RETURN(P4);
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.13
diff -u -d -r1.13 opcode_table
--- opcode_table2001/09/13 16:16:38 1.13
+++ opcode_table2001/09/15 21:52:38
@@ -62,12 +62,19 @@
 # Comparators
 
 eq_i_ic4   I I D D
+eq_ic_ic   4   I i D D
 eq_n_ic4   N N D D
+eq_nc_ic   4   N n D D
 ne_i_ic4   I I D D
+ne_ic_ic   4   I i D D
 lt_i_ic4   I I D D
+lt_ic_ic   4   I i D D
 le_i_ic4   I I D D
+le_ic_ic   4   I i D D
 gt_i_ic4   I I D D
+gt_ic_ic   4   I i D D
 ge_i_ic4   I I D D
+ge_ic_ic   4   I i D D
 
 # Flow control
 

Re: CVS update mailing list

[Nathan Torkington]

Simon Cozens writes:
> So maybe the best thing would be for people to send patches to the
> list and Cc [EMAIL PROTECTED]

I wonder if, when RT comes online, we could use that to manage the
patches.  In other words, patches become open "to do" items, which are
cleared when the patches are definitively applied or rejected.

Nat

Re: #include "config.h" or #include "parrot/config.h"

[Nathan Torkington]

Andy Dougherty writes:
> > #include "config.h"
> > rather than
> > #include 

Isn't the correct solution to this problem to say

   #include 

That is, include the subdirectory prefix in all #includes.  You -I the
directory containing parrot/, and that avoids randomly located
config.h files from buggering you up.

Nat

Re: PDD 6 (parrot assembly) now in CVS

[Nathan Torkington]

Dan Sugalski writes:
> >Lines 249 to 261 seem to duplicate 204 to 216.
> 
> D'oh! Thanks, fixed.

Oh man, good luck building a unit testing system for the docs :-)

Nat

Re: Muddled Boundaries - Perl 6 vs Parrot

[Nathan Torkington]

Simon Cozens writes:
> I am in two minds here. I want to have Parrot_... prefices on
> functions even if they're *not* completely necessary /pour
> encourager les autres/.  However, I don't want to go the way of
> opening up everything in a public API righht now, because once
> you've exported a symbol for developers to use, you can never take
> it away from them again - whereas if nearly everything's private and
> not exported, you can always open it up later.

Part of "configuration" could be building a #define pile so you can
use foo and bar in the .c files, but they're invisibly translated into
Parrot_ and so on equivalents.

Preprocessing hurts my ass, though, when it comes time to debug.

Nat

Re: Muddled Boundaries - Perl 6 vs Parrot

[Nathan Torkington]

Bryan C. Warnock writes:
> It's not a prioirty, but it's so much easier to walk the correct path from 
> the start.  Since it's all Parrot, it's even easier.

I agree.  How about this: when the code is available (i.e., this
afternoon), why don't you sit down with whoever else feels
passionately about this, and add the namespace protection?  There's no
reason why it can't be added early, and I agree with Simon that he has
higher priority things to worry about, but there's no reason why you
or anyone else can't add it in.  And it should be easy to add it in
while the codebase is small.

Namespace protection seems tricky.  You need a list of symbols,
categorized public or private.  You need to automatically check the
symbol list (e.g., output of nm) to see you're not exporting
un-prefixed symbols.  And so on.  The more of this stuff that can be
automated, the better.

Go to it!

Nat

Re: Muddled Boundaries - Perl 6 vs Parrot

[Nathan Torkington]

Bryan C. Warnock writes:
> Like I said, just things to keep in mind.  There's a slight difference 
> between designing and coding Parrot as an interpreter backend, and coding it 
> as a backend to Perl that other languages can use.  (I'm in favor of the 
> latter, though public opinion seems to favor the former.)

Here's my Official Word.  Right now it's too early to know whether
building perl6's runtime to also support other languages will impact
perl6's speed or size.  We also have faced skepticism about the whole
effort from other languages.

So we're proceeding with designing perl6.  We're leaving the door open
for other languages, but we're not going to significantly delay or
impede perl6 to support them.  Dan and Simon have both been talking
with Python folks about their language, and I'm sure there'll be demos
to the Python crowd soon to show them that it's feasible and attempt
to get their buy-in.

If we get other languages interested to the point where we share our
internals with them, then we'll go through the painful divorce process
of dividing assets between Perl and Parrot.  But until then, let's
assume that Parrot will only officially be part of the Perl project,
and focus on writing more Parrot code instead of arguing about
namespaces.

That may mean we may face a little pain down the road, but at the
moment I'm much more interested in getting something to have pain
about than I am about planning for a future that *might* come about.
If we get the other languages interested, it'd be such a big win (in
terms of development resources) that we'd be *happy* to do the work of
separating parrot from perl.

Make sense?

Nat

Simon Cozens is the Source Pumpking

[Nathan Torkington]

I'm happy to say that, in preparation for the release of the first
piece of Parrot code, Simon Cozens has stepped forward to hold the
source pumpkin.

Simon's responsible for the contents of the internal and external
source distribution.  He'll update the CVS repository with patches
submitted by the public to perl6-internals.  He'll make periodic
releases available on CPAN.  He'll also build an initial team of
committers from those who submit good patches.

Simon will have to work closely with many people, including:
 * Larry, who is designing the language 
 * Dan, who is designing the internals
 * Schwern and everyone else from QA, who will be responsible for
   smoking the builds, unit testing, and more
 * The as-yet-unknown configuration and build group, responsible
   for determining system configuration and the build process.

Nat

Re: Should MY:: be a real symbol table?

[Nathan Torkington]

Dan Sugalski writes:
> Needless to say, this makes the optimizer's job... interesting. On the 
> other hand, it does allow for some really powerful things to be done by 
> code at runtime.

The big thing I want it for is so I can write nats_settings.pm:

  # nats_settings.pm - turn on strict and warnings in caller
  magically_affect_my_caller_with {
use strict;
use warnings;
  };

then at the top of my programs I can write:

  use nats_settings;

Nat

Where's da code?

[Nathan Torkington]

Simon and Dan have been teasing you, I know.  I'm holding them back
from releasing what they have until:

1) We have a CVS server running.  (Ask has done this and is now
   working on anonymous access).

2) We have a bugtracking system.  (We're currently thinking of
   Bugzilla).

3) We have a build tracking system.  I believe Ask is working on
   Tinderbox.

4) We have some "bugs" to put into the bugtracking system.  That is,
   some initial projects that people can hack on.  Simon's been coming
   up with a good To Do list that we'll seed the bugtracking system
   with.

I want to avoid the situation where we announce code and then chaos
erupts.  If there's going to be lots of frenzied hacking, I want to
make sure it is appropriately focused.  Think of this as the lesson
I've learned from bootstrap (and from watching how Mono started up).

There'll be a CVS server for those who want bleeding edge source.
We'll put daily build snapshots onto an FTP/http server, and any time
we have a particularly stable/featureful build, that'll go onto CPAN.

Let me know if I've forgotten anything.  If all goes well, we should
see the first source release towards the end of this week.  Fingers
crossed!

Nat

Re: An overview of the Parrot interpreter

[Nathan Torkington]

Sam Tregar writes:
> > If our PMC is a string and has a vtable which implements Perl-like
> > string operations, this will return the length of the string. If, on the
> > other hand, the PMC is an array, we might get back the number of
> > elements in the array. (If that's what we want it to do.)
> 
> Ok, so one example of a PMC is a Perl string...

If you grok vtables, think of a PMC as the thing a vtable hangs off.

Another way to think of it is that a PMC is an object.  To the outside
(the interpreter that is manipulating data values) its contents are
opaque.  All you can do is call methods (vtable entries) on it.

So if you have an object/PMC that implements a string, the "length"
method/vtable-entry will return the length of the string.  An
object/PMC that implements an array, the "length" method/vtable-entry
will return the number of things in the array.

Nat

Re: Something to hash out

[Nathan Torkington]

Simon Cozens writes:
> I was using .pas and .pac. Gotta think about 8.3ness, unfortunately.

.pas is generally Pascal.

I also think it's important we choose extensions based around their
humour potential.  With that in mind, I propose:

  .par for Parrot source, and .pao for Parrot Objects would be cool.
  Sample files:

under.par
kung.pao

Actually, are these the only two types of file we're going to
generate?  Won't there be unoptimized bytecode, parse trees, etc?  Do
we want an integrated set of extensions (.pa?)?

Nat

Anyone here with Sourceforge experience?

[Nathan Torkington]

I'd like to keep the code on Sourceforge from the get-go.  I don't
have much experience with Sourceforge, though, and would like to talk
to someone who has.  Which bits work well?  Which bits aren't worth
the effort?  Any tips or tricks to pass on?

Thanks,

Nat

Python on Unicode etc.

[Nathan Torkington]

This is from the latest python-dev summary.  It might be of interest
to folks considering how to store strings.


* Adding .decode() method to Unicode * Marc-Andre Lemburg asked for
  opinions on adding a .decode method to unicode objects:

 http://mail.python.org/pipermail/python-dev/2001-June/015346.html

He certainly got them; the responses ranged from neutral to negative,
and there was a surprising amount of hostility in the air. The problem
(as ever in these matters) seems to be that Python currently uses the
same type for 8-bit strings and gobs of arbitrary data. Guido came to
the rescue and calmed everyone down:

  http://mail.python.org/pipermail/python-dev/2001-June/015404.html

since when discussion has vanished again.

Re: Stacks, registers, and bytecode. (Oh, my!)

[Nathan Torkington]

Dan Sugalski writes:
> Okay--Parrot Object Code. (If I was feeling cleverer at the moment, I'd 
> come up with a name that has a snappier acronym. Alas I'm not... :)

p-code.  The p stands for Parrot :-)

Nat

Re: Master-Apprentice and a "sneak peek"

[Nathan Torkington]

Not to speak for Dan, but there's no code yet to review or learn from.
I'd love to see someone set up a perl *5* apprentice program, and
Mark-Jason Dominus has some ideas on how it might work.  For perl6,
though, we're not yet at a place where I think it makes sense.  Right
now there's so little defined in the way of implementation, that
questions can be asked and answered on the mailing list.

Dan?

Nat

Chip's topaz slides

[Nathan Torkington]

Better late than never!  Chip's provided the slides for last year's
Topaz talk at TPC5.

Nat
(Ask, could you put them on dev.perl.org?  Thanks!)
 topaz-v2.pdf

Re: We should have some YAPC talks on Perl 6

[Nathan Torkington]

John van V writes:
> If perl.org is unacceptable for some reason I can easily create a
> mailing list on puny.vm.org

Thanks for the offer, but I don't think we'll need it.  I think we're
hampered right now by the fact that we don't know much about what
perl6 is going to look like.  Until we get more specifics from Larry,
and Dan helps us all work out the internals some more, there's not
much to write about.

Any mailing lists we need for documentation can definitely be hosted
at perl.org.  But we need something to document first :-)

Nat

We should have some YAPC talks on Perl 6

[Nathan Torkington]

--- start of forwarded message ---
  # CFP in English, followed by French (see below) #

Third North American YAPC: First Call for Participation

 Yet Another Society
  calls for your participation in

  YAPC 2001
  the Third North American
Yet Another Perl Conference

  http://yapc.org/America/ 

  McGill University,
   Montreal, Quebec 

   Wednesday through Friday
   June 13-15, 2001 

YAPC is a place for people to meet and talk about Perl -- where people
who've done interesting things, people who are working on the language
itself, people who are using it daily, and people who are looking to
learn about it are all within arm's reach. Some of the great authors
and coders in the field will be on hand to discuss their work, as well
as the nature and direction of Perl itself.

Please join us for three days of listening and talking about Perl in
Montreal.

* Conference registration will be available by Feb. 1, 2001 at 
http://na-register.yapc.org/ 

* Dorm rooms will be available at the University (rates TBA); the dorm
  request information will be on the website and registration form.
  Registration Cost: CAD$125 (about USD$85) 

* We are looking for sponsors. Please contact Kevin Lenzo
  ([EMAIL PROTECTED]) for information about how you can help support the
  Yet Another society and YAPC. Much of the necessary funding for YAPC
  comes from the generous donations of our sponsors.

* Submitted papers: 
Submission Deadline: May 1, 2001 

All topics are welcome. Here is a short list of subjects that might
be presented:

XML, CGI/Web, Interprocess Communication, GUIs (GTk, Tk), Natural
Language Processing, Interactive Perl, Agents, Perl as Glue,
Object-Oriented Perl, Scientific Applications, Guts, Internals, 
JAPHs, Perl Poetry, System Administration, DBI/DBD, Non-UNIX Perl, 
Security, Peer-to-Peer Communication, Your Favourite Topic.

Please submit your abstracts to <[EMAIL PROTECTED]>. Authors are
requested to limit their abstracts to one or two paragraphs for
Lightning Talks, and to 300 words for other talks.

This year we will accept a number of types of talks: 

  * Lightning: 5 minutes 

The lightning talks were instigated by Mark-Jason Dominus last 
year in Pittsburgh, and were replicated with great success at 
the European YAPC in London.

Participants speak for no more than five minutes, with the use 
of conventional transparencies. Any use of data projector, etc, 
is discouraged, but allowed as long as the five minute time limit 
is maintained (set-up will be done as the clock ticks). The talk 
ends at the five-minute mark, regardless of whether or not the 
speaker has finished.

Any topic is allowed, and some have been fantastically humourous. 
Lightning talks are an excellent forum for first-time speakers.

  * Standard: 20 minutes 

A 'standard' talk is the preferred format. This is enough time 
to start a topic, introduce it with some pithy slides, and open 
up to later conversation.

  * Long and Extra-Long: 45 minutes, 90 minutes 

Long talks are reserved for experienced speakers covering large
topics. If you have an in-depth topic you would like to present 
in some detail, perhaps with considerable discussion, a Long or
Extra-Long talk may be the format of choice.

  * Tutorial: 3 hours + break (possibly in two sets) 

Half-day (or possibly full-day) tutorials. 

Please submit your abstracts to <[EMAIL PROTECTED]>! 

--

Yet Another Society is a non-profit organization for the advancement
of collaborative efforts in computer and information sciences.  YAS
promotes symposia, teaching, and group projects. See
http://yetanother.org for more information.

--


   Troisime YAPC Amrique du Nord: premier appel  la participation

  Yet Another Society
   vous invite  participer  

YAPC 2001
   La troisime
   Yet Another Perl Conference
   en Amrique du Nord

 http://yapc.org/America/ 

Universit McGill,
 Montral, Qubec 

  Du mercredi au vendredi
   13 au 15 juin, 2001

YAPC est un endroit o se rencontrer et parler de Perl; o sont runis
des gens qui ont fait des choses intressantes, qui travaillent sur le
langage lui-mme, qui utilisent ce langage tous les jours et qui
veulent en apprendre plus. Quelques uns des meilleurs auteurs et
codeurs dans le domaine seront prsents pour discuter de leur travail,
ainsi que de la nature et de l'avenir du langage Perl lui-mme.

Joignez-vous donc  nous  Mont

Compiler theory text available

[Nathan Torkington]

I browsed this books on the shelves at Barnes and Noble and remember
mocking it because of the section on "what makes a successful
language" (orthogonal, minimal, clearly defined, ...).

While we won't be using C++, it looks like this might be an
interesting read if you're interested in learning how compilers work.

  http://scifac.ru.ac.za/compilers/

Nat

Re: Meta-design

[Nathan Torkington]

Simon Cozens writes:
> This is not a design document; it's a meta-design document - that is, it
> tells us what things we need to design, the things we need to consider
> during the design process of the Perl 6 internals.

Thank you!

> Why does string C have to screw everything up?

It doesn't.  String eval is the escape hatch from a language that
can't do what you want it to do.  As such it's okay for it to be
slow--consider it incentive to fix the language :-)  The runtime
system should be able to load the compilation system and say
"turn this SV into a CV in this lexical scope," and then call the
CV.

> Today's scary thought:
> 
> use B; my $main_root = new B::OP;
> ...
> my $int = new B::Interpreter; $int->run($main_root)

That's yesterday's scary thought.  Today's scary thought is making
a perl5 XS wrapper for the perl6 component libraries and being able
to run perl6 from within perl5 in that way.

Nat

Re: Markup wars (was Re: Proposal for groups)

[Nathan Torkington]

Bennett Todd writes:
> Would you accept a restatement of: as long as whatever it is can be
> translated into a common format, we can work with it, and the
> composition of the actual words is far more important than niggling
> over choices in preferred markup style?

Sure, but that begs the question of what is common, and that's yet
another flamewar.

Even if people wanted to write the docs in XML, I'd be happy to have
docs.  We can always PODify them if XML proves troublesome.  It's
having no docs that is the situation we want to avoid.

There are also many documentation needs.  I don't think we need to
distribute the design docs as manpages, but we need to distribute
the user docs as manpages.  When we get to user docs, we'll need to
consider the ultimate destinations for the manpages.  Until that
point, it's all talk with nothing behind it.

Nat

Re: Meta-design

[Nathan Torkington]

Bradley M. Kuhn writes:
> > Java is portable and gives us OO, but it's slow and ugly.
> 
> I am probably the biggest proponent of the "use Java to implement Perl"
> camp.

Java is only somewhat portable.

> One concern that I have about the data structure design thus far (and I
> believe I wrote an RFC about this) is that we should try to resist the
> temptation to "talk in C" too soon.  Most of the ideas I have seen thrown
> around are filled with C-isms.  Of course, that's totally reasonable, if it
> helps people think about the issues.  However, I would like it to be
> possible for a programmer of language Foobar to take the specification of
> the data structures and implement them directly in Foobar without too much
> trouble.  The fewer C-isms in the high-level spec, the easier such a task
> will be.

That's a worthy goal.  We should keep it in mind.  And if we design
the data structures in this fashion, then the programming language
choice is somewhat minimised.

> I would like to note that GCC has actually switched to using garbage
> collection to manage its *internal* data structures rather than a
> traditional C memory management system.  The GCC team has been pleased with
> both the performance and ease of use.
> 
> The argument is: "Computers do a better job at memory allocation than humans
> do by hand, so let the computer do it!"
> 
> I think we should give this idea some serious consideration.

I agree.

Nat

Re: Proposal for groups

[Nathan Torkington]

Simon Cozens writes:
> Yes, we should really postpone the inevitable markup language war until
> we have something to mark up.

You channeled my very thoughts, Simon.

I say that the person who *does* the work deserves the right to choose
what format it is in.  So long as we can make navigable webpages out
of it, that person can write on a Commodore 64 for all I care.

Nat

Designers step forward now

[Nathan Torkington]

Simon Cozens writes:
> As for me, I hate this "self-selection" thing because it forces me to be
> immodest. Oh well, better get used to it: Me. I think I'd be useful.

Excellent.  Anyone else who wants to be part of the initial design
team, now is the time to speak up.  If you have perl5 internals
experience, or design experience with a comparable project, then offer
your name to Dan Sugalski.  Let's see how we go by Friday, and then
consider pruning if we have too many people.  It's no tragedy either
if we only have 3 or 4.  The individual experience of the participants
is far more important than the number of participants at this stage
(this can and will change when we get to test cases and
implementation).

We will keep the number of people small (5 to 10, smaller being
better) and their job will be to come up with the architecture and API
for the systems.  We can watch their work and comment, but on a
separate list.

Nat

Re: Proposal for groups

[Nathan Torkington]

Alan Burlison writes:
> seem a very optimal way to go about it.  How about a design document
> (format to be decided) and a 'design + commentary' document which is the
> design document with the condensed email discussion inserted into it as
> the commentary.  That way there is a design spec for the implementation,

Cool.  You're volunteering to edit it?

Nat

Re: Proposal for groups

[Nathan Torkington]

Simon Cozens writes:
> On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> > perl6-internals-design is for a team of no more than 10 people. 
>  
> And we decide those ten... how? :)

Self-selecting.  Who has the necessary experience to bring to the
table and wants to be part of that team?

Nat

Proposal for groups

[Nathan Torkington]

I think I see two problems:
 * a lot of people want to know what's going on, but not all have the
   experience to be able to follow it
 * it's difficult for the design to happen through the questions

How about we do this to design the architecture and API:

perl6-internals-design is for a team of no more than 10 people.  These
people should have experience either with perl5 or with a similar
system.  Mail to this list goes to perl6-internals-design and to
perl6-internals.

perl6-internals is a public access list, where folks can feel free to
question and kibitz.  The design team will probably want to have a few
people on the public list as well.  This is where the consciousness of
the rest of us can be raised.  We can see what they're doing, ask
questions, and make suggestions.  Because the meta discussion happens
off the -design list, designers will be able to tune it out if they
have to focus on the task at hand.

This lets us satisfy these goals:
 * open process, both for visible and participation
 * small team doing the design (elephant is a mouse designed by
   committee, etc)

Make sense?

Nat

Another XS type of thing: Orchard/C

[Nathan Torkington]

--- start of forwarded message ---
From: Ken MacLeod <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Orchard/C 0.2.3 preview release available
Date: 15 Nov 2000 09:38:56 -0600

Half of the Perl interface into Orchard/C is complete, you can now
call C functions and return C objects to Perl.  (The other half is
Orchard/C calling Perl.)

  

Included examples are an Expat node-based SAX wrapper and two sets of
XML objects (one optimized for in-memory usage, one not).

Orchard/C is comparible to SWIG, as it's intended to make interfacing
C to Perl (and Python and Tcl) very easy and portable.  SWIG is
intended for wrapping existing C/C++ libraries and must contend with C
data types.  Orchard/C, on the other hand, is intended for writing new
C code as performance enhancements for Perl/Py/Tcl.

Because Orchard/C code is written with scripting languages in mind,
several things have been done to make this easier, including a fast
OO-like runtime (pure C, albeit preprocessed), object attribute
accessors, garbage collection (Boehm GC), and transparent interfacing
(no code or interface files) of Orchard/C classes to Perl/Py/Tcl
classes.

Orchard/C requires Expat 1.95.x and Boehm GC (see the README), both of
which are very easy to compile (on Unix, anyway).  The Perl interface
is in 'perlif/' and is compiled as a second step after compiling
Orchard/C, and it compiles like a standard Perl module.  The Perl
interface includes wrapper modules for the main C classes:
Orchard::SAXDriver::Expat, Orchard::TreeBuilder,
Orchard::XML::FastSmall, etc.

Adding the ability for Orchard/C to call Perl code is up next.  Future
enhancements include dynamic loading of Orchard/C modules (currently
all Orchard/C code must be preprocessed at the same time),
implementation of Python and Tcl interfaces, and design patterns for
writing Perl/Py/Tcl cross-compatible Orchard/C modules.

 -- Ken
--- end of forwarded message ---

Re: Design, opps- govt foul up

[Nathan Torkington]

John van V writes:
> FTC = FCC  (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...)

This is so far away from being of use to the perl6-internals list,
I'm surprised to see it here.

Let's get back to design.  Dan?

Nat

Re: Design

[Nathan Torkington]

Ken Fox writes:
> Nathan Torkington wrote:
> >   Robustness
> >   Portability
> >   Maintainability
> >   Testability
> >   Reusability
> >   Speed
> >   Simplicity
> >   Size
> 
> Hey, whoa. Aren't we pre-maturely optimizing the development
> process?

Not in deciding priorities.  These are factors of architecture
just as much as code.

> Example: I'd like to see a few different species of vtbl before
> we commit to an API

Yup, that makes perfect sense.  But how do we evaluate the vtbl?
We need some acknowledged priorities.

> BTW, where's Chip? I was *really* hoping
> that he'd write up his Topaz experience and clue us in on
> architectural dead ends. It might be that the family tree of

Sigh.  I've asked for Chip's talk notes.  Chip is deluged in
VA Linux kernel work, and doesn't answer anything.

Nat

Re: Design

[Nathan Torkington]

> Another angle is to collect a set of mantras, design principles
> if you will, something like:
> 
>   Avoid copying.
>   Avoid premature optimization.
>   Be extensible.
>   Be orthogonal.  Orthogonal be.
>   Be portable.
>   Be scalable.

Quite right.  This is the standard practice of listing your priorities
for code.  Here are the things to order, in my order:

  Robustness
  Portability
  Maintainability
  Testability
  Reusability
  Speed
  Simplicity
  Size

To put them into order, imagine you're a Perl sort comparison routine
comparing two of the items.  Ask yourself "would I trade $a to get
$b?"  Obviously it sometimes depends, but what would you do most of
the time?

Nat

Design

[Nathan Torkington]

Dan, Jarkko, etc.  How about we try to identify the big units we'll be
working on?

  parser
  optimizer
  bytecode
  runtime dispatcher (w/knowledge of dynaloading)
  data-types
  regex
  memory

My idea of development is something like this:

 * identify the units/modules
 * map relationships between modules
 * design the API for the modules
 * code test cases for the API (circular process with the previous
   step?)
 * code the API
 * code the wrappers for the libraries (perl.c, etc)

Make sense?

Nat

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

[Nathan Torkington]

Steve Fink writes:
> I suspect perl can do a much better job than it does now, but if you
> make it a requirement, you prevent many optimizations. I think the RFC
> should be very specific about when it applies and when it gets out of
> the way.

I can't be more specific unless I know the optimizations.  So I'll
fudge and say "unless a compelling case can be made for an
optimization that absolutely cannot preserve this information".

I don't mind a bloated optree, so long as there's a way to trim it.

Nat

Re: Perl Implementation Language

[Nathan Torkington]

Ken Fox writes:
> The dogfood theory? One of the design goals for Perl is to make text
> munging easy. Parsing falls into that category and therefore we should
> use it, i.e. eat our own dogfood.

How about this.  During design, we try to make the parser a module
with an interface designed so that it could be done via Perl
callbacks.  At this stage we should be able to say "whoa!  This is
crazy, we can't do it", or "yes, we can leave the door open for
this."

I think we are going to have enough on our plates without trying to
use a language that doesn't exist to write the parser for that
language :-)

That kind of bootstrapping problem adds a lot of uncertainty to the
development, and another level of implementation to overcome.  I'd
be happy to make it *possible* to write the parser in Perl and then
start doing that in 6.1.0.

Nat

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

[Nathan Torkington]

Dan Sugalski writes:
> No, that's the point. But if someone explicitly strips out the debugging 
> info then, well, you don't get much help in debugging, now do you? :)

I buy that.  It'd be nice to be able to be one step better than C,
though, and given *something* that you can use to go back to your
source from.

Nat

Re: A tentative list of vtable functions

[Nathan Torkington]

Dan Sugalski writes:
> It's possible, for example, for a tied/overloaded/really-darned-strange 
> variable to look true but still be false. If you do:
> 
>$foo = $bar || $baz;
> 
> and both $bar and $baz are objects, the 'naive' way is to make $foo be 
> $bar. But it's distinctly possible that $bar really should be treated as a 
> false value and $baz be used instead. Why? Dunno. Serious hand-waving here. 
> (And yes, I know that's a danger sign... :) But I don't see any reason to 
> preclude the possibility.

You can do that right now in perl5, by using overload.pm and supplying
a 'bool' method.

An application might be when your object represents an array and you
want the boolean context of your object to report whether it has data
in it or not, to facilitate:

  if ($pdl) {
 # do something if the $pdl has data in it
  }

Nat

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

[Nathan Torkington]

Dan Sugalski writes:
> I wouldn't worry about this too much. If it's all keyed off an opcode of
> some sort ("Current line info"), we could easily just strip those opcodes
> out. They won't take up that much space relative to the rest of the
> program, but I can see some sort of runtime overhead if we have each
> 'current line' op smack a pointer to the current line info into the
> interpreter structure or something.

That'd be an incentive to write one-liners ... they'd be faster :-)

Wouldn't removing opcodes make it impossible for you to give the user
a position in the optree that they can turn back into a point in their
program?  It seems like you'd only be able to say "division by zero at
position 4501 of the opcode stream" and position 4501 has a different
opcode in stripped and unstripped programs.  You'd have to recompile
your Perl program, and have a pseudo-strip that calculates where 4501
in the stripped opcode tree would be, then tells you where in your
program that corresponds to.

I could also be missing the point. :)

Nat

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

[Nathan Torkington]

Simon Cozens writes:
> > Nice!
> Efficient!
> Practical!
> 
> Choose two.

I take this oblique comment to mean that it'd bloat the op-tree too
much?

I was thinking of this over lunch.  I want to be able to strip the
instruction sequence of line number, package, etc. information, in the
name of a smaller memory footprint and smaller distributed bytecode.
It'd make debugging tricky, but if there was still a sequence number
("error at opcode #1590") preserved, the user could produce an
unstripped executable and then use the sequence number to see where
the problem was.

Make sense?

Nat

Re: New Perl rewrite - embedded Perl

[Nathan Torkington]

Tom Christiansen writes:
> We've been down this route.  It doesn't help the way you think it does.
> These are merely wafer-thin wrappers about syscalls.  It's Perl's 
> complete infrastructure support system you're seeing, and that you
> will not reduce.

Actually, if we can split compiler from runtime, Apache could choose
to embed only the runtime engine (no eval()s permitted, obviously) with
a corresponding drop in memory consumption.

I don't know how you'd find out what amount of /usr/bin/perl5 is runtime
vs compiletime.  But I'd like to know.

Nat

Re: A tentative list of vtable functions

[Nathan Torkington]

Jarkko Hietaniemi writes:
> > I'm not too worried about getting the vtbl right at the first because
> > it will be pretty obvious how it should go once the code starts to form.
> 
> Some planning isn't that painful :-)

Yes.  Especially given that vtables are an unbenchmarked change.  It'd
be good to see someone prototype the vtables and then benchmark the
code against similarly fleshed out SV structures.  We need to know
just how much of a hit this is going to be in terms of memory and in
terms of speed.  Everyone's saying "this is the way to go", but I'm
a little afraid that nobody has said why.

Nat

Re: RFC 155 - Remove geometric functions from core

[Nathan Torkington]

David L. Nicol writes:
> This handwringing naysaying is depressing.

Yes, it's depressing to find out there are problems in one's grand
plans.  However, I'm very glad that people (including Tom) are
pointing out problems *before* we commit to a course of action.

Nat

Re: RFC 161 (v2) OO Integration/Migration Path

[Nathan Torkington]

Dan Sugalski writes:
> If the vtable stuff goes into the core perl engine (and it probably will,
> barring performance issues), then what could happen in the

I have a lot of questions.  Please point me to the appropriate place
if they are answered elsewhere.

vtables are tables of C functions?  Perl functions?  Either?  How
would you use them to handle overloading of operators?  One function
in the vtable for every operation?  How does that extend to
user-defined operators?

Nat

Re: RFC 155 - Remove geometric functions from core

[Nathan Torkington]

Tom Christiansen writes:
> further abuse as the next bandit decides to chew on you.  As nobody
> else said mum about that scat, I took care of it myself.

90 minutes passed on a Friday night.  That doesn't mean it wasn't
going to be dealt with.

> >(hint: grown-ups would apologise at this point)
> I'm sorry he said that.

Cute, but flippancy doesn't convince me you're capable of maturity.
If you can't behave, I'll treat you like the little children you are
and give you a time out.  If that fails to moderate your behaviour, I
will take the ability to make trouble out of your grasp by preventing
the mailing list software from accepting messages from you.

This goes for everyone, Stephen as well as Tom.  Name-calling and
petulant messages are the kind of things we're trying to leave behind.

This is supposed to be about perl6, not personalities.  It makes me
grumpy that this is distracting from the work we're supposed to be
doing.  Please don't waste any more of our time with this idiocy.

Thank you,

Nat

Re: RFC 155 - Remove geometric functions from core

[Nathan Torkington]

Tom Christiansen writes:
> Your coquettish plot to reveal the desperate yearning of your
> nethermost alimentary canal for multiply redundant new egresses is
> neither charming nor

And that's offensive.  Please act like a grown-up.  Stephen cast the
first stone, but that's no excuse for you to reply with a boulder.

Nat
(hint: grown-ups would apologise at this point)

Re: RFC 155 - Remove geometric functions from core

[Nathan Torkington]

Stephen P. Potter writes:
> =head1 TITLE
> 
> Perl is Tom's private domain.

That's unproductive.

Nat

Re: RFC 143 (v1) Case ignoring eq and cmp operators

[Nathan Torkington]

David L. Nicol writes:
> Any subroutine declaration, for instance
> 
>   sub Cmp:infix($$){
>   return uc($_[0]) cmp uc($_[1])
>   };
> 
> implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
> it installs the name of the function in a place the clarifier will know
> to look for the definition.
> 
> It doesn't convert it to opcodes, doesn't "parse" it yet, just stores
> the token string.
> 
> Later, while parsing some expression or other, Cmp is encountered.
> 
> BAREWORD:Cmp is looked up in the whaddayaknow table, and there it is,
> an infix subroutine taking two scalar arguments, so if that makes sense
> with what is in front of and behind it, it gets evaluated as such.

Ooookay.  I think there's compile-time and run-time confusion here.
Cmp will get *evaluated* at run-time.  But the decision on what it is
is made at compile-time.

I'd just been picturing:

  sub Cmp :infix { ... }

primes the parser to accept Cmp as an infix subroutine call.
When the parser sees:

  SOMETHING Cmp SOMETHING

it rewrite it as

  Cmp($foo, $bar)

I don't see the need for exceptions to manage that.

I also wonder how to specify the operator's precedence.

Nat

Re: RFC 155 - Remove geometric functions from core

[Nathan Torkington]

Larry Wall writes:
> Tom Christiansen writes:
> : More of this nonsense, eh?
> 
> Please don't use fighting words in here.

On the subject of fighting words, I owe everyone an apology for my
language on the subject of Perl being the only thing that can parse
Perl.  I've been banging my head against program filters lately, and
I'm frustrated that it's so hard.  That's no excuse for exposing you
all to my frustration.  Sorry.

So please take the suggestion (that Perl be more easily toked) without
the swear words.  Thanks.

Nat

Re: RFC 146 (v1) Remove socket functions from core

[Nathan Torkington]

Dan Sugalski writes:
> One of the current plans is for the parser to have access to a list of 
> functions that trigger autoloading modules.

Isn't dynamic loading really slow?  If they're going to incur the
penalty of dynamic loading, you might as make them request that
slowdown by 'use'ing the module.  The alternative is that they
memorize a long list of functions, some of which are slow and some
of which aren't.

Nat

Re: Episode 4 - A New Version

[Nathan Torkington]

Ok, time to head back to planet Earth and the story of perl6.
Back to the grindstone!

Nat
(party pooper)

Re: RFC 146 (v1) Remove socket functions from core

[Nathan Torkington]

Tom Christiansen writes:
> >There are a number of good reasons to do this from an internals standpoint, 
> >enough that I'd like to do it.
> 
> Is one allowed to know that number, and those reasons? :-)

No idea what the internals reasons are.  Here are my reasons:
 * the current socket(), bind(), connect() etc are based VERY closely
   around C, to the point of requiring C structures that are binary
   data which you have to build using a separate module.  So if you're
   using them, you *already* load a module.  Just put the bloody things
   into that module.  You wouldn't lose anything over how it's done
   now.
 * they take magic constants, just like the C function, that are mostly
   the same.  You know the difference between PF_INET and AF_INET, I
   know the difference, but many people do not.  And they shouldn't have
   to.  IO::Socket is a good start at Doing It Right instead of Doing
   The Old Way With Lots of Constants And Arguments.
 * the get*by* for networking stuff (hosts,services,etc) are so rarely
   used they should be moved out.  Yes, it's only a small win.  But
   every byte counts towards a smaller Perl, and moving getprotobyname()
   to a module isn't the same as moving open().

Nat

Re: RFC 127 (v1) Sane resolution to large function returns

[Nathan Torkington]

Perl6 RFC Librarian writes:
> There has been a proposed new core function C. this seems
> to be generally regarded as a good thing. Fine. If it is implemented
> we should use it. Offending functions (See RFC 37) should use
> C internally to determine what to return i.e; a list or a hash.

This implies that the internals can tell 'hash context' from 'list
context', which they current cannot.  Because Perl says you put a
list into a hash:

  $foo = func();# scalar
  @foo = func();# list context
  %foo = func();# still list context

I'm very nervous about adding another context (isn't context confusing
enough already?) without good justification for it.  And this one
situation isn't justification enough.  You could easily say, as RFC 37
does, that the functions return key-value pairs in list context.

That'd make me happy.

Nat

Program lifecycle

[Nathan Torkington]

It seems to me that a perl5 program exists as several things:
 - pure source code (ASCII or Unicode)
 - a stream of tokens from the parser
 - a munged stream of tokens from the parser (e.g., use Foo has
   become  BEGIN { require Foo; Foo->import })
 - an unthreaded and unoptimized optree
 - a threaded optimized optree

Different utilities need access to different representations of a
program:
 - source filters munge the pure source code
 - cpp-like macros would work with token streams
 - pretty printers need unmunged tokens in an unoptimized tree, which
   may well be unfeasible
 - bytecode is saved optimized optree (+stab dumps, interpreter context,
   etc)

Would it make sense for the parsing of a Perl program to be done as:
 - tokenize without rewriting (e.g., use stays as it is)
 - structure without rewriting (e.g., constant subs are unfolded)
 - rewrite for optimizations and actual ops

Then Perl could provide hooks into each stage:
 - source filters take and emit text
 - cpp-like filter takes and emits tokens
 - pretty-printer takes compiled op-tree from a file
 - bytecode dumper gets optimized actual-op tree

Nat

Re: pramgas as compile-time-only

[Nathan Torkington]

Chaim Frenkel writes:
> GB> As Chip says, human intuition is a very bad benchmark.
> 
> Does the cache hit/miss depend on the nearness of the code or simply
> on code path? Obviously having the checked version be a wrapper of
> the base op and near it on the same page would be a VM win.

This sounds like something you're going to need to run code to decide.
Until then you could talk until the cows come home.

Nat

Re: RFC 46 (v1) Use features of portable, free compilers

[Nathan Torkington]

John Tobey writes:
> I am furthermore *not* suggesting dropping support for non-Unix or
> non-GCC platforms.  I am merely saying that that is not where our
> focus should be.

Is there some problem with the current perl5 treatment of gcc that
you're trying to address?  If not, then I don't see the point of the
RFC.

Nat

Re: perl6-internals-gc sublist

[Nathan Torkington]

John Tobey writes:
> OK.  Ask, cancel that request.  Sorry.

In the future, it's best to address your list requests directly
to the working group chair.  They'll decide and ask Ask.  In fact,
asking Ask could probably be done offline.

Nat

Re: ffcall GPL -> LGPL

[Nathan Torkington]

Bradley M. Kuhn writes:
> I wrote http://tmtowtdi.perl.org/rfc/13.pod to propose that we create a
> licensing working group.  It needs someone in authority to create the
> working group.  Unfortunately, I have yet to find out how the process works
> to create new top-level working groups.
> 
> Of course, it could be that no one has gotten time to figure out that
> procedure.  That's understandable.

Hi, that's me.  :-)  Still chewing on it.

Nat

Re: RFC Archive

[Nathan Torkington]

Steve Fink writes:
> What about updating RFCs? Should I increment the version number and send
> each new revision to perl-rfc? Do I need to be careful about the RFC
> number when submitting updates?

Yes and yes.

> Also, I assumed the intention of the RFCs was to stimulate focused
> discussion and to keep a record of the decisions made during that
> discussion in the RFC. Is that true? Or, asked another way, is the
> maintainer of an RFC automatically responsible for tracking the related
> discussions and recording the decisions made in them?

Uh, yes.  The RFC pixies are, unfortunately, not yet implemented.
Until they are, someone will have to maintain the RFCs and that
someone is the, uh, maintainer.  We don't need a daily blow-by-blow,
but when it looks like conclusions have been reached, write 'em up.

Nat

Re: Recording what we decided *not* to do, and why

[Nathan Torkington]

Steve Simmons writes:
> This idea is both important and more general.  If we go thru a huge
> discussion of, say, multi-line comments and decide *not* to do it,
> we don't want to have the whole thing repeated with perl 6.1, 7.0,
> etc, etc.  When something reaches RFC stage but is rejected, part of
> the process should include archiving the gist of the arguements for 
> and against.  IMHO the RFC editor should be responsible for this.

IMHO someone should write an RFC on why perl6 should NOT have
comments.  The RFC editor doesn't have time to follow these zillions
of discussions and write documents based on them.

Nat
RFC,PCR,PHB,whatever :-)

Re: RFC Archive

[Nathan Torkington]

Jonathan Scott Duff writes:
> > In the future, if you want to submit an RFC mail it to
> > [EMAIL PROTECTED] only.  
> 
> http://tmtowtdi.perl.org/rfc/meta/ says that you should send your RFCs to
> [EMAIL PROTECTED] rather than [EMAIL PROTECTED]

They go to the same place.  However, I meant to only mention -rfc, so
please excuse the brainfart of -librarian.  Both work.

Nat

RFC Archive

[Nathan Torkington]

I'm about to push the button that will send my private set of RFCs
off to the archive and mail them to perl6-announce.  Fingers crossed.

The RFC archive is at http://tmtowtdi.perl.org/rfc/

If I've screwed up your RFC, please let me know.

If I've forgotten your RFC, please send it to [EMAIL PROTECTED]

In the future, if you want to submit an RFC mail it to
[EMAIL PROTECTED] only.  The automated process will send it to
the correct list as well as to -announce.  This will also prevent
perl6-librarian being CC:ed on followups.  Don't forget to
double-check you're using the right RFC format (we went around a
few times on it) by looking at http://tmtowtdi.perl.org/rfc/meta/

I also intend to put the RFCs on SourceForge, but I'm almost out of
brain power tonight and wanted to get something up and running as
communal memory.  ETA for SourceForge is probably going to be the end
of the week, but I'm starting to feel burnt out from all the
perl6-related work, so I may hand it off to someone else (Ask?
Turoff?) and they may set their own timetable.

Nat

Re: Where to get RFCs?

[Nathan Torkington]

Ask Bjoern Hansen writes:
> http://tmtowtdi.perl.org/rfc/
> (will soon be http://dev.perl.org/rfc/)

I'm working on it right now, so things will appear and disappear.
I'll post when it's stable.  Please hold :-)

Nat

Re: Stuff in core (was Re: date interface, on language (wasRe: perl6 requirements, on bootstrap))

[Nathan Torkington]

Ken Fox writes:
> pipeline stalls, cache misses and a whole bunch of interesting things. One
> of the reasons Perl performed well is that it spent a lot of time in what
> they called native code, i.e. not decoding and dispatching ops.

One thing we could do is look at the op paths produced by perl5 code
and work out which sequences of ops occur so often that they deserve
to be encapsulated in their own op.  This might give us new ideas on
how to design the ops.

Nat

Re: Summary...tell me where I'm worng...

[Nathan Torkington]

Graham Barr writes:
> Why would the fuzzy regex not be done this way ?

I have some small objections:

I think one regexp syntax with potentially wildly variable
interpretations is a dangerous thing.  If we want fuzzy
regexp matching, either put it into the core's re engine
or make it a module that doesn't use =~ and qr//.

I also think that lexically scoped RE engines are useless.
You want the engine scoped to the pattern, so you can mix
and match fuzzy with traditional (e.g., search engine has
box for pattern and buttons for regular RE or fuzzy, and
all you need to do is say:)

  $pattern = param("pattern");
  if (param("fuzzy")) {
$re = qr/$pattern/f;
  } else {
$re = qr/$pattern/;
  }
  # ...
  while () {
print if /$re/;
  }

My big objection to a dynamically loadable core is my
experience (admittedly limited) with GNOME and Mozilla.
They're big Big BIG ... fat Fat FAT ... pigs Pigs PIGS.
I see the plethora of componentized libraries as part of
the problem.  I fear Perl becoming a big fat pig too.

Nat

Re: RFC: Implementation of Threads in Perl (v1)

[Nathan Torkington]

Bryan C. Warnock writes:
> The librarian bounced, so sending this internals way.

Sorry about that bounce.  It's set up now.  I'm still setting
up the repository (should have done that *before* publishing the RFC
format, I guess :-).  Optimistic ETA: tomorrow.  If it's not up by
then, I'll fall back to a simple web site.

Nat

Re: Summary...tell me where I'm worng...

[Nathan Torkington]

Tim Bunce writes:
> > >The word "pluggable" gives me the willies.  I feel like things like
> > >REs should have one blessed implementation and set of capabilities.
> 
> The key point here is *one blessed implementation*.

(nat as nat)

When I said that, I was keeping in mind that we might have multiple
implementations when we're building a Perl to release, or preparing a
new version of Perl.  But I fear Joe Random User being able to install
their own regexp engine.  That way lies madness, surely.

> If people *want* to say "use My::New:Regex;" and have that install a
> new regex implementation for that lexical scope then we should allow
> that.

I don't hear a good reason for why we'd want this.  All I can see is
that it would lead to yet more crap that someone would have to install
in order to use a module.

> I doubt we'll see multiple regex engines but should shouldn't presume to
> stand in the way of making it possible.

Au contraire.  Some things we should stand in the way of.  I suspect
that this is one.

Nat

Re: Summary...tell me where I'm worng...

[Nathan Torkington]

Dominic Dunlop writes:
> Pluggable regex engines would make supporting (say) core and optional 
> regex language features easier.

(Nat qua Nat speaking)

The word "pluggable" gives me the willies.  I feel like things like
REs should have one blessed implementation and set of capabilities.  I
don't want to have four modules in my program, each of which requires
a different RE engine.

I also don't think that Perl should become a Big Fat Pig[tm] like
GNOME, where you need a half-zillion different shared libraries, each
of which comes from a different source, just to run a program.

If nobody else will, I will RFC this architecture concept: unity.  We
want unity of language design, I think we should shoot for unity of
implementation.  That's not to say that we shouldn't design things
modularly, but encouraging diverging released implementations of the
modules seems like it would only lead to chaos.

Nat

Re: RFC: On-the-fly tainting via $^T

[Nathan Torkington]

I respectfully request that one list be picked for this topic and
discussion confined to that one list even if it should occasionally
spill into the other bailiwick.  Or perhaps it's a candidate for a new
working group.

If all messages are CC:ed to all lists, then simply have p5p reborn
(and the hassle of filtering duplicates).

Nat