Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test

[Alan Burlison]

[EMAIL PROTECTED] 

PIT - Perl Intergration Testers

Alan Burlison

Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test

[Stephen P. Potter]

Lightning flashed, thunder crashed and Alan Burlison <[EMAIL PROTECTED]>
 whispered:
| [EMAIL PROTECTED] 
| 
| PIT - Perl Intergration Testers
| 
| Alan Burlison

Not to pick on Alan, God knows he's been doing us all a real favor lately
with the leaktest stuff.  But can we please stop crossposting this thread
to -announce?  For that matter, does it really need to go to 7 individuals,
and 5 lists?

-spp

Re: RFC 362 - revisiting the RFC process

[Bryan C . Warnock]

On Monday 19 February 2001 22:18, Edward Peschko wrote:
> Speaking of which... apologies in advance for cross-posting this, but I 
wanted
> to get the largest audience possible... I won't do it again. At least not 
in the
> forseeable future.. ;-)

Yes, "forgive me father, for I'm about to sin."
If it warrants an apology, don't do it.

> I did a brief audit of all of the RFC's, and wheras they were a good 
start,
> they are hardly the end-all-be-all for perl6. There were gaps in 
functionality,
> a variance in the quality of the RFC's, and not enough emphasis on 
> implementation. In addition, the discussion on the list did not seem to 
wend
> its way back into the RFC's themselves.

Yes, see below.

> =item 1. that without an RFC process in place, old ideas and discussions 
will
>   rehash themselves on mailing lists ad nauseum.

Yes.

> 
> =item 2. that RFC's are a good starting point for people unfamiliar with
>   with discussions/issues on the mailing list.

Yes.

> 
> =item 3. that RFC's are a good starting point for documentation.

Yes.

> 
> =item 4. that this is perl's first attempt at organizing ideas like this. 
>  Hence, we are newbies at this and are bound to make mistakes the 
first
>  time round. 

Yes.

> 
> However, there is one aspect in which I agree with him. That, as it 
stands, the
> RFCs are incomplete, lack encorporation of discussion, and seem to be 
'out of
> touch' with the rest of the RFCs (to some extent). 

Well, yes, but that was rather the point, wasn't it?

{snip}
 
> Instead, I think that the doors to the RFCs should be re-opened, and that 
they
> should be bulletproofed. 

No, and here's why.

The RFC process wasn't meant to be comprehensive or unidirectional - it was 
a feeder system for the start of Perl 6.  Each RFC wasn't a community 
effort, beyond what feedback the author got, and couldn't really be 
expected to be complete.  Each RFC was also proposed in a vacuum - each 
functionality was standalone - unless the author happened to have written 
another fifty RFCs or so that they could tie into - so there was no way to 
give a true representation of implementation.  The RFCs addressed general 
models for Perl 6 direction, or directions, since there was no specific 
Perl 6 definition to target for.  The RFC stage was designed for what folks 
were passionate about - the most important changes - not an 
all-encompassing picture of Perl 6.  It was prep work.  It was pre- and 
mid-construction bracing.  It was just one stage in the life of Perl 6.
It should be left alone as is, if only to segregate all v2 process from the 
v1 process.

What you are looking for is the (slightly misnamed) PDD, which I 
supposed to be the "end-all-be-all" of Perl 6 (and Perl, to some extent).
It is supposed to a community-driven, comprehensive, living record of what 
is (and was) Perl. 

http://dev.perl.org/pdd/ 

> The next four RFCs suggest methods on how to improve
> the RFC process and the quality of RFCs:
> 
>   RFC 363 - Anyone posting a new RFC should have read all of the existing
>   RFCs first.

Anyone posting just about anything should have some historical perspective 
to draw from.  RFCs, PDDs, mailing lists...

Of course, the problem with the mailing lists is that there are so many 
lists, and it's hard to find anything in them anymore.  (Unless I'm missing 
a search box somewhere for perl6-*)

> 
> RFC 364 - There should be a web interface for people to 
interactively
>   comment on RFCs.

For instance, this was discussed.

> 
> RFC 365 - There should be a rating system for RFCs.

As was this.

> 
> RFC 366 - There should be a culling system for RFCs, a way to 
>   distinguish quickly between withdrawn RFCs and RFCs in 
>   process.

http://dev.perl.org/rfc/by-number.html

> 
> (ps -- no, I haven't written these yet. But if this RFC is acted upon, I 
reserve
> those numbers in advance. ;-))

Which shows that you haven't read the instructions for submitting an RFC.  
:-)

Seriously, though, read PDD 0, and comment on it.  No one else has.
(Follow up post coming.)

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

State of PDD 0

[Bryan C . Warnock]

To date, I've received a whopping zero comments on PDD 0, the defining 
document for the PDD process.  

That means one of five things: 
http:[EMAIL PROTECTED]/msg01126.html

Surely, if the name of a mailing list can generate so much traffic, then 
someone must have something to say, no?  I'm not in *that* many people's 
killfile, am I?

Nat, Dan: PDD 0 is also still at the Proposed level (even though it was 
assigned a number).  Is it at least good enough to bump to Developing?

Dan, Dave Mitchell: your PDDs also list the PDD Format as 1.  Until PDD 0 
is accepted, the Format should also be 0.  (Unless that's something that 
needs to be tweaked in PDD 0's Implementation section.)

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Simon Cozens]

On Tue, Feb 20, 2001 at 09:05:57AM -0500, Bryan C. Warnock wrote:
> To date, I've received a whopping zero comments on PDD 0, the defining 
> document for the PDD process.  

Uhm, you just turned meta-discussion into meta-meta-discussion, and you wonder
why people aren't commenting? :)

Seriously, I think the p5p rule applies here - if people thought it was crap,
you'd know about it by now.

-- 
The UNIX system is harder to use than a toaster.  -Kaare Christian

Re: End-of-scope actions: Toward a hybrid approach.

[Simon Cozens]

On Tue, Feb 20, 2001 at 01:49:45AM -0500, [EMAIL PROTECTED] wrote:
> On Tue, Feb 20, 2001 at 02:14:52AM +, Simon Cozens wrote:
> > > Yes.  And the modules on CPAN that already do this are interesting too.
> > 
> > Oh, bother. Oh well, I've got builtinify (which was actually the point of the
> > exercise) and they haven't, so I'm happy. :)
> 
> Something like Function::Override then? 

Sort of. What I really wanted to do was to be able to say

sub foo { ... }
builtinify(foo);

package bar;
foo(); # Refers to main::foo
package baz;
foo(); # Refers to main::foo

(this is so that the forthcoming Safety::First module can produce exported
functions available throughout the program) which is easily done if you mess
with UNIVERSAL::AUTOLOAD, but what if the user has their own
UNIVERSAL::AUTOLOAD? You need to make sure your version runs first, optionally
passing on control to theirs, which you can to be adding a pre-hook. So I had
to implement pre-hooks. :)

> Want to merge implementations?

I'm open to offers. Take a look at S::V and tell me what you think.

-- 
Jenkinson's Law:
It won't work.

The Unlambda Programming Language

[Juanma Barranquero]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 19 Feb 2001 13:17:56 -0600, "David L. Nicol"
<[EMAIL PROTECTED]> wrote:

> "currying" used in a fascinating context: an experimental 
> language in which
> 
> http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/#tut

In that vein, perhaps (the collective) you wants to visit the
Esoteric Languages' page of Cat's Eye Technologies:

http://www.catseye.mb.ca/

   /L/e/k/t/u

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQA/AwUBOpJ9Cv4C0a0jUw5YEQJFwgCfXc6USTxBcJHbf0vSagVu9ofNVL0AnjN/
TwaFtv8MxYM+mCFp87PlKChe
=0iQ+
-END PGP SIGNATURE-

Re: State of PDD 0

[David Mitchell]

"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> To date, I've received a whopping zero comments on PDD 0, the defining 
> document for the PDD process.  
> 
> That means one of five things: 
> http:[EMAIL PROTECTED]/msg01126.html

Sounded fine to me, but since I'm not one of the Powers, I didnt comment.
I kind of assumed it was up to Dan/Ask/whoever, and if they didnt object,
it had kind of been approved.

> Dan, Dave Mitchell: your PDDs also list the PDD Format as 1.  Until PDD 0 
> is accepted, the Format should also be 0.  (Unless that's something that 
> needs to be tweaked in PDD 0's Implementation section.)

I just copied Dan's, and so propagated any mistakes, (plus added my own, of
course) :-)
Atually I'm not sure if Mere Mortals like myself are allowed to submit
PDDs - I vaguely assumed Dan would chip in and tell me off or something!

Re: PDD for code comments ????

[David Mitchell]

Regarding comments in code:

Chopping and misquoting wildly

Jarkko Hietaniemi said:

* I would define a relatively strict and standard way to do this so that
the documentation can be extracted out.
* lets avoid a markup-up flamewar

Simon Cozens said:

* I'd like to see Perl 6 written as a literate program
* the apidoc is a really good thing, but it needs to be made more extensible
* RFC281 was an initial set of thoughts on this idea.

David L. Nicol said:

/*
=pod
=cut
*/

Whereas I'm about to say

Questions:

1. Does anyone *disagree* that we need "a relatively strict and
standard way" to document code?

2. Is this the time and place to discuss it?

3. Should the result of the discusssion be a PDD?

4. Are we all agreed that in addition to anything else (eg rfc281), at
least some of the standard commentary should appear actually within the
src file itself?

5. Does anyone agree or disagree with my proposal for mandatory
per file, per section, and per func/struct comments?

5. Do *all* these comments need to be extractable, or only ones related
to published APIs etc? 

6. Can we leave the details of pod/apidoc/rfc281 until 1..5 have been
agreed?

7. What is the average air speed velocity of a swallow, etc etc...

Dave M.

PS. I decree that this email solves Warnock's Dilemma [*] by assuming
that silence implies absolute assent to everything I have ever said or
will ever say. ;-)

[*] Or should that be quintlemma, or pentlemma, or ? Any Classics
scholars out there?

Tolkein (was Re: PDD for code comments ????)

[David Mitchell]

> Tolkien quotes are mandatory?
> 
> perl5's globals.c malloc.c perlio.c perly.c universal.c xsutils.c
> definitely fail then.

Sounds like some urgent patches need submitting to p5p ;-)

Re: PDD for code comments ????

[Bryan C . Warnock]

