* Nathan Torkington <[EMAIL PROTECTED]> [05/10/2001 17:31]:
>
> Here's the corresponding perl6 program:
>
> #!/usr/bin/perl -w
>
> while (<$ARGS>) {
^
Whoa! Is RFC 94 being considered?! I thought I retracted that. ;-)
> Notice the variable changes: %count{...} because I'm
* Adam Turoff <[EMAIL PROTECTED]> [05/10/2001 15:20]:
>
> Yes, it has, in Apocolypse 1:
>
> Perl 6 must assume it is being fed Perl 5 code until it knows otherwise.
>
> http://www.perl.com/pub/2001/04/02/wall.html
Yup, I saw that - actually, the discussion I was referencing was
post-A
* Dan Sugalski <[EMAIL PROTECTED]> [05/10/2001 14:18]:
> >
> >Perl 6 *will* provide a backwards compatible Perl 5 parser. The
> >details are not nailed down, but this definately will happen.
>
> Damn straight. One way or another, perl 6 will eat perl 5 code close to
> painlessly. (Typeglobs, pe
* Larry Wall <[EMAIL PROTECTED]> [05/10/2001 11:57]:
>
> Nathan Wiger writes:
> : Maybe the name "Perl" should be dropped altogether?
>
> No. The Schemers had to do a name change because the Lisp name had
> pretty much already been ruined by divergence.
&g
* Peter Scott <[EMAIL PROTECTED]> [05/10/2001 10:55]:
>
> Eh, I fully understand that version number magnitudes are simply to attract
> attention, and that The Faithful don't need the glitz. Since AFAICT the
> glitz doesn't hurt, though, it doesn't do any harm to give marketing all
> the help
[again, apologies if this is a duplicate]
* Michael G Schwern <[EMAIL PROTECTED]> [05/04/2001 15:51]:
>
> Oddly enough, varying the number of traffic lights can effect
> efficiency. By over-regulating you can choke off traffic. Constant
> fiddling with the setups and timings, trying to control
* Michael G Schwern <[EMAIL PROTECTED]> [05/04/2001 15:51]:
>
> Oddly enough, varying the number of traffic lights can effect
> efficiency. By over-regulating you can choke off traffic. Constant
> fiddling with the setups and timings, trying to control each and every
> intersection to maximize t
Kirrily Skud Robert wrote:
>
> Open Source Writers Group (http://oswg.org/) is a good starting point.
> I'm subscribed to their mailing list.
This is really cool. Should we consider posting an announcement to this
website for potential docs people? Or is it still premature to do
something like
Steve Fink wrote:
>
> David Grove wrote:
>
> > Also, as far as documentation goes, I think it _should_ be written by
> > apprentices, so that non-masters can understand it too.
>
> Except it's a particular duty that nobody really likes to perform.
One thing that might be really cool is if ther
Adam Turoff wrote:
>
> No worries. These BSD guys are onto something...
> http://www.daemonnews.org/200010/dadvocate.html
Thanks for the great link. This is a really interesting article. In
particular, I found these points about FreeBSD to be reminiscient of
concerns some have raised about
Nathan Torkington wrote:
>
> $als_keynote = Dumper($Larry->perl6_design);
package Sympathy;
sub create { print "We're behind you, $_!\n" }
package main;
create Sympathy because => RFCs for Larry;
Heh, it actually works, too. :-)
-Nate
P.S. Do we need a perl6-poetry? ;-)
Nathan Torkington wrote:
> The immediate question facing us is how to structure software design.
> This is different from the ongoing maintenance of Perl.
> The architecture will be partially decided by Larry, and seems best
> done by a few experienced with such things. Detailed design seems
>
Dan Sugalski wrote:
>
> Works. We still have those Quantum Ninja that we're holding in reserve for
> Damian... :)
Yeah... they're vicious, too - they kick ass in constant time. ;-)
-Nate
Dan Sugalski wrote:
>
> > > Just that it not be *too* hard to get on the closed lists
> >
> >Yep, this is my only concern. It should be reasonably easy to say "I
> >really want to help" and get on the closed lists. Perhaps the best way
> >of making sure the lists don't bloat into "everyone has a
Andy Dougherty wrote:
>
> On Mon, 9 Oct 2000, Nathan Torkington wrote:
>
> > Closed-for-posting mailing lists that are publically readable is the
> > best suggestion we've had to meet these ends so far.
> >
> > Anyone have better suggestions?
>
> Just that it not be *too* hard to get on the clo
John Porter wrote:
>
> RFCs like "330: Global dynamic variables should remain the
> default" should not need to be written! (No disrespect to you,
> Nate.)
None taken; I actually agree. Unfortunately, I thought that -strict did
nowhere near enough analysis of scoping issues besides the initial
s
Adam Turoff wrote:
>
> RFC Improvement #1: All updated RFCs must contain a CHANGES section.
>
> RFC Improvement #2: All updated RFCs must contain a synopsis of
> relevant discussion, including opposing views.
>
> RFC Improvement #3: All final RFCs must contain a discussi
Adam Turoff wrote:
>
> I'd like to take advantage of the 2-week RFC freeze to focus on the
> process we set up for the first two months of Perl6. That way, we can
> start talking about more procedural issues, like what happens when someone
> comes up with v1 of an RFC but abandons it for 7 weeks
Russ Allbery wrote:
>
> I've been feeling guilty about not doing much in the way of chair-like
> things with date-time, but I'm also not sure what exactly I'm supposed to
> be doing. Discussion has essentially died out completely, which means
> that I probably should be trying to kick-start it.
> > What we're doing about that:
> > * pushing the output through Larry
> > [Yes, this addresses only part of the problem. Any suggestions for
> > other ways to solve this?]
>
> The RFC mountain is way, way too high to be climbed by just one person,
> let alone the output of the various mailing
Larry Wall wrote:
>
> More generally, for all X, I wouldn't mind
> if Perl became the language of choice for X.
Who wouldn't!
But I think that would probably have to be, "if Perl became the language
of choice for X - 1".
Perl's gotta be written in something, after all... ;-)
-Nate
Of course,
Adam Turoff wrote:
>
> Look again.
>
> Next request? ;-)
Can you continue to rock? You're kickin' my ass as RFC Librarian. Nice
job.
-Nate :-)
Mark-Jason Dominus wrote:
>
> The IMPLEMENTATION section of the RFC is supposed to be mandatory, but
> there have been an awful lot of RFCs posted that have missing or
> evasive IMPLEMENTATION sections.
Well, I have to counter this with the following: Having a complete
IMPLEMENTATION section sho
Are we maintaining the RFC's in HTML anywhere? I don't see them.
If not, could we add an HTML link at the end of the RFC links:
RFC 0 (v4): Some title [ HTML ]
Sometimes reading HTML is easier on the eyes than plain text. Plus you
get all the cross-links and stuff. Just a suggestion.
-Nate
24 matches
Mail list logo
