> J. David Blackstone wrote:
>> That's one nice thing about Perl; you can foreach over
>> an array of all sorts of different things. In fact, being able to
>> just have an array of all sorts of different things is something Perl
>> still has over Java, C, and t
>o The architecture-interrogation primitives are inadequate; there is no
> robust way to ask ``am I running on Windows'' or ``am I running on
> Unix.''
>
> **We have $^O, but it requires parsing every time**
And $^O =~ /win/i broke recently when Apple introduced Darwin.
(R
> Nathan Torkington wrote:
>
>> I'd rather not revisit this, or any other, RFC until Larry's had a
>> chance to *really* comment and put forward his suggestions.
>
> I think pitching renames for "local" is at least as worthwhile as
> pitching code names. How about "Hold?" It isn't listed in Bla
> On Wed, Oct 18, 2000 at 10:32:32AM -0700, Larry Wall wrote:
>> Rename the local operator? Yeah, I think we ought to do that. It
>> confuses people when we call it local(). The problem is, of course,
>> that this is not a perfect solution--they haven't come up with the
>> right name here: save
> On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote:
>> "General consensus" is best, but that can't be guaranteed. "Consensus of
>> the ruling council" is more attainable, but there's that whole "ruling
>> council" thing to contend with. "What Larry says" is best, but what
> happens
>>
David Grove wrote:
> The
> community need that I _know_ is being ignored is the ability to have a perl
> that's not taking a dive toward being slopped all over with the four-colored
> flag.
David, please, you must be more specific and less idiomatic. I
don't even know what the four-colored fl
>
>
> 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?
>
> I don't know that this is _better_, but...perhaps we could have
> the l
> Something's gotta budge. I do not want to pay for the privilege of using a
> free
> language, and the "elite" need a damn good spaking to learn some manners to
> newbies (for at least the sake of advocacy) and people who don't use their
> own
> OS/Computer/Platform.
Being a Perl community new
I think the success criteria on http://dev.perl.org/pm/pos.html
should be more measurable.
> SUCCESS CRITERIA
> 1.Benchmarks of text processing programs show improved performance on
perl6 over perl5.
Yes, but how much improved? Is 50% in everyone's minds, or is 10%
enough? How much i
> I believe in having small control teams (2-3 people) assigned to
> each issue; these teams act as moderators for whatever they are
> implementing. These teams consist entirely of proven people. Give
> the control teams whatever they need to function: read-only + public
> mailing lists, etc.
Nat "Is pm for Project Management or Perl Module" Torkington wrote:
> You're right that it's very unclear how RFCs will be accepted or
> rejected. It's become obvious from the variety of RFCs proposed that
> Perl cannot be designed by committee. That's why there's one person
> designated as the
> On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote:
>> Wait. Does a good idea have to go away simply because the person
>> who originally proposed it no longer has interest? What if several
>> people are interested, but the original author has tota
Adam Turoff wrote:
> All of the RFCs have mailing lists associated with them, and all of
> the mailing lists have chairpeople leading discussion.
>
> Why not ask these chairpeople to start a Last Call process, whereby
> any unmaintained RFCs can be marked as "unmaintained and withdrawn"
> by the r
On Wed., Aug 16, 2000, Nate Wiger wrote:
> is good. Right now, people are hopping in 500 emails behind, replying to
> something in the middle of the stream, and only later reading the
> "please move this to -errors" post.
Actually, I'm 1283 emails behind, to be exact.
And that's just countin
On the main perl6-language list, Larry Wall wrote:
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Oooh. Someone proposed this as a reason why we can't get rid of
dynamic variables, and I've spent all evening being troubled by it.
If that "c
Larry Wall wrote:
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Is anyone thinking of this? This comes at a good time when I've
been looking for just such an idea to shore up one of my proposals on
perl6-language-strict.
J. David
My last message mentioned planned changes to RFCs. Lest anyone
should worry that I'm going to spring major surprises as this group's
time comes to an end, I'd like to mention that every change reflects
things that have been discussed here. Probably the only thing that
might surprise some peop
This message is intended to remind us all that the deadline for this
working group is _tomorrow_. I feel we've hashed out most of the
details of the various proposals and that any other issues will be
minor or can be settled closer to implementation time.
I realize I've spewed a whole lot o
Nate the prolific Perl6 RFC producer and commentator wrote:
> I don't think suggesting that we eliminate globals altogether is a good
> or feasible idea. It's an unnecessary crutch. They are useful in many
> circumstances.
So here's my order of preference:
1) Eliminate dynamic variables entire
I've been wanting to respond to these issues for the past two days,
but I've stopped short while I tried to consider everything.
This email dealt with making lexical variables default to being
available at the outermost scope (file). I'm not sure that's what
people usually mean when they th
I was just sitting here thinking over all these issues and making
various responses (as well as adjustments to my mental model for RFC
106 v2).
With the radical proposal of eliminating dynamic variables that RFC
106 includes (as an option! Don't get excited; read the RFC first!),
I've demon
> [EMAIL PROTECTED] (Nathan Wiger) wrote on 14.08.00 in
> <[EMAIL PROTECTED]>:
>
>> Well, lexical variables don't belong to any package in Perl. They're not
>> in the symbol table, hence why others can't mess with them. That's why a
>> "my $var" is different from a "$pkg::var". The latter gets i
> Perl6 RFC Librarian writes:
>> The chief instance where Perl5 requires dynamic variables is in the
>> case of package globals.
>
> I think this is a bad idea (so I'm glad you made it optional).
Thanks for the feedback, Nat.
I figured the idea would meet with resistance. Really, since the
>> Furthermore, in the "more rope" department, it might be possible to make
>> local() work on my() variables this way.
>
> I'm still unsure if this is a good thing. I think it is, but it's worth
> some pondering.
>
> -Nate
>
In the programming languages class I took last year, we wrote an
inte
>> Is Perl currently using different epochs on different platforms? If so, I
>
> Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
> just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
> VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
> rea
> On 14 Aug 2000, Russ Allbery wrote:
>
>> Day resolution is insufficient for most purposes in all the Perl scripts
>> I've worked on. I practically never need sub-second precision; I almost
>> always need precision better than one day.
>>
>
> MJD allows fractional days (otherwise it would of co
26 matches
Mail list logo