On Tuesday 20 February 2001 10:49, David Mitchell wrote:
> Regarding comments in code:
> 2. Is this the time and place to discuss it?

Certainly before we actually begin coding

> 
> 3. Should the result of the discusssion be a PDD?

Yes.

> 
> 5. Do *all* these comments need to be extractable, or only ones related
> to published APIs etc? 

All extractable comments need to be extractable, which doesn't make sense, 
I know.  There are two, maybe three different kinds of comments - metadata 
type comments (like which API is belongs to, versioning, authorship, etc),
explanatory ( /* one little, two little, three little endians */ ), and 
completely unnecessary ( /* Twas brillig... */  and most prologues )

The first, certainly, whether we plan to extract them now or not.
The second, of course not, they are meaningless without the code.  They're 
often meaningless *with* the code.
The third, maybe, if only for trivialness.  :-)

> 
> 6. Can we leave the details of pod/apidoc/rfc281 until 1..5 have been
> agreed?

Good idea.  Define the why, the what, and then the how.


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: PDD for code comments ????

[Nicholas Clark]

On Tue, Feb 20, 2001 at 03:49:44PM +, David Mitchell wrote:
> 4. Are we all agreed that in addition to anything else (eg rfc281), at
> least some of the standard commentary should appear actually within the
> src file itself?

quote from someone recently "separate documentation is no documentation"
(sorry, forget who) which seemed a nice way of describing it.
I think it would be good to make it so easy to documented code as you
write it that there really would be no excuse not to do it

> 5. Does anyone agree or disagree with my proposal for mandatory
> per file, per section, and per func/struct comments?

Tolkien quotes are mandatory?

perl5's globals.c malloc.c perlio.c perly.c universal.c xsutils.c
definitely fail then.

[globals.c malloc.c miniperlmain.c perly.c regcomp.c regexp.c taint.c
universal.c xsutils.c have no copyright statement.]
embed.pl doesn't add a Tolkien quote or a copyright statement to perl API.c

> 5. Do *all* these comments need to be extractable, or only ones related
> to published APIs etc? 

You have 2 point 5s.
[I feel there must be a Monty Python quote related to this, but apart from
"Rule 6 - there is /no/ rule six" from the Bruces sketch, I'm lost]

It would be good to be able to extract documentation relating to the
implementation behind the APIs, for guts hackers.

> PS. I decree that this email solves Warnock's Dilemma [*] by assuming
> that silence implies absolute assent to everything I have ever said or
> will ever say. ;-)

I don't think "will ever say" holds. And I think I'd phrase it as
"ongoing silence". But apart from that, it seems to be a working
assumption for design proposals.

Nicholas Clark

Re: State of PDD 0

[Dan Sugalski]

At 09:05 AM 2/20/2001 -0500, Bryan C. Warnock wrote:
>To date, I've received a whopping zero comments on PDD 0, the defining
>document for the PDD process.
>
>That means one of five things:
>http:[EMAIL PROTECTED]/msg01126.html
>
>Nat, Dan: PDD 0 is also still at the Proposed level (even though it was
>assigned a number).  Is it at least good enough to bump to Developing?

D'oh! Yes, mark it as Approved, or whichever step is past developing. (I'm 
a little scattered at the moment, so I don't have the doc handy)


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Things have paused... really?

[Simon Cozens]

On Tue, Feb 20, 2001 at 12:10:53PM -0600, Garrett Goebel wrote:
> o  Will experiences from Ruby be assimilated back into Perl? 
> 
> o  What impact will C# and .NET have on Perl 6? Don't forget
>Larry's required reading recommendation:  
>http://windows.oreilly.com/news/hejlsberg_0800.html
> 
> o  Where will the foreign function interface be heading?

The task and the art of language design is - I hate to use the word
"holistic", but, well - holistic. 

It's like, oh, I don't know, writing music. You can't do it in a vacuum -
everything you hear influences you. Everything feeds in - whether it was what
you thought sucked about your last piece, or what worked about your last
piece, or interesting techniques in something you've just heard, or maybe just
the style and "feeling" of a few composers you've been listening to recently. 

Culture matters a *lot*. If I spent a load of time in Canadia, I'd probably
start picking up a few Canadian idioms in my own speech. In that case of
speech, it's hard to avoid them; for language design, they only become
explicit by design. But they're still implicit influences.

So I think it's impossible that interesting things about Ruby, C#, Japanese,
and everything else out there would *not* be *an influence* to some degree. 

Language design is more fun than writing music because you can generalise the
good parts of your influences - if I ripped off one of Michael Nyman's vocal
lines, I'd be a plagiarist, but if I could find a way of ripping off the
*potential* to create vocal lines like his, then I've done something far more
valuable and interesting. (aside: Python is Mahler. Discuss.) So while we may
not end up doing things the way Ruby or Python does them, we'll certainly have
the ability to some something like them.

Or maybe we won't. There has to be some point to having other languages
around, after all. :)

-- 
What happens if a big asteroid hits the Earth?  Judging from realistic
simulations involving a sledge hammer and a common laboratory frog, we
can assume it will be pretty bad. - Dave Barry

Re: State of PDD 0

[Bryan C . Warnock]

On Tuesday 20 February 2001 11:22, Dan Sugalski wrote:
> D'oh! Yes, mark it as Approved, or whichever step is past developing. 
(I'm 
> a little scattered at the moment, so I don't have the doc handy)

Actually, now that I've been updating this, I'm going to hold it at 
development for a little while, if only because I have some more changes 
coming down the pike.  (The actual formatting will stay the same, so I 
guess Simon would call these meta-meta-meta changes.)

Ask, all, are we reusing perl6-rfc as the submittal address, or will there 
be a new one (perl-pdd)? 

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Things have paused... really?

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> >
> >The RFC project should be ongoing and more adaptive.
> 
> It's my understanding that this is, in fact, the plan. The 
> only reason things have paused (and it is a pause, not a
> stop) is that we're waiting for Larry to take what's been
> done so far and build something resembling a coherent base
> we can implement. After that's done then we'll have
> something to work from, which is a good thing.

This is perhaps the 3rd recent "waiting for Larry" comment posted in the
last week. I don't mind waiting... good things take time. But this mushroom
_is_ curious to hear if anyone has got wind of the current state of affairs?

I'm particularly curious to hear what if any ideas Larry will be
contributing beyond the herculean task of digesting, regurgitating, and
whipping Perl 5 + 361 RFC's of varying quality into a language
specification.

o  Will experiences from Ruby be assimilated back into Perl? 

o  What impact will C# and .NET have on Perl 6? Don't forget
   Larry's required reading recommendation:  
   http://windows.oreilly.com/news/hejlsberg_0800.html

o  Where will the foreign function interface be heading?

From: Larry Wall [mailto:[EMAIL PROTECTED]] 2000-11-01 7:06 PM
>
> The hope is to extend Perl's subroutine declaration
> syntax (via types and attributes) to the point where
> a "forward" declaration in Perl of a C, Java, or C#
> routine can supply all the glue information formerly
> supplied by XS.  While this will undoubtedly give us
> some rather strange looking Perl, I'd rather look at
> potentially strange Perl than certainly strange XS.

Re: Tolkein (was Re: PDD for code comments ????)

[David Mitchell]

> > And what about us poor semi-literates who've never heard of Yojimbo ???
> > If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
> > read him :-)
> 
> Adams rather than Pratchett, I'd think. :)

But Pratchet has 20+ books to his credit, so we need never run out of quotes
:-)

Re: Tolkein (was Re: PDD for code comments ????)

[Dan Sugalski]

At 05:57 PM 2/20/2001 +, David Mitchell wrote:
> > Do we want to go with Tolkein quotes for perl 6 and, if so, who wants to
> > put together a list of good ones? It's been ages since I've read the 
> books,
> > and I'm likely to pull quotes from other places anyway. (Usagi Yojimbo
> > strikes me as a good place to yank from, as does Zot!, but Pratchett will
> > do too...)
>
>Err, would that be Larry's prerogative ???

Yep, it would. Hence the call for a list of quotes from LOTR. :)

>And what about us poor semi-literates who've never heard of Yojimbo ???
>If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
>read him :-)

Sheesh, kids today. You can't even count on anyone having a misspent youth 
anymore...

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Tolkein (was Re: PDD for code comments ????)

[Simply Hao]

> Douglas Adams does seem rather more appropriate a source of quotes
> for software (anyone's, alas) than Pratchett.

But Adams already has a software company.

-Hao

Re: PDD for code comments ????

[David L. Nicol]

David Mitchell wrote:

> 4. Are we all agreed that in addition to anything else (eg rfc281), at
> least some of the standard commentary should appear actually within the
> src file itself?

s/at least some/most, if not all/

> 5. Do *all* these comments need to be extractable, or only ones related
> to published APIs etc?

Initially the automaton creates them all extractable, and the coder
can depod the ones that are implementation details and should not be
published, as a measure more extreme than noting "This function is
an implementaion detail" in the mandatory comment for the function.  Which
implies an at least implicit standard lexicon of flexibility to use in these
comments, ranging from "implements ISO standard interface" down to
"experimental - failed, remove during clean-up phase"
 
> 6. Can we leave the details of pod/apidoc/rfc281 until 1..5 have been
> agreed?

I can't.  Can you?  Altering a C prettyprinter to insert an extensible
standard comment template before each function definition would be even
easier than writing one from scratch.  But what goes in that block of text,
beyond

/*
=pod
=head1 function $FunctionName returning $ReturnType

=head1 Named arguments: @ArgNameList

=cut
*/

Re: Tolkein (was Re: PDD for code comments ????)

[H.Merijn Brand]

On Tue, 20 Feb 2001 19:17:25 + Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2001 at 07:43:11PM +0100, H.Merijn Brand wrote:
> > My name (Merijn) is *from* Tolkien's dutch translation, so I'm a little biases
> > if I state: "Stick with Tolkien". Well, I'm of to Mordor now ...
> 
> http://www.prembone.com/mythtakes/shiresong.html   

| Holy Mordor!  I have been removed
| I've been made a spectre, I don't know what to do
| Distant island of Elvenkind
| Brand of people who ain't my kind
  ^
| Holy Mordor!  I have been removed

See! They even use my surname! :-))

-- 
H.Merijn Brand
using perl5.005.03 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC
 OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.020 and/or DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Member of Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)

Re: Tolkein (was Re: PDD for code comments ????)

[Simon Cozens]

On Tue, Feb 20, 2001 at 07:43:11PM +0100, H.Merijn Brand wrote:
> My name (Merijn) is *from* Tolkien's dutch translation, so I'm a little biases
> if I state: "Stick with Tolkien". Well, I'm of to Mordor now ...

http://www.prembone.com/mythtakes/shiresong.html   

-- 
"It's God.  No, not Richard Stallman, or Linus Torvalds, but God."
(By Matt Welsh)

Re: Tolkein (was Re: PDD for code comments ????)

[Dan Sugalski]

At 07:52 PM 2/20/2001 +0200, Roman M. Parparov wrote:
>On Tue, Feb 20, 2001 at 05:57:10PM +, David Mitchell wrote:
> > > Do we want to go with Tolkein quotes for perl 6 and, if so, who wants to
> > > put together a list of good ones? It's been ages since I've read the 
> books,
> > > and I'm likely to pull quotes from other places anyway. (Usagi Yojimbo
> > > strikes me as a good place to yank from, as does Zot!, but Pratchett 
> will
> > > do too...)
> >
> > Err, would that be Larry's prerogative ???
> >
> > And what about us poor semi-literates who've never heard of Yojimbo ???
> > If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
> > read him :-)
>
>Adams rather than Pratchett, I'd think. :)

Douglas Adams does seem rather more appropriate a source of quotes for 
software (anyone's, alas) than Pratchett.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Tolkein (was Re: PDD for code comments ????)

[Buddha Buck]

At 06:18 PM 02-20-2001 +, Nicholas Clark wrote:
>As long as Terry Pratchett writes books faster than perl consumes quotes.
>Based on the fact that he's still very alive, we aren't in danger yet.

True...  And he has some very good quotes.

>However, Larry has already commented on the danger of running out of LOTR
>quotes:
>
>http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-02/msg00369.html

That thread does raise another concern in my mind.  While a quote here and 
a quote there would constitute "Fair Use", if we are seriously in danger of 
running out of quotes, we are pushing the bounds of "Fair Use".

I think, for copyright considerations alone, it's worth expanding to other 
authors.

"Literate Programming"?  Well, the Perl source is well read...

>Nicholas Clark

Re: Tolkein (was Re: PDD for code comments ????)

[H.Merijn Brand]

On Tue, 20 Feb 2001 18:18:31 + Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2001 at 06:06:49PM +, David Mitchell wrote:
> > > > And what about us poor semi-literates who've never heard of Yojimbo ???
> > > > If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
> > > > read him :-)
> > > 
> > > Adams rather than Pratchett, I'd think. :)
> > 
> > But Pratchet has 20+ books to his credit, so we need never run out of quotes
> > :-)
> 
> As long as Terry Pratchett writes books faster than perl consumes quotes.
> Based on the fact that he's still very alive, we aren't in danger yet.
> 
> However, Larry has already commented on the danger of running out of LOTR
> quotes:
> 
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-02/msg00369.html

My name (Merijn) is *from* Tolkien's dutch translation, so I'm a little biases
if I state: "Stick with Tolkien". Well, I'm of to Mordor now ...

-- 
H.Merijn Brand
using perl5.005.03 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC
 OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.020 and/or DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Member of Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)

Re: Tolkein (was Re: PDD for code comments ????)

[Nicholas Clark]

On Tue, Feb 20, 2001 at 06:06:49PM +, David Mitchell wrote:
> > > And what about us poor semi-literates who've never heard of Yojimbo ???
> > > If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
> > > read him :-)
> > 
> > Adams rather than Pratchett, I'd think. :)
> 
> But Pratchet has 20+ books to his credit, so we need never run out of quotes
> :-)

As long as Terry Pratchett writes books faster than perl consumes quotes.
Based on the fact that he's still very alive, we aren't in danger yet.

However, Larry has already commented on the danger of running out of LOTR
quotes:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-02/msg00369.html

Nicholas Clark

Re: Tolkein (was Re: PDD for code comments ????)

[Dan Sugalski]

At 04:50 PM 2/20/2001 +, David Mitchell wrote:
> > Tolkien quotes are mandatory?
> >
> > perl5's globals.c malloc.c perlio.c perly.c universal.c xsutils.c
> > definitely fail then.
>
>Sounds like some urgent patches need submitting to p5p ;-)

Do we want to go with Tolkein quotes for perl 6 and, if so, who wants to 
put together a list of good ones? It's been ages since I've read the books, 
and I'm likely to pull quotes from other places anyway. (Usagi Yojimbo 
strikes me as a good place to yank from, as does Zot!, but Pratchett will 
do too...)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Tolkein (was Re: PDD for code comments ????)

[Roman M. Parparov]

On Tue, Feb 20, 2001 at 05:57:10PM +, David Mitchell wrote:
> > Do we want to go with Tolkein quotes for perl 6 and, if so, who wants to 
> > put together a list of good ones? It's been ages since I've read the books, 
> > and I'm likely to pull quotes from other places anyway. (Usagi Yojimbo 
> > strikes me as a good place to yank from, as does Zot!, but Pratchett will 
> > do too...)
> 
> Err, would that be Larry's prerogative ???
> 
> And what about us poor semi-literates who've never heard of Yojimbo ???
> If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
> read him :-)

Adams rather than Pratchett, I'd think. :)

-- 
Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
Email: [EMAIL PROTECTED]   http://www.komkon.org/~romm
Phone/Fax: +972-(0)3-6405205 (work), +972-(0)54-629-884 (home)
--
The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann

Re: Tolkein (was Re: PDD for code comments ????)

[David Mitchell]

> Do we want to go with Tolkein quotes for perl 6 and, if so, who wants to 
> put together a list of good ones? It's been ages since I've read the books, 
> and I'm likely to pull quotes from other places anyway. (Usagi Yojimbo 
> strikes me as a good place to yank from, as does Zot!, but Pratchett will 
> do too...)

Err, would that be Larry's prerogative ???

And what about us poor semi-literates who've never heard of Yojimbo ???
If we can't go with Tolkien, I'd vote for Pratchett, 'cause *everyone*'s
read him :-)

Re: Things have paused... really?

[Dave Rolsky]

On Tue, 20 Feb 2001, Dan Sugalski wrote:

> At 01:32 PM 2/20/2001 -0600, Dave Rolsky wrote:
> >
> >Hmm, I think of Python as more Babbit than Mahler.  Perl is ... John Cage?
>
> Would that mean that perl 6 corresponds to 4'33"? (If I have the composers
> right...)

As someone else pointed out, you are correct.  However, that's not exactly
what I was thinking with that analogy.  If Perl 6 is 4'33" that would be
most unfortunate.

Actually, I was thinking of the difference between "there is one way"
(Python & Babbitt's serialism (side note: Babbitt is a _really_ nice guy
and not a crazy fascist though I can't stand his music)) and TMTOWTDI
(John Cage for sure).


-dave

/*==
www.urth.org
We await the New Sun
==*/

Re: Things have paused... really?

[Dave Rolsky]

On Tue, 20 Feb 2001, Simon Cozens wrote:

> valuable and interesting. (aside: Python is Mahler. Discuss.) So while we may

Hmm, I think of Python as more Babbit than Mahler.  Perl is ... John Cage?


-dave

/*==
www.urth.org
We await the New Sun
==*/

Re: State of PDD 0

[Dan Sugalski]

At 01:05 PM 2/20/2001 -0500, Bryan C. Warnock wrote:
>On Tuesday 20 February 2001 11:22, Dan Sugalski wrote:
> > D'oh! Yes, mark it as Approved, or whichever step is past developing.
>(I'm
> > a little scattered at the moment, so I don't have the doc handy)
>
>Actually, now that I've been updating this, I'm going to hold it at
>development for a little while, if only because I have some more changes
>coming down the pike.  (The actual formatting will stay the same, so I
>guess Simon would call these meta-meta-meta changes.)

Fair enough. PDD 0, version 2... :)

>Ask, all, are we reusing perl6-rfc as the submittal address, or will there
>be a new one (perl-pdd)?

Let's use perl-rfc for now.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Things have paused... really?

[Dan Sugalski]

At 01:32 PM 2/20/2001 -0600, Dave Rolsky wrote:
>On Tue, 20 Feb 2001, Simon Cozens wrote:
>
> > valuable and interesting. (aside: Python is Mahler. Discuss.) So while 
> we may
>
>Hmm, I think of Python as more Babbit than Mahler.  Perl is ... John Cage?

Would that mean that perl 6 corresponds to 4'33"? (If I have the composers 
right...)

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Things have paused... really?

[David H. Adler]

On Tue, Feb 20, 2001 at 02:33:48PM -0500, Dan Sugalski wrote:
> At 01:32 PM 2/20/2001 -0600, Dave Rolsky wrote:
> >On Tue, 20 Feb 2001, Simon Cozens wrote:
> >
> > > valuable and interesting. (aside: Python is Mahler. Discuss.) So while 
> > we may
> >
> >Hmm, I think of Python as more Babbit than Mahler.  Perl is ... John Cage?
> 
> Would that mean that perl 6 corresponds to 4'33"? (If I have the composers 
> right...)

You do, but surely it's been longer than that since we've heard
anything... :-)

dha
-- 
David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/
tastes filling! less great!   - ignatz in #perl

Re: Closures and default lexical-scope for subs

[Peter Scott]

At 05:27 PM 2/19/01 +, Piers Cawley wrote:
>Peter Scott <[EMAIL PROTECTED]> writes:
> > I don't want to DWIM this.  Would it be so bad to have to type
> >
> >  GetOptions (foo => \my ($foo),
> >  bar => \my $bar);
>
>If you're really all for maintainability, then surely you mean:
>
>GetOptions (foo => \my ($foo),
>bar => \my ($bar));
>
>otherwise some dumb hacker (eg. You, two weeks later) could come to
>add annother pair of args by sticking C<, baz => \my $baz> into the
>args list...

Yup, yup.

> >  tie my ($shoe) => $tring;
> >
> > if we made 'my' consistent with all other functions that take lists
> > (yes-I-know-it's-not-a-function)?
>
>Do you not *care* how ugly you're making something that was once
>compact, expressive and elegant?

Of course I care.  I just weighed the advantage (consistency, intuitiveness 
in the case of my $a, $b, $c which is far more common than either of the 
above) against the disadvantage and decided it was worth it, on 
balance.  Subscribers to different value systems may have different results.

>And if it's not a function then WTF
>do you want to make it look like one, potentially sowing more
>confusion.

I'd be happy to retract my position if someone would take the thing out of 
perlfunc then.  I'd really also like to see a more definitive description 
than "language construct" at the same time.
--
Peter Scott
Pacific Systems Design Technologies

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Stephen P. Potter]

Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> whispered
:
| Yep; the perl manpage has said, since time immemorial, that 
| the fact that -w was not on by default is a BUG.

I don't know that I would say time immemorial.  It wasn't in the man for
4.036.  I can only find man pages back to 5.002 right now, so I can't
check any earlier than that in the 5 tree.  However, it was meant to be
(more than) slightly tongue-in-cheek.

-spp

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 14:45, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]> 
whispered
> :
> | Yep; the perl manpage has said, since time immemorial, that 
> | the fact that -w was not on by default is a BUG.
> 
> I don't know that I would say time immemorial.  It wasn't in the man for
> 4.036.  I can only find man pages back to 5.002 right now, so I can't
> check any earlier than that in the 5 tree.  However, it was meant to be
> (more than) slightly tongue-in-cheek.

And there's a difference between warnings originating because something has 
gone wrong and those originating because I'm doing something particularly 
perlish.  Unfortunately, -w doesn't (and probably can't) tell the 
difference.



A friend of mine was attempting to install some commercial program (a D&D 
character generator, IIRC) on a Windows box - one that didn't have a sound 
card.  It wouldn't run.  It always crashed while trying to talk to the 
sound card.  He procured someone else's laptop to do a demo install, and it 
ran fine - there are open and close window sound effects, and this 
voice-over guy that gives instructions.  The first instruction given in the 
setup box? If you'd like to turn off the voice, click this box.  Nothing 
else is sound dependent.  Somehow I think there's a lesson to be learned 
here.


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[John Porter]

Bryan C. Warnock wrote:
> 
> And there's a difference between warnings originating because something has 
> gone wrong and those originating because I'm doing something particularly 
> perlish.  Unfortunately, -w doesn't (and probably can't) tell the 
> difference.

Can you give me an example of the former?
I can't think of any off the top of my head.

-- 
John Porter

Re: End-of-scope actions: Background.

[Graham Barr]

On Tue, Feb 20, 2001 at 03:49:13AM +, Simon Cozens wrote:
> On Mon, Feb 12, 2001 at 01:58:35PM -0700, Tony Olekshy wrote:
> > Hi, it's me again, the guy who won't shut up about exception handling.
> > I'm trying,
> 
> I'm catching.

And I'm thowing (up :)

Graham.

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 16:03, John Porter wrote:
> Bryan C. Warnock wrote:
> > 
> > And there's a difference between warnings originating because something 
has 
> > gone wrong and those originating because I'm doing something 
particularly 
> > perlish.  Unfortunately, -w doesn't (and probably can't) tell the 
> > difference.
> 
> Can you give me an example of the former?
> I can't think of any off the top of my head.

Scalar value @foo[$bar] better written as $foo[$bar], for one.

(But you probably would have thought of that if I had said something better 
than "something has gone wrong" which doesn't describe the above at all.  
I'm sorry, a completely horrible phrasing of what I was trying to say - 
I'll take me out back and shoot me now.)

I'll try this again - the difference between a perceived user error, and a 
misused perl construct.  The above error reflects an inability to 
distinguish between mulitple typos: either $foo or a list index.

If part of Perl's breeding is autovivication and interpretation of undef as 
0 or "" in the appropriate context, why should Perl bitch at me if I use it 
as such?  Why should I have to ask permission to do so?

I would rather say, and I think it would be more perlish to say, "I'm not 
feeling particularly perly today, can you check for anything clever, cause 
if there is, chances are it's a mistake."


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[John Porter]

What it boils down to is, warnings are for perl to tell you
when you probably made a logic error, based on the perl code
it sees.  What some people might think is merely unperlish
code, others might say is "horribly wrong".

-- 
John Porter

Re: ANNOUNCE: smokers@perl.org Discussion of perl's daily build and smoke test

[Mike Lacey]

People call it "Soak Testing" when they test electronics don't they?

[EMAIL PROTECTED]?

nah 

- Original Message -
From: "Stephen P. Potter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 12:56 PM
Subject: Re: ANNOUNCE: [EMAIL PROTECTED] Discussion of perl's daily build and
smoke test


> Lightning flashed, thunder crashed and Alan Burlison
<[EMAIL PROTECTED]>
>  whispered:
> | [EMAIL PROTECTED]
> |
> | PIT - Perl Intergration Testers
> |
> | Alan Burlison
>
> Not to pick on Alan, God knows he's been doing us all a real favor lately
> with the leaktest stuff.  But can we please stop crossposting this thread
> to -announce?  For that matter, does it really need to go to 7
individuals,
> and 5 lists?
>
> -spp

Re: Tolkein (was Re: PDD for code comments ????)

[David L. Nicol]

Simply Hao wrote:

> > Douglas Adams does seem rather more appropriate a source of quotes
> > for software (anyone's, alas) than Pratchett.
> 
> But Adams already has a software company.

And Sirius pioneered the GPP in Perl 6.

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 19:34, Edward Peschko wrote:

> Well, for one, your example is ill-considered. You are going to get 
> autovivification saying:
> 

The two ideas were disjoint.  The example wasn't an example of autoviv.

> Hence I'd say that @foo[$bar] has NO INTRINSIC VALUE whatsoever.

Correct, which is why I could care less if Perl warns me about it.

> 
> Second, with the keyword empty (if it comes to pass) the reasons for 
> interpretation of undef as 0 and "" go away. Right now, things are a PITA 
> to get empty values:
> 
> my ($a, $b, $c, $d, $e) = ('') x 5;

I *like* the interpretation of undef as 0 and "".  It's useful.  Sometimes.
Sometimes it's not.  And that's fine.  

> 
> With empty:
> 
> my ($a, $b, $c, $d, $e) = empty;

There's no reason in the world why that should replace undef -> 0 and "".

> 
> > I would rather say, and I think it would be more perlish to say, "I'm 
not 
> > feeling particularly perly today, can you check for anything clever, 
cause 
> > if there is, chances are it's a mistake."
> 
> Or how about "I'm feeling particularly lazy today, I think I'll sleep in. 
Lets
> worry about any mistakes I might make another day."

Well, Laziness is One of the Three.

Let me rephrase.
Perl shouldn't bitch at me for valid perl.

> 
> For i maintain that any 'cleverness' that you might have that causes 
warnings 
> in perl6 will *probably* be a mistake.

Certainly, because it seems that all things inherently Perl are being 
removed from the language.  :-(

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bart Lateur]

On Tue, 20 Feb 2001 16:31:35 -0500, Bryan C. Warnock wrote:

>Scalar value @foo[$bar] better written as $foo[$bar], for one.

I agree on this one (hash slices too), if this expression is in list
context. There is no error in

@r = map { blah } @foo{$bar};

-- 
Bart.

Re: State of PDD 0

[Bryan C . Warnock]

On Tuesday 20 February 2001 17:43, Peter Scott wrote:
> I suggest that we clearly delineate the RFCs which were pre-deadline from 
> the ones that are post-deadline.  The advantage to having the original 
> deadline was that it motivated many of us to get off our butts and fish 
or 
> cut bait.  If we're going to continue this process now, I move that:
> 
> New RFCs be numbered starting from 1000 (easiest way to denote the 
difference);
> 
> Old RFCs are frozen, and that means frozen.  I have no idea how far 
Larry's 
> got on digesting them and I really don't want to try and interfere with 
> something that could be making its way down his small intestine.  People 
> should be free to write new RFCs that contradict older ones, or head off 
on 
> some tangent, but please let's not keep refining the old ones, enough is 
> enough.

Regardless of the outcome, the initial set of RFCs should be set off 
somewhere.  (And a lot of them aren't listed as frozen, at that!)

> 
> 
> --
> Peter Scott
> Pacific Systems Design Technologies

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: RFC archive?

[Adam Turoff]

On Tue, Feb 20, 2001 at 04:58:11PM -0800, Matthew Cline wrote:
> What's the URL for the RFC archive?

http://dev.perl.org/rfc/

Z.

Re: C Garbage collector

[Alan Burlison]

Alan Burlison wrote:

> I've attached the HTML

Well it was there when I sent it... does this list strip attachments or
something?
 
Here is is as badly-formatted text - sorry!

Alan Burlison


Appendix A: How Sun WorkShop Memory Monitor Works 

Memory management in C/C++ is both time consuming and
error prone. Typically, about one-third of development time
is spent on memory management, and most commercially
available programs ship with memory leaks or premature
frees. Even worse, no matter how well written your own
code is, third-party libraries and DLLs used by your
program may leak, leaving you with no way to deliver
leak-free applications.

Imagine what would happen if memory just freed itself when
it was no longer in use. Programs that freed memory in the
wrong place would automatically be fixed, and new code
wouldn't need to free memory at all. Such automatic
garbage collection is the standard in Java and Smalltalk.
I'll lift the hood on the Sun WorkShop Memory Monitor
garbage collector, focusing on the details that make it
practical, transparent, and scalable.

Why Garbage Collection? 

The basic idea behind garbage collection is refreshingly logical. As a
program runs, the garbage collector
periodically scans the program's data marking everything that is in use.
It begins by scanning the
program's stack, registers, and the static segment. Every time it
encounters a pointer, it marks the object
that it points to. Then it scans the object for pointers to other heap
objects. Once it has marked all
reachable heap objects, it frees all the objects that haven't been
marked (see Figure 1).

The hard part of adapting garbage collection to C/C++ is identifying
pointers. Since object libraries and
DLLs often lack source, you can't examine the source for type
information, and you can't recompile.
Typically, you don't even have debugging information. The only remaining
option is to relink. This isn't as
bad as it sounds, since relinking lets you redefine whatever functions
you like.

What functions should you redefine? The natural candidates are
memory-management functions --
malloc(), free(), new, and delete. Redefining free() and delete to Null
operations protects the
programmer from premature frees. This leaves only the malloc() and new
allocators.

But how does this help you identify pointers? A solution to this problem
was first observed by Hans Boehm
and Mark Weiser. (For more information, see their article, "Garbage
Collection In an Uncooperative
Environment," Software Practice and Experience, September 1988, as well
as Boehm's "Advantages and
Disadvantages of Conservative Garbage Collection," at
ftp://parcftp.xerox.com/pub/gc/issues.html.)
Allocators keep track of what memory has been allocated. You can test
whether a data word points inside
an allocated object. If so, it's probably a pointer. Is this test always
right? No, but it's a start.

Sun WorkShop Memory Monitor implements a refined version of this
pointer-finding strategy through a
custom allocator that can efficiently report on the status of any
address. Once you can identify pointers,
you can garbage collect a program.

We Interrupt this Program... 

Proper scheduling may be the most important factor in garbage collector
performance. The earliest
collectors only performed garbage collection when the computer ran out
of memory. When a collection
finally occurred, it analyzed the computer's entire address memory,
interrupting operation for long periods
of time. No wonder early garbage collectors were invariably associated
with annoying interruptions of
program operation.

Many current garbage collectors, especially Java collectors, rely
primarily on a low-priority background
thread to schedule garbage collection. This approach sounds good, but
leads to poor performance. The
low-priority background thread provides lots of garbage collection to
inactive programs that don't need it.
By the same token, computation-intensive programs require large amounts
of garbage collection, but don't
receive any because the background collection thread doesn't have a
chance to run since such a program
always demands CPU cycles. As a result, background collection threads
should, at best, supplement some
other primary collection strategy.

Sun WorkShop Memory Monitor decides when to collect garbage by watching
how much memory has been
allocated since the last collection. This way, programs that use lots of
dynamic memory allocation receive
the collection they need, while programs that don't allocated much
memory don't waste a lot of time doing
unnecessary garbage collection.

To further limit program interruptions, you can do only a small part of
the garbage collection each time. At
first glance, this seems impossible. The heap is constantly changing, so
how can you know that the
analysis from earlier partial collections is still correct?
Memory-management hardware in the CPU provides
some help. After analyzing a page of memory, simply "write-protect" that
page

C Garbage collector

[Alan Burlison]

Documentation excerpt:

With Sun WorkShop Memory Monitor, you can program without calling free()
or delete. Determining when to call free() or delete is difficult. 
Studies indicate that 30% to 40% of programmer time is spent on memory
management in C or C++ programs. Failing to release memory causes memory
leaks, which refers to the accumulation of unused memory in the program,
ultimately causing the program to monopolize or even run out of memory.
Releasing memory too early leaves loose pointers, which are pointers
that do not point to valid memory. Using loose pointers invariably
causes data corruption, segmentation faults, or general protection
violations. Sun WorkShop Memory Monitor automatically eliminates the
problems of freeing memory at the wrong time.

In the field, Sun WorkShop Memory Monitor automatically protects your
program against memory leaks and premature frees, even those in
third-party libraries. Simply linking with Sun WorkShop Memory Monitor
automatically eliminates any leaks. In deployment mode, Sun WorkShop
Memory Monitor's high-performance memory allocator makes your programs
run faster and consume less memory. 

Sounds like nirvana ;-)

Shame it only works with the Sun compilers.

However, there is an explanation of how it works that might be useful
when considering how to do this for perl6.  I've attached the HTML -
sorry about the broken links, but I don't think this is on any
externally-visible webpage.

Alan Burlison

RFC archive?

[Matthew Cline]

What's the URL for the RFC archive?

Thanks in advance.

-- 
Matthew Cline| Suppose you were an idiot.  And suppose that
[EMAIL PROTECTED] | you were a member of Congress.  But I repeat
 | myself.  -- Mark Twain

Re: C Garbage collector

[Damien Neil]

On Wed, Feb 21, 2001 at 12:25:10AM +, Alan Burlison wrote:
> Shame it only works with the Sun compilers.

See also Boehm's garbage collector, which is rather more portable:
  http://www.hpl.hp.com/personal/Hans_Boehm/gc/

  "The collector uses a mark-sweep algorithm.  It provides incremental
  and generational collection under operating systems which provide
  the right kind of virtual memory support.  (Currently this includes
  SunOS[45], IRIX, OSF/1, Linux, Windows NT, and Windows 95, with
  varying restrictions.) It allows finalization code to be invoked
  when an object is collected.  It can take advantage of type
  information to locate pointers if such information is provided,
  but it is usually used without such information."

   - Damien

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Edward Peschko]

> > 
> > Can you give me an example of the former?
> > I can't think of any off the top of my head.
> 
> Scalar value @foo[$bar] better written as $foo[$bar], for one.
> 
> If part of Perl's breeding is autovivication and interpretation of undef as 
> 0 or "" in the appropriate context, why should Perl bitch at me if I use it 
> as such?  Why should I have to ask permission to do so?

Well, for one, your example is ill-considered. You are going to get 
autovivification saying:

@foo[$bar] = 1;

just as much as you are going to get autovivification for:

$foo[$bar] = 1;

Hence I'd say that @foo[$bar] has NO INTRINSIC VALUE whatsoever.

Second, with the keyword empty (if it comes to pass) the reasons for 
interpretation of undef as 0 and "" go away. Right now, things are a PITA 
to get empty values:

my ($a, $b, $c, $d, $e) = ('') x 5;

With empty:

my ($a, $b, $c, $d, $e) = empty;

> I would rather say, and I think it would be more perlish to say, "I'm not 
> feeling particularly perly today, can you check for anything clever, cause 
> if there is, chances are it's a mistake."

Or how about "I'm feeling particularly lazy today, I think I'll sleep in. Lets
worry about any mistakes I might make another day."

For i maintain that any 'cleverness' that you might have that causes warnings 
in perl6 will *probably* be a mistake.

Ed

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[Edward Peschko]

> > RFC 362
> > ---
> ...
> > The RFC process should not have had an artificial deadline; it should be an
> > adaptive process that should last the entire development cycle of perl6 and
> > perhaps after.
> 
> Should is a very dangerous word.

its a very useful word too sometimes... ;-)

> RFC 363 - Anyone posting a new RFC should have read all of the 
>   existing RFCs first.
> 
> Not just "relevant"?

No, not just relevant. I think it should be rite of passage, a way for people
to educate themselves on what's there and what's not. Sort of like reading the
FAQ.

> > RFC 364 - There should be a web interface for people to interactively
> >   comment on RFCs.
>  
> > RFC 365 - There should be a rating system for RFCs.
>  
> > RFC 366 - There should be a culling system for RFCs, a way to
> >   distinguish quickly between withdrawn RFCs and RFCs in
> >   process.
> 
> These are nice daydreams.  Please feel free to go ahead with these projects.
> Do you need a cgi-enabled web server?  I can see what I can do towards providing
> you one.

yeah, ok, I'd be willing to do this (in lieu of writing RFCs), as long as the 
RFC issue was definitely a permanent/semi-permanent feature of the language. 
I'm assuming that most of this GUI could be translated over to PDD's too, and 
perhaps PCR's.

And yeah it would be nice to have access to an 'official' CGI-enabled web 
server, after something was working.

Ed

Re: State of PDD 0

[Dan Sugalski]

At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote:
>Bryan C. Warnock writes:
> > Ask, all, are we reusing perl6-rfc as the submittal address, or will there
> > be a new one (perl-pdd)?
>
>I'm in favour of renaming to reflect the new use of the list.  Dan?

I've been thinking since I sent my last mail on this that we might actually 
want to leave the two (PDD & RFC) separate. Keep on with the RFCs for 
'external' things, and PDD for the actual internals implementation of things.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 362 - revisiting the RFC process

[Edward Peschko]

On Tue, Feb 20, 2001 at 08:47:58AM -0500, Bryan C. Warnock wrote:
> On Monday 19 February 2001 22:18, Edward Peschko wrote:
> > Speaking of which... apologies in advance for cross-posting this, but I 
> wanted
> > to get the largest audience possible... I won't do it again. At least not 
> in the
> > forseeable future.. ;-)
> 
> Yes, "forgive me father, for I'm about to sin."
> If it warrants an apology, don't do it.

Unfortunately, some sins are worth doing. This is one of them. I gauged that the
larger audience was worth the flak that I would get. I think I was right.

> Well, yes, but that was rather the point, wasn't it?

No I don't think that's true.. I think that RFC's are much more powerful if they
work at least somewhat in concert. At the very least, the knowledge of the other
RFC's help come up with new ideas...

> The RFC process wasn't meant to be comprehensive or unidirectional - it was 
> a feeder system for the start of Perl 6.  Each RFC wasn't a community 
> effort, beyond what feedback the author got, and couldn't really be 
> expected to be complete.  Each RFC was also proposed in a vacuum - each 
> functionality was standalone - unless the author happened to have written 
> another fifty RFCs or so that they could tie into - so there was no way to 
> give a true representation of implementation.  The RFCs addressed general 
> models for Perl 6 direction, or directions, since there was no specific 
> Perl 6 definition to target for.  The RFC stage was designed for what folks 
> were passionate about - the most important changes - not an 
> all-encompassing picture of Perl 6.  It was prep work.  It was pre- and 
> mid-construction bracing.  It was just one stage in the life of Perl 6.
> It should be left alone as is, if only to segregate all v2 process from the 
> v1 process.

But that's the point - as it is, the RFC's are an insufficient source of 
raw material for the v2 processes that you describe.

I think of RFC's as 'high level design'. The PDD's that you are describing
are low-level design, reality chipping in after reading all of the RFCs and
deciding how to implement them. And I don't think that PDD's should be 
shoehorned to fit both roles.

And look at it this way. RFC's were an experiment that was *very* successful. Or
at least very popular.  361 RFCs, just by the count of them is a smashing
success.

No, I think that there really should be two levels of docs. One, a scratchpad,
the second a 'lets do this, here's how we are going to do it.' type of doc.
And one can be the starting point for the other. 

> What you are looking for is the (slightly misnamed) PDD, which I 
> supposed to be the "end-all-be-all" of Perl 6 (and Perl, to some extent).
> It is supposed to a community-driven, comprehensive, living record of what 
> is (and was) Perl. 

Again, I don't think that *is* what I'm looking for. I think that RFC's 
could be a very convenient way of reducing the amount of redundant traffic on 
mailing lists, as well as standardizing the dialog. And as I said, I don't think
that *either* the RFC's or the PDD's should be 'comprehensive'. That's asking
too much.

I'll clarify these points in the RFC.

Ed

Re: State of PDD 0

[Edward Peschko]

On Tue, Feb 20, 2001 at 02:15:56PM -0700, Nathan Torkington wrote:
> Bryan C. Warnock writes:
> > Ask, all, are we reusing perl6-rfc as the submittal address, or will there 
> > be a new one (perl-pdd)? 
> 
> I'm in favour of renaming to reflect the new use of the list.  Dan?

How about two lists?

I still think that there should be a two-tiered process. I think its a mistake
to have a 'one size fits all' process. See my other post on this.

Ed

Re: State of PDD 0

[Nathan Torkington]

Bryan C. Warnock writes:
> Ask, all, are we reusing perl6-rfc as the submittal address, or will there 
> be a new one (perl-pdd)? 

I'm in favour of renaming to reflect the new use of the list.  Dan?

Nat

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[Edward Peschko]

On Mon, Feb 19, 2001 at 11:38:03PM -0500, Dan Sugalski wrote:
> At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> >RFC 362
> >---
> >
> >=head1 TITLE
> >
> >The RFC project should be ongoing and more adaptive.
> 
> It's my understanding that this is, in fact, the plan. The only reason 
> things have paused (and it is a pause, not a stop) is that we're waiting 
> for Larry to take what's been done so far and build something resembling a 
> coherent base we can implement. After that's done then we'll have something 
> to work from, which is a good thing.

Ok, fair enough. I think that perl should have a two-tiered process though, and
it should be ongoing and two tiered. 

Bryan Warnock mentioned PDD as being 'comprehensive', but I think that is a 
mistake. There should be a more formal process for distilling conversations, 
lest we repeat length(@array), '??', etc, ad-nauseum.  PDD should be stuff
that was decided as 'golden' and then implemented.

> If we don't ever stop, ponder, and implement, the RFCs will be just another 
> go-round of intellectual masturbation. (and we *really* don't need to go 
> there...) Yeah, it means the process will be bursty, but that's just the 
> nature of the beast.

Fair enough too, except that my time *too* is bursty, and that the time I can
give may or may not correspond with community time. I'll write them down, and 
post them to perl6-rfc (or perl6-meta). 

And if they miss the 'original' pass, that's fine with me.

Ed

Re: State of PDD 0

[Adam Turoff]

On Tue, Feb 20, 2001 at 05:42:01PM -0500, Dan Sugalski wrote:
> At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote:
> >How should the submission process work? As for the RFC's?
> 
> Sounds good to me.

Any additional constraints on acceptance criteria?  PDD 0 describes
an acceptable baseline on rejection (return incomplete submissions),
but I daresay that we want something more strict.  

For example, I doubt that we want or need three competing PDDs on
Async I/O developing in the Standard track, but multiple PDDs on
the same topic would be welcome if they were Experimental (or even
Informational).

Would any other constraints help to promote discussion moving forward?
The goal isn't to be burdensome on people actually volunteering their
time, but to cut down on the crosstalk that doesn't lead to Real Work(tm).

Z.

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[Dan Sugalski]

At 01:36 PM 2/20/2001 -0800, Edward Peschko wrote:
>On Mon, Feb 19, 2001 at 11:38:03PM -0500, Dan Sugalski wrote:
> > At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> > >RFC 362
> > >---
> > >
> > >=head1 TITLE
> > >
> > >The RFC project should be ongoing and more adaptive.
> >
> > It's my understanding that this is, in fact, the plan. The only reason
> > things have paused (and it is a pause, not a stop) is that we're waiting
> > for Larry to take what's been done so far and build something resembling a
> > coherent base we can implement. After that's done then we'll have 
> something
> > to work from, which is a good thing.
>
>Ok, fair enough. I think that perl should have a two-tiered process 
>though, and
>it should be ongoing and two tiered.
>
>Bryan Warnock mentioned PDD as being 'comprehensive', but I think that is a
>mistake. There should be a more formal process for distilling conversations,
>lest we repeat length(@array), '??', etc, ad-nauseum.  PDD should be stuff
>that was decided as 'golden' and then implemented.

Honestly, the PDDs are for the stuff that was implemented, not the stuff 
that was decided. Or, more clearly, PDDs describe the implementation or 
proposed implementation at the internals level. RFCs are for language-level 
features.

We should have PDDs on garbage collection and memory allocation (I know, I 
know--I'm working on it! :). We should not have PDDs on, say, currying.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: State of PDD 0

[Bryan C . Warnock]

We lost two of three *and* I missed actual discussion.  It must not be my 
night.  :-)

On Tuesday 20 February 2001 20:32, Adam Turoff wrote:
> On Tue, Feb 20, 2001 at 05:42:01PM -0500, Dan Sugalski wrote:
> > At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote:
> > >How should the submission process work? As for the RFC's?
> > 
> > Sounds good to me.
> 
> Any additional constraints on acceptance criteria?  PDD 0 describes
> an acceptable baseline on rejection (return incomplete submissions),
> but I daresay that we want something more strict.  

I'm working on some automation for the actual format to help with this.

> 
> For example, I doubt that we want or need three competing PDDs on
> Async I/O developing in the Standard track, but multiple PDDs on
> the same topic would be welcome if they were Experimental (or even
> Informational).

The idea, unlike the RFC process, wasn't that PDDs were to lead the 
discussion.  A PDD proposal was more or less a checkpoint in the 
development process.

In this case, a thread runs on and on about I/O - sync versus async, roll 
our own versus libc, etc.  Everyone has their say, until a Deciding Factor 
says - "We're going to roll our own async.  Can someone write up a proposal 
PDD?"

Now, any yahoo can write up a PDD for, say, libc stdio, and submit it.  The 
librarian (is he knows what is going on) can either reject it outright, or 
forward it to the lists.  (I think Proposals should be kept internal.)

The PDD Proposal should cover (and this is what I meant by comprehensive) 
the previously exhausted arguments of why we're doing our own async i/o 
versus other alternatives.  (And the title should be "The I/O subsystem" or 
something similar, not "async i/o")

If the Proposal is in the ballpark of why it was supposed to have been 
written in the first place, the chair can move it to Developing, where it 
gets fleshed out until it's a complete picture of what the subsystem should 
(or will) be.

It *should* be comprehensive in scope, and applicable content.  It should 
give folks an idea of what was discussed, and why we came to the conclusion 
that we did.   (For instance, I didn't itemize every support position for 
XML as the PDD format in PDD 0, but I did mention that there are a number 
of proponents, that we had a discussion about it, but we are sticking with 
POD for these reasons.)

> 
> Would any other constraints help to promote discussion moving forward?
> The goal isn't to be burdensome on people actually volunteering their
> time, but to cut down on the crosstalk that doesn't lead to Real Work(tm).

The problem with the RFC expectation, much like the sublists, is that the 
bulk of the discussion is done and over with long before someone takes 
action.  It's natural.  It's going to happen.  The mailing lists exists for 
a reason.  Let's discuss amongst ourselves before we speak with one voice.
The PDD should be that one voice - all the arguments should be done and 
over with.

PDDs should be born with builtin maturity.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Bryan C . Warnock]

On Tuesday 20 February 2001 17:38, Ask Bjoern Hansen wrote:
> 
> I have created perl6-announce-pdd. Mail [EMAIL PROTECTED]
> for clues.
> 
> How should the submission process work? As for the RFC's?

Can you confirm the actual submission address?  Are we using perl-pdd? And 
did we want to make this Perl 6 specific, or Perl generic (like perl-qa is)?


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Simon Cozens]

On Tue, Feb 20, 2001 at 08:32:07PM -0500, Adam Turoff wrote:
> > >How should the submission process work? As for the RFC's?
> > Sounds good to me.
> Any additional constraints on acceptance criteria? 

There is an *expectation* that people will not file PPDs as PPDs unless
they have been agreed upon or authorised. Community pressure can be
brought to bear on those calling things PPDs when they aren't. :)

-- 
It's a short step from using alt.binaries.warez.protocol-droids.c3p0 to
Palpatine seeing a post along the lines of: "CA|\| NE1 0N Th]5 BB0ARD T3Ll M3
H0w 2 GeT KeWL S]Th P0WeRZ!?!?!?!??!?"  The rest is, well, a couple
more overly-hyped ILM graphics demos.  -- [EMAIL PROTECTED] in ASR

Re: State of PDD 0

[Dan Sugalski]

At 04:01 PM 2/20/2001 -0700, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I've been thinking since I sent my last mail on this that we might 
> actually
> > want to leave the two (PDD & RFC) separate. Keep on with the RFCs for
> > 'external' things, and PDD for the actual internals implementation of 
> things.
>
>Ultimately, I think we're going to need at least three different
>types of documentation:
>
>  * internals design documents (PDDs)
>  * language design documents (PLDs?)
>  * change requests, once we've got something to change (PCRs)

That works. I rather like it, and I expect once we get a working perl 6, we 
probably won't need to freeze things either--worst case we mark a proposed 
document irrelevant or something of the sort.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[Bryan C . Warnock]

On Tuesday 20 February 2001 16:51, Dan Sugalski wrote:
> Honestly, the PDDs are for the stuff that was implemented, not the stuff 
> that was decided. Or, more clearly, PDDs describe the implementation or 
> proposed implementation at the internals level. RFCs are for 
language-level 
> features.

It should sort of do both.  Okay, maybe arbitrary language decisions 
needn't be P?Dd, but there should be some documented consensus, even for a 
language feature, of what is (or will be), if only to give the developers a 
clear target to shoot for.

> 
> We should have PDDs on garbage collection and memory allocation (I know, 
I 
> know--I'm working on it! :). We should not have PDDs on, say, currying.

Well, a well-designed spec on currying language would certainly help with 
development of the internals to handle currying.  It would also provide a 
nice starting point for the currying documentation. 

Lest the architect say, "Build me a house", and then complain that we don't 
match the plans he never gave us.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[Bryan C . Warnock]

On Tuesday 20 February 2001 16:36, Edward Peschko wrote:
> Ok, fair enough. I think that perl should have a two-tiered process 
though, and
> it should be ongoing and two tiered. 

I may be slow, but I make mistakes.
Yes, I've changed my mind.  I now think this is a good idea.

> 
> Bryan Warnock mentioned PDD as being 'comprehensive', but I think that is 
a 
> mistake. There should be a more formal process for distilling 
conversations, 
> lest we repeat length(@array), '??', etc, ad-nauseum.  PDD should be stuff
> that was decided as 'golden' and then implemented.

Except that's not quite what I meant by comprehensive.  
When it comes to what you are doing and why, it should certainly cover 
every base.  When it comes to the "why nots", there should at least be 
sufficient coverage to answer the question.

As I replied earlier (to a later thread), PDDs weren't meant to be 
discussion starters - they were meant to be discussion enders.  We've 
talked about it, and here's what we've decided to do.  There will be much 
discussion before that.   That discussion is exactly the first tier of the 
two-tier system that you're talking about.  I wasn't going to be so formal 
as to require an RFC, but then again, there's no reason to prohibit them, 
either.  An RFC is a good way to present an argument, vice the incoherent 
babble that people like me put out, as well as a good transition to a PDD 
Proposal.


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Bryan C . Warnock]

On Tuesday 20 February 2001 18:17, Dan Sugalski wrote:
> >Ultimately, I think we're going to need at least three different
> >types of documentation:
> >
> >  * internals design documents (PDDs)
> >  * language design documents (PLDs?)
> >  * change requests, once we've got something to change (PCRs)
> 
> That works. I rather like it, and I expect once we get a working perl 6, 
we 
> probably won't need to freeze things either--worst case we mark a 
proposed 
> document irrelevant or something of the sort.

Well, there's also Meta stuff for discussion that we should probably 
document as well.  As much as I disliked RFC, I also disliked PDD, as it 
'sounds' internal.  But do we create a new category for every new area we 
attempt to document, or do we change the name to reflect something more 
generic?  (The PDD has a Class field to distinguish between internals, 
meta, and language already.)

If we go with mulitple documents, is the numbering scheme concurrent?

I'm also thinking heavily about change requests, and whether they should be 
separate, or a stage beyond Standard.  Pros and cons welcome.


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Edward Peschko]

On Tue, Feb 20, 2001 at 06:17:18PM -0500, Dan Sugalski wrote:
> At 04:01 PM 2/20/2001 -0700, Nathan Torkington wrote:
> >Dan Sugalski writes:
> > > I've been thinking since I sent my last mail on this that we might 
> > actually
> > > want to leave the two (PDD & RFC) separate. Keep on with the RFCs for
> > > 'external' things, and PDD for the actual internals implementation of 
> > things.
> >
> >Ultimately, I think we're going to need at least three different
> >types of documentation:
> >
> >  * internals design documents (PDDs)
> >  * language design documents (PLDs?)
> >  * change requests, once we've got something to change (PCRs)
> 
> That works. I rather like it, and I expect once we get a working perl 6, we 
> probably won't need to freeze things either--worst case we mark a proposed 
> document irrelevant or something of the sort.

Well, how about calling 'Language Design Documents' "RFC's" ? After all, the
term RFC is a lot more generic; it can encorporate comments on *anything* perl
related.

Ed

Re: State of PDD 0

[Ask Bjoern Hansen]

On Tue, 20 Feb 2001, Dan Sugalski wrote:

> > > Ask, all, are we reusing perl6-rfc as the submittal address, or will there
> > > be a new one (perl-pdd)?
> >
> >I'm in favour of renaming to reflect the new use of the list.  Dan?
> 
> I've been thinking since I sent my last mail on this that we might actually 
> want to leave the two (PDD & RFC) separate. Keep on with the RFCs for 
> 'external' things, and PDD for the actual internals implementation of things.

I have created perl6-announce-pdd. Mail [EMAIL PROTECTED]
for clues.

How should the submission process work? As for the RFC's?


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: State of PDD 0

[Peter Scott]

At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote:
>At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote:
>>Bryan C. Warnock writes:
>> > Ask, all, are we reusing perl6-rfc as the submittal address, or will there
>> > be a new one (perl-pdd)?
>>
>>I'm in favour of renaming to reflect the new use of the list.  Dan?
>
>I've been thinking since I sent my last mail on this that we might 
>actually want to leave the two (PDD & RFC) separate. Keep on with the RFCs 
>for 'external' things,...

I suggest that we clearly delineate the RFCs which were pre-deadline from 
the ones that are post-deadline.  The advantage to having the original 
deadline was that it motivated many of us to get off our butts and fish or 
cut bait.  If we're going to continue this process now, I move that:

New RFCs be numbered starting from 1000 (easiest way to denote the difference);

Old RFCs are frozen, and that means frozen.  I have no idea how far Larry's 
got on digesting them and I really don't want to try and interfere with 
something that could be making its way down his small intestine.  People 
should be free to write new RFCs that contradict older ones, or head off on 
some tangent, but please let's not keep refining the old ones, enough is 
enough.


--
Peter Scott
Pacific Systems Design Technologies

Re: State of PDD 0

[Dan Sugalski]

At 02:38 PM 2/20/2001 -0800, Ask Bjoern Hansen wrote:
>On Tue, 20 Feb 2001, Dan Sugalski wrote:
>
> > > > Ask, all, are we reusing perl6-rfc as the submittal address, or 
> will there
> > > > be a new one (perl-pdd)?
> > >
> > >I'm in favour of renaming to reflect the new use of the list.  Dan?
> >
> > I've been thinking since I sent my last mail on this that we might 
> actually
> > want to leave the two (PDD & RFC) separate. Keep on with the RFCs for
> > 'external' things, and PDD for the actual internals implementation of 
> things.
>
>I have created perl6-announce-pdd. Mail [EMAIL PROTECTED]
>for clues.
>
>How should the submission process work? As for the RFC's?

Sounds good to me.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: State of PDD 0

[Jarkko Hietaniemi]

On Tue, Feb 20, 2001 at 02:43:14PM -0800, Peter Scott wrote:
> At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote:
> >At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote:
> >>Bryan C. Warnock writes:
> >> > Ask, all, are we reusing perl6-rfc as the submittal address, or will there
> >> > be a new one (perl-pdd)?
> >>
> >>I'm in favour of renaming to reflect the new use of the list.  Dan?
> >
> >I've been thinking since I sent my last mail on this that we might 
> >actually want to leave the two (PDD & RFC) separate. Keep on with the RFCs 
> >for 'external' things,...
> 
> I suggest that we clearly delineate the RFCs which were pre-deadline from 
> the ones that are post-deadline.  The advantage to having the original 
> deadline was that it motivated many of us to get off our butts and fish or 
> cut bait.  If we're going to continue this process now, I move that:
> 
> New RFCs be numbered starting from 1000 (easiest way to denote the difference);
> 
> Old RFCs are frozen, and that means frozen.  I have no idea how far Larry's 
> got on digesting them and I really don't want to try and interfere with 
> something that could be making its way down his small intestine.  People 
> should be free to write new RFCs that contradict older ones, or head off on 
> some tangent, but please let's not keep refining the old ones, enough is 
> enough.

Strongly agreed.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[Mike Lacey]

- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "Edward Peschko" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 20, 2001 9:51 PM
Subject: Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and
CPAN)


> > > ..we're waiting
> > > for Larry..

yep 

I am, basically, just *dying* to see perl6! Ho Hum...

Re: State of PDD 0

[Bryan C . Warnock]

On Tuesday 20 February 2001 17:30, Dan Sugalski wrote:
> At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote:
> >Bryan C. Warnock writes:
> > > Ask, all, are we reusing perl6-rfc as the submittal address, or will 
there
> > > be a new one (perl-pdd)?
> >
> >I'm in favour of renaming to reflect the new use of the list.  Dan?
> 
> I've been thinking since I sent my last mail on this that we might 
actually 
> want to leave the two (PDD & RFC) separate. Keep on with the RFCs for 
> 'external' things, and PDD for the actual internals implementation of 
things.

I'm not particularly fond of an internal/external delineation, but I'm not 
adverse to RFCs being generated as they were before - to initiate 
discussion.  If nothing else, it would make the transition to an actual PDD 
easier.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Adam Turoff]

On Tue, Feb 20, 2001 at 08:58:03PM -0500, Bryan C . Warnock wrote:
> On Tuesday 20 February 2001 20:32, Adam Turoff wrote:
> > For example, I doubt that we want or need three competing PDDs on
> > Async I/O developing in the Standard track, but multiple PDDs on
> > the same topic would be welcome if they were Experimental (or even
> > Informational).
> 
> The idea, unlike the RFC process, wasn't that PDDs were to lead the 
> discussion.  A PDD proposal was more or less a checkpoint in the 
> development process.

PDDs, like the RFCs that preceded them, will need to serve multiple
purposes.  One of them will be to catalog (and *name*) ideas that
keep coming up, including the bad ideas (like the |||= operator)
that we're tired of discussing.  I don't think anyone expects each
of N PDDs to get us 1/Nth closer to Perl6.

Some PDDs, especially Informational and possibly Experimental,
might need to precede knowledgeable discussion.  If so, then
Standards-track need to have the requirement that they summarize
some amount of discussion on the list(s), and that requirement is
enforcable (i.e., no PDDs out of left field).  

That's a good idea, but I'm not entirely convinced that it's the
only one, the fairest one or the most practical one.

Z.

Re: State of PDD 0

[Nathan Torkington]

Dan Sugalski writes:
> I've been thinking since I sent my last mail on this that we might actually 
> want to leave the two (PDD & RFC) separate. Keep on with the RFCs for 
> 'external' things, and PDD for the actual internals implementation of things.

Ultimately, I think we're going to need at least three different
types of documentation:

 * internals design documents (PDDs)
 * language design documents (PLDs?)
 * change requests, once we've got something to change (PCRs)

As you can see, I favour getting away from the RFC name.  I wish
I'd listened to people who warned me about the confusion the name
would choose.  This also means we don't have to renumber or start
counting from 1000 to differentiate the old RFCs from new ones.

Nat

Re: State of PDD 0

[Dan Sugalski]

At 04:43 PM 2/20/2001 -0600, Jarkko Hietaniemi wrote:
>On Tue, Feb 20, 2001 at 02:43:14PM -0800, Peter Scott wrote:
> > At 05:30 PM 2/20/01 -0500, Dan Sugalski wrote:
> > >At 02:15 PM 2/20/2001 -0700, Nathan Torkington wrote:
> > >>Bryan C. Warnock writes:
> > >> > Ask, all, are we reusing perl6-rfc as the submittal address, or 
> will there
> > >> > be a new one (perl-pdd)?
> > >>
> > >>I'm in favour of renaming to reflect the new use of the list.  Dan?
> > >
> > >I've been thinking since I sent my last mail on this that we might
> > >actually want to leave the two (PDD & RFC) separate. Keep on with the 
> RFCs
> > >for 'external' things,...
> >
> > I suggest that we clearly delineate the RFCs which were pre-deadline from
> > the ones that are post-deadline.  The advantage to having the original
> > deadline was that it motivated many of us to get off our butts and fish or
> > cut bait.  If we're going to continue this process now, I move that:
> >
> > New RFCs be numbered starting from 1000 (easiest way to denote the 
> difference);
> >
> > Old RFCs are frozen, and that means frozen.  I have no idea how far 
> Larry's
> > got on digesting them and I really don't want to try and interfere with
> > something that could be making its way down his small intestine.  People
> > should be free to write new RFCs that contradict older ones, or head 
> off on
> > some tangent, but please let's not keep refining the old ones, enough is
> > enough.
>
>Strongly agreed.

That works for me--we could increment the thousands number by one each time 
we open things up for a new RFC period. Once we have a working perl 6 of 
some sort we can kick in with RFC 1000, and once perl 6.1 is done we can go 
with 2000, and so on.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 362 - revisiting the RFC process (was Warnings, strict, and CPAN)

[David L. Nicol]

Yikes!

Altough it does not appear in the text of RFC 141, your idea to
keep all topics open indefintely, and Get Everything Done Right
No Matter How Long It Takes were certainly talked about in September.



> RFC 362
> ---
...
> The RFC process should not have had an artificial deadline; it should be an
> adaptive process that should last the entire development cycle of perl6 and
> perhaps after.

Should is a very dangerous word.

 
> Instead, I think that the doors to the RFCs should be re-opened, and that they
> should be bulletproofed. The next four RFCs suggest methods on how to improve
> the RFC process and the quality of RFCs:
> 
> RFC 363 - Anyone posting a new RFC should have read all of the existing
>   RFCs first.

Not just "relevant"?
 
> RFC 364 - There should be a web interface for people to interactively
>   comment on RFCs.
 
> RFC 365 - There should be a rating system for RFCs.
 
> RFC 366 - There should be a culling system for RFCs, a way to
>   distinguish quickly between withdrawn RFCs and RFCs in
>   process.

These are nice daydreams.  Please feel free to go ahead with these projects.
Do you need a cgi-enabled web server?  I can see what I can do towards providing
you one





-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
   Soon to take out a full page add looking for venture capitalists

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Bryan C . Warnock]

On Tuesday 20 February 2001 22:03, Edward Peschko wrote:

> > I *like* the interpretation of undef as 0 and "".  It's useful.  
Sometimes.
> > Sometimes it's not.  And that's fine.  
> 
> No that's NOT fine. It leads to 'find the needle in the haystack' sort of 
> problems. If you get 1450 'use of undef value' errors, they are all 
useless.
> 
> If you get 10 of them, and you know that the only time you are going to 
get
> 'use of undef value' errors, they are very valuable. And how valuable 
they 
> are grows as the size of your project increases.
> 
> > There's no reason in the world why that should replace undef -> 0 and 
"".
> 
> See above.
> 
> > > Or how about "I'm feeling particularly lazy today, I think I'll sleep 
in. 
> > Lets
> > > worry about any mistakes I might make another day."
> > 
> > Well, Laziness is One of the Three.
> 
> Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by 
> default, because warnings and strict are great teaching tools.
> 
> > Let me rephrase.
> > Perl shouldn't bitch at me for valid perl.
> 
> '-q'.

None of that is the point.
I don't disagree that having loads of warnings are a good thing.
I don't disagree that having strict parsing rules, variable declarations, 
and the ilk are a good thing.
There is no technical reason why warnings and strictness can't be the 
default.

You with me so far?  Everything you have said is perfectly valid, and if we 
were designing a brand-spanking new language, I might be arguing *for* you.
But we're not, we're tweaking Perl.  Perl, remember that language?  The 
language that advertised all the above laziness?  That the above laziness 
was part of its drawing power?

This isn't an addition to the language that you're talking about - it's 
changing some of the fundamental behavior of the language.  It's saying 
that no longer is Perl a loose, powerful language - oh, you want B&D? well, 
we can do that for you too - but rather that Perl is just another 
conventional programming language, (although if you flip this switch, 
you'll get its old, horrible behavior.) 

Sure, it will be easier to learn - it had better be, because 
*e-v-e-r-y-o-n-e* is going to have to learn it.  Again.

Look, most folks are probably sick of us going round and around about this, 
so I'll sum up my position.

1. There is no technical reason why warnings and strict can't be on by 
default, why undef must be able to promote to 0 or "", or just about any 
other feature a computer language can have.  No technical reason.  It may 
break some things, but those things can be fixed in their own right.

2. There are many non-technical reasons not to change codified behavior.  
This is why the last serious revamp of English spelling and grammar rules 
were aborted by the publication of the dictionary, why Americans adamantly 
refuse any doings with the metric system (except the 2 liter bottle), and 
why sports fans hate the instant replay.  To change what some consider the 
philosophical essence of Perl is akin to a bait-and-switch, and I, for one, 
would feel cheated, (and if you'll allow me to wax melodramatic, betrayed).

3. While the argument is internal to us, I will remain steadfast in my 
stance against any arbitrary, widespread reversal of the language.

4. Should the Perl cabal deem that, for Perl to improve, it *must* undergo 
these radical changes, I will, to the best of my meager abilities, attempt 
to implement them.

My position may seem a bit extreme - after all, didn't I, in the second 
RFC, attempt to autoprint statements in a void context?  I started in the 
middle of the road, but as arguments like this have continued, I've moved 
wy to the minimalist's side.  Hey, overhaul Perl to your heart's 
content so that you're able to do x, y, and z; just so long as Perl itself 
doesn't do x, y, and z.
 
-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: State of PDD 0

[Ask Bjoern Hansen]

On Tue, 20 Feb 2001, Bryan C. Warnock wrote:

> On Tuesday 20 February 2001 17:38, Ask Bjoern Hansen wrote:
> > 
> > I have created perl6-announce-pdd. Mail [EMAIL PROTECTED]
> > for clues.
> > 
> > How should the submission process work? As for the RFC's?
> 
> Can you confirm the actual submission address?  Are we using perl-pdd? And 
> did we want to make this Perl 6 specific, or Perl generic (like perl-qa is)?

Notify [EMAIL PROTECTED] after sending the (unnumbered) PDD to
perl6-internals and I will add it to the list.

Will be changed when the PDD traffic gets higher.


  - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Edward Peschko]

On Tue, Feb 20, 2001 at 08:33:50PM -0500, Bryan C. Warnock wrote:
> On Tuesday 20 February 2001 19:34, Edward Peschko wrote:
> 
> > Well, for one, your example is ill-considered. You are going to get 
> > autovivification saying:
> 
> The two ideas were disjoint.  The example wasn't an example of autoviv.

well, I was thinking you were saying @foo[$bar] = 100;

> > Hence I'd say that @foo[$bar] has NO INTRINSIC VALUE whatsoever.
> 
> Correct, which is why I could care less if Perl warns me about it.

right, but which is the higher cost? 10 experienced people being inconvenienced
because they see a message they can easily avoid, or 1 people learning the
language not getting the benefits that they would otherwise get by seeing it.

If perl is squawking to you about something, it usually is because you've got
a misconception of some kind. In this case, the misconception is that something
like:

if (@tmp[1,4] == @tmp[2,5])
{
}

will work.

> > Second, with the keyword empty (if it comes to pass) the reasons for 
> > interpretation of undef as 0 and "" go away. Right now, things are a PITA 
> > to get empty values:
> > 
> > my ($a, $b, $c, $d, $e) = ('') x 5;
> 
> I *like* the interpretation of undef as 0 and "".  It's useful.  Sometimes.
> Sometimes it's not.  And that's fine.  

No that's NOT fine. It leads to 'find the needle in the haystack' sort of 
problems. If you get 1450 'use of undef value' errors, they are all useless.

If you get 10 of them, and you know that the only time you are going to get
'use of undef value' errors, they are very valuable. And how valuable they 
are grows as the size of your project increases.

> There's no reason in the world why that should replace undef -> 0 and "".

See above.

> > Or how about "I'm feeling particularly lazy today, I think I'll sleep in. 
> Lets
> > worry about any mistakes I might make another day."
> 
> Well, Laziness is One of the Three.

Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by 
default, because warnings and strict are great teaching tools.

> Let me rephrase.
> Perl shouldn't bitch at me for valid perl.

'-q'.

Ed

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

[Edward Peschko]

> This isn't an addition to the language that you're talking about - it's 
> changing some of the fundamental behavior of the language.  It's saying 
> that no longer is Perl a loose, powerful language - oh, you want B&D? well, 
> we can do that for you too - but rather that Perl is just another 
> conventional programming language, (although if you flip this switch, 
> you'll get its old, horrible behavior.) 

I never said it was its 'old horrible' behaviour. We've got to stop thinking
about this as a religious issue. I have no qualms with people using something
like '-q', hell, I'll use it myself. The only thing is that it has a 
*huge cost*, this laxness by default. And the cost is not only technical:

1) diminished reputation.
2) misconceptions on news groups, mailing lists
3) wasted time, frustrations from users saying perl is 'quirky'
4) poorer quality of 3rd party modules, persistent bugs in them.
5) -w as pariah, ignored warnings.

In order to get the big, big, win. warnings have to be on by default, and they
have to be intuitive and easy enough to use by being on by default. 

If that means we clean up both warnings (getting rid of some of the sillier 
ones) and the method of using warnings up unto the point that they are flexible
enough *to* be included by default, well that's the price we will have to 
pay in order for it to work.

If it means that we turn on warnings && strict on by default and give it a 
'trial run' to get the perl community's feedback, get their positive feedback
and iterate that means we do that. Unlike most other changes that we decide
on, this one is *undoable*. If it doesn't work, and there is a big rebellion,
well, it doesn't work and there is a big rebellion. We say it was a noble 
experiment and move on. But if it *does* work, then great. 

There's no reason to feel betrayed - its a simple experiment: I think that this
is doable, and will help a lot. You think its not doable for cultural reasons.
Good - then let the culture decide. But don't sell it short until you've seen
it done. The least we get out of it is a cleaner, better warnings model and 
a 

Its all a matter of attitude, of selling people that its a good idea by not
forcing it down their throats but by presenting them with something and asking
them to use it, and getting their *opinion* on it. 

As for innovation, I really don't know of any language that helps users by 
pointing out potential mistakes...

And that's the last *I'm* going to say on the subject. I'm better off writing
RFC's...

Ed