My apologies if the following has already been suggested.
I know Larry said the colon was his, but presumably he's
not talking about the double colon, as currently used as a
package name separator, right?
What if:
use Foo::Bar qw/ qux waldo /;
can be written:
use Foo::Bar :: qux waldo
Just a quick obeservation:
Given the radicalness of the changes suggested by apo 2, I think it's
fair to say that the proportion of Perl 5 code that will run unchanged
on a Perl 6 interpreter will be heading into single-figure percentages.
While I personally think this will be price well worth pa
Dave Mitchell wrote:
>
> All entities should be prefixed with the name of the subsystem they appear
> in, eg C, C. They should be further prefixed
> with the word 'perl' if they have external visibility or linkage,
>
Duh! Missed it. Thanks.
Alan Burlison
Dave Mitchell wrote:
> My main objection to dSP et al is that it represents the innermost circle
> of the hell that is Perl 5 macros. Stuff like this is totally bemusing to
> the newcomer:
>
> dPOPPOPnnrl;
> if (right == 0.0)
>
> I was just trying think of ways of altering peop
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>I strongly agree. The current macro mayhem in perl is an utter abomination,
>and drastically reduces the maintainability of the code. I think the
>performance argument is largely specious, and while abstraction is a
>laudable aim, in the case of perl
Since we all seem to be agreed that macros that Do Strange Things are evil,
but are a necessary evil in certain extensibility situations,
and since Larry choked on my choice of naming scheme for macros
which declare variables for you, here's a slighly more modest proposal:
=item *
A macro that m
John Porter wrote:
>
> Larry Wall wrote:
> >
> > : do you think conflating @ and % would be a perl6 design win?
> >
> > Nope, I still think most ordinary people want different operators for
> > strings than for numbers.
>
> Different operators, conflated data type.
>
> That's what we have for s
At 11:11 PM 5/10/01 +0100, Simon Cozens wrote:
>On Thu, May 10, 2001 at 04:41:09PM -0400, David Grove wrote:
> > > Anywhere else? :)
> > FreeBSD comes to mind, among others.
>
>Hm. You initially restricted your survey to commercial vendors, but now
>you are moving the goalposts.
>
> > Can we get b
On Thu, May 10, 2001 at 10:00:13PM +0100, Michael G Schwern wrote:
> On Thu, May 10, 2001 at 01:49:30PM -0700, Edward Peschko wrote:
> > We need to keep syntactic compatibility, which means we need to keep the
> > ability for perl6 to USE PERL5.
>
> I think you're in violent agreement here. Thi
- Original Message -
From: "David Grove" <[EMAIL PROTECTED]>
To: "Peter Scott" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, May 10, 2001 5:47 PM
Subject: RE: Perl, the new generation
.
.
.
> Corporate users do not think in terms of neat and novel, they think in
terms
> of how
On Thu, May 10, 2001 at 03:58:41PM -0400, David Grove wrote:
> it's been 13 months since 5.6 was released,
> and two commercial entities have so far accepted it: ActiveState and SuSE.
This is what seasoned David-Grove-watchers call "a complete, barefaced lie".
Who do you get your Perl from?
Red
David Grove <[EMAIL PROTECTED]> writes:
> Unless Perl 6 is capable of parsing and running that 99.9% (or higher)
> of Perl 5 scripts originally foretold, I foresee a far worse outcome for
> Perl 6 than has happened for an almost universally rejected 5.6 and
> 5.6.1.
Most people don't adopt .0 re
On Thu, May 10, 2001 at 09:06:47PM +0100, Mike Lacey wrote:
> The idea of changing all of my Perl scripts is *not* attractive,
> actually it's sort of scary.
Before this FUD gets any further, let me repeat. It will NOT be
necessary to immediately change over all your Perl scripts!
/usr/bin/perl
> 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.
>
> : (Granted, that's not what I'd prefer, but the changes are getting
> : rather massive and ar
> On Thu, May 10, 2001 at 03:58:41PM -0400, David Grove wrote:
> > it's been 13 months since 5.6 was released,
> > and two commercial entities have so far accepted it:
> ActiveState and SuSE.
>
> "a complete, barefaced lie".
To be a lie, it must be purposeful. I am not above error, however.
> Wh
On Thu, May 10, 2001 at 04:41:09PM -0400, David Grove wrote:
> My information on this comes from discussion (asking directly) in undernet
> #linux. If this is in error, tell it to them.
An IRC channel, in ERROR?! On Undernet no less?! THE DEUCE YOU SAY!! ;)
Next thing you're going to tell me t
Michael G Schwern writes:
: On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
: > If you talk that way, people are going to start believing it. The
: > typical Perl 6 program is not going to look very different from the
: > typical Perl 5 program. The danger of us continually talking a
> -Original Message-
> From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 3:07 PM
> To: Larry Wall
> Cc: [EMAIL PROTECTED]
> Subject: Re: Perl, the new generation
>
>
> On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
> > If you talk that way, peop
* 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.
>
> : (Granted, that's not what I'd prefe
> Perl 5 is far from stagnant--please don't bend the truth to fit your
> points. My impression is that there's quite a bit more constructive
> activity on p5p than there was a year ago.
I've stopped paying attention to P5P except for keeping an eye on the
possibility of a new surprise upgrade fr
* 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
On Thu, May 10, 2001 at 09:20:13AM -0700, Peter Scott wrote:
> So, I wonder aloud, do we want to signify that degree of change with a more
> dramatic change in the name? Still Perl, but maybe Perl 7, Perl 10, Perl
> 2001, Perl NG, Perl* - heck, I don't know, I'm just trying to get the
> creati
Peter Scott writes:
: So, I wonder aloud, do we want to signify that degree of change with a more
: dramatic change in the name?
I'm inclined to think that people will be more likely to migrate if
they subconsciously think we're taking continuity into consideration.
Which we are, albeit not at a
This is a long shot, but here goes.
I was thinking about Perl 6 this morning while jogging (blithely ignoring
the forest scenery). It occurred to me that what appears to be emerging as
the new language embodies bigger changes than I ever anticipated - which is
great, software should improve w
On Thu, May 10, 2001 at 09:20:13AM -0700, Peter Scott wrote:
> So, I wonder aloud, do we want to signify that degree of change with a more
> dramatic change in the name? Still Perl, but maybe Perl 7, Perl 10, Perl
> 2001, Perl NG, Perl* - heck, I don't know, I'm just trying to get the
> creati
Hey, we could call it Perl 9 from Outer Space. No wait...
Larry
On Thu, May 10, 2001 at 05:23:01PM +0100, Simon Cozens wrote:
> On Thu, May 10, 2001 at 09:20:13AM -0700, Peter Scott wrote:
> > So, I wonder aloud, do we want to signify that degree of change with a more
> > dramatic change in the name? Still Perl, but maybe Perl 7, Perl 10, Perl
> > 2001, Per
At 02:58 PM 5/10/2001 -0700, Nathan Wiger wrote:
>* 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
At 09:20 AM 5/10/01 -0700, I wrote:
>At some point, the Perl 6 cognomen will have attracted enough inertia that
>we couldn't reasonably change it even if we wanted to. Maybe that time
>has already come. Maybe not. Can't hurt to raise the question.
I retract the last sentence.
--
Peter Scot
On Thu, May 10, 2001 at 04:41:09PM -0400, David Grove wrote:
> > Anywhere else? :)
> FreeBSD comes to mind, among others.
Hm. You initially restricted your survey to commercial vendors, but now
you are moving the goalposts.
> Can we get back to the subject now?
Certainly. The subject was whethe
I'd just like to make this abundantly clear, since there seems to be
some confusion (and hopefully I'm not the one confused).
*** You will NOT have to rewrite your Perl 5 programs ***
Perl 6 *will* provide a backwards compatible Perl 5 parser. The
details are not nailed down, but this definat
At 10:06 PM 5/10/2001 +0100, Michael G Schwern wrote:
>I'd just like to make this abundantly clear, since there seems to be
>some confusion (and hopefully I'm not the one confused).
>
>*** You will NOT have to rewrite your Perl 5 programs ***
>
>Perl 6 *will* provide a backwards compatible Perl 5
> Damian's converted a program from the Cookbook to perl6 to show how
> the language might look. It's not vastly different from the perl5
> version. It certainly still looks like the same language.
Yep. BTW this is the first in a series of articles paralleling Larry's
Apocalypses. Ever
On Thu, 10 May 2001, Uri Guttman wrote:
> > "DS" == Dave Storrs <[EMAIL PROTECTED]> writes:
>
> DS> There have been multiple mentions of the fact that we intend to have safe
> DS> signals in Perl 6. I was wondering if it will also be possible to have
> DS> more than one alarm() set
Dave Storrs writes:
: < QUOTE LARRY >
: Dave Storrs writes:
: : You know, it would be really cool if you specify the number of
: : lines you wanted like so:
: :
: : <$STDIN # One line
: : *<$STDIN# All available lines
: : *4<$STDIN
> if we have a proper core event loop as dan and i want, multiple timers
> will be part of that. and that will mean we can have timed out
> operations without the mess of eval/die (or whatever 6 will have for
> that).
Event loop will be great for many applications. We probably need
a better way
> "HZ" == Hong Zhang <[EMAIL PROTECTED]> writes:
HZ> There is no need to store pending signals. It will be impossible
HZ> to achieve in a multi-threaded perl runtime.
HZ> The only safe signals in multi-threaded system is using to use
HZ> sigwaitinfo() for all process-wide signals. S
John Porter wrote:
> Larry Wall wrote:
> > We do have to worry about the C loop control function though.
> > It's possible that in
> >
> > FOO: while (1) {
> > next FOO if /foo/;
> > ...
> > }
> >
> > the C label is actually being recognized as a pseudo-package
> > name! The loop
There have been multiple mentions of the fact that we intend to have safe
signals in Perl 6. I was wondering if it will also be possible to have
more than one alarm() set at a time, or some other mechanism for having
multiple pending signals.
Dave
Uri Guttman wrote:
>
> multiple timers
This means something like there is this array of sets of events,
and a thread that shifts off the front one every second and
feeds everythin in it into the event queue. Right?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
how to pull the next four lines out of a file handle in
way new syntax,
Larry Wall wrote:
>
> Dave Storrs writes:
> : < QUOTE LARRY >
> : Dave Storrs writes:
> : @foo = $STDIN * 4;
> :
> : Larry
What's wrong with old-fashioned autoextending array slices that
now DWIM
splice @foo,
Edward Peschko writes:
: On Thu, May 10, 2001 at 09:43:34AM -0700, Larry Wall wrote:
: > Peter Scott writes:
: > : So, I wonder aloud, do we want to signify that degree of change with a more
: > : dramatic change in the name?
: >
: > I'm inclined to think that people will be more likely to migra
> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes:
DS> There have been multiple mentions of the fact that we intend to have safe
DS> signals in Perl 6. I was wondering if it will also be possible to have
DS> more than one alarm() set at a time, or some other mechanism for having
DS> m
< QUOTE LARRY >
Dave Storrs writes:
: You know, it would be really cool if you specify the number of
: lines you wanted like so:
:
: <$STDIN # One line
: *<$STDIN# All available lines
: *4<$STDIN # Next 4 lines
:
: Or even:
:
On Thu, May 10, 2001 at 02:58:50PM -0700, Nathan Wiger wrote:
> * 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 a
* 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
On Thu, May 10, 2001 at 03:19:16PM -0700, Peter Scott wrote:
> With respect - and I do mean that - the subject as I started it was, Is
> "Perl 6" the most appropriate title for what we discuss here and what brave
> people like yourself will be implementing?
Peter,
Yes.
Simon
--
All the goo
> or some such, unless the purpose of the local(*foo) could be determined
> by unscrupulous means. Similarly, glob aliases *foo = *bar would
> need special treatment.
By far most of my use of typeglobs is making aliases, and then mostly
for code:
*color = \&colour;
So naturally I hope
On Thu, May 10, 2001 at 07:40:04PM -0500, Jarkko Hietaniemi wrote:
> > or some such, unless the purpose of the local(*foo) could be determined
> > by unscrupulous means. Similarly, glob aliases *foo = *bar would
> > need special treatment.
>
> By far most of my use of typeglobs is making aliases
One of the great strengths of Perl is that, more than any other
language I know, it helps you cross between the "data" space and the
"program" space: eval(), built in regex notation, etc. Even with the
considerable expressive power already at our disposal, I would like to
suggest that there might
Dave Storrs wrote:
> *4<$STDIN # Next 4 lines
> *$num_lines<$STDIN # Numifies $num_lines, gets that many
> *int rand(6)<$STDIN # Gets 0-5 lines
> *&mySub($bar)<$STDIN# mySub returns num, gets that many
Shades of printf...
--
John Porter
At 08:40 AM 5/10/2001 -0700, Larry Wall wrote:
>Dave Mitchell writes:
>: Content-MD5: FiIz8m/ma8enU5CTBqhsQw==
>: X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
>: X-Spam-Rating: onion.valueclick.com 1.6.2 0/1000/N
>:
>:
>: > Briefly: We want the Perl 6 runtime to be an equival
Hillary writes:
: >I happen to like $ and @. They're not going away in standard Perl as
: >long as I have anything to do with it. Nevertheless, my vision for Perl
: >is that it enable people to do what *they* want, not what I want.
: >
: >Larry
:
: If only that were true...But it isn't true. It
On Fri, 4 May 2001 18:20:52 -0700 (PDT), Larry Wall wrote:
>: love. I'd expect $FOO.readln (or something less Pascalish) to do an
>: explicit readline to a variable other than $_
>
>It would be $FOO.next, but yes, that's the basic idea. It's possible
>that iterator variables should be more synta
Dave Storrs writes:
: You know, it would be really cool if you specify the number of
: lines you wanted like so:
:
: <$STDIN # One line
: *<$STDIN# All available lines
: *4<$STDIN # Next 4 lines
:
: Or even:
:
: *$num_l
Larry Wall wrote:
>
> : do you think conflating @ and % would be a perl6 design win?
>
> Nope, I still think most ordinary people want different operators for
> strings than for numbers.
Different operators, conflated data type.
That's what we have for scalars already.
Makes sense to have i
> -Original Message-
> From: John Porter [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 11:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: what I meant about hungarian notation
>
>
> Larry Wall wrote:
> >
> > : do you think conflating @ and % would be a perl6 design win?
> >
> > No
Dan Sugalski writes:
: At 08:40 AM 5/10/2001 -0700, Larry Wall wrote:
: >Dave Mitchell writes:
: >: Content-MD5: FiIz8m/ma8enU5CTBqhsQw==
: >: X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
: >: X-Spam-Rating: onion.valueclick.com 1.6.2 0/1000/N
: >:
: >:
: >: > Briefly: We wan
(apologies if this is a duplicate - I think my last post has gotten lost).
> The RFC pleads for a community spirit from ORA. Barring that, it seeks
> a new symbol for the community entirely
I'd suggest a mongoose - eats poisonous snakes for breakfast.
There's a sort of tie-in with Perl Mongers
/me likes. /me likes a lot.
David T. Grove
Blue Square Group
[EMAIL PROTECTED]
[EMAIL PROTECTED]
> -Original Message-
> From: Dave Hartnoll [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 8:56 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Apoc2 - concerns : new mascot?
>
>
>
On Thu, May 10, 2001 at 12:43:13PM -0500, David L. Nicol wrote:
> John Porter wrote:
> >
> > Larry Wall wrote:
> > >
> > > : do you think conflating @ and % would be a perl6 design win?
> > >
> > > Nope, I still think most ordinary people want different operators for
> > > strings than for number
Larry:
> Currently, @ and [] are a promise that you don't intend to use string
> indexing on this variable. The optimizer can make good use of this
> information. For non-tied arrays of compact intrinsic types, this
> is going to be a major performance win in Perl 6.
Assuming that optimization
On Thu, May 10, 2001 at 10:19:10AM +0100, Dave Mitchell wrote:
> to be such that the writing of the Perl 5 to 6 translator utility is
> still feasable.
If you're at TPC this year, you'll hear me how explain how translators
*far* weirder than simply Perl 5 to Perl 6 are possible. :)
Briefly: We w
> -Original Message-
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 8:01 AM
> To: Dave Mitchell
> Cc: [EMAIL PROTECTED]
> Subject: Re: The 5% solution
>
>
> On Thu, May 10, 2001 at 10:19:10AM +0100, Dave Mitchell wrote:
> > to be such that the writing of the
Larry:
> : > Currently, @ and [] are a promise that you don't intend to use
string
> : > indexing on this variable. The optimizer can make good use of
this
> : > information. For non-tied arrays of compact intrinsic types, this
> : > is going to be a major performance win in Perl 6.
Clearly the
> Briefly: We want the Perl 6 runtime to be an equivalent of the Microsoft
> CLR, so that if you can somehow get bytecode onto it - from whatever
> language - you can run it. So we've got some bytecode that perl can run.
> Now think about what B::Deparse does.
I knew the intention was to go the
Me writes:
: Larry:
: > Currently, @ and [] are a promise that you don't intend to use string
: > indexing on this variable. The optimizer can make good use of this
: > information. For non-tied arrays of compact intrinsic types, this
: > is going to be a major performance win in Perl 6.
:
: As
Larry Wall <[EMAIL PROTECTED]> writes:
> Me writes:
> : Larry:
> : > Currently, @ and [] are a promise that you don't intend to use string
> : > indexing on this variable. The optimizer can make good use of this
> : > information. For non-tied arrays of compact intrinsic types, this
> : > is go
> Nope, I still think most ordinary people want different operators for
> strings than for numbers. Dictionaries and calculators have very
> different interfaces in the real world, and it's false economy to
> overgeneralize. Witness the travails of people trying to use
> cell phones to type mess
On Tue, 8 May 2001, Larry Wall wrote:
> In this view, * and < could just be two different kinds of "expandable" flags.
> But I'm uncomfortable with that, because I'd like to be able to say
>
> lazy_sub(<$STDIN, <$STDIN, <$STDIN, <$STDIN)
>
> to feed four lines to lazy_sub without defeati
On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
> If you talk that way, people are going to start believing it.
[snip]
Some of us are are talking that way because we already
beleive it. You can't make the transition from Attic
Greek to Koine without changin
> The RFC pleads for a community spirit from ORA. Barring that, it seeks a
new
> symbol for the community entirely
I'd suggest a mongoose - eats poisonous snakes for breakfast.
There's a sort of tie-in with Perl Mongers == Perl Mongoose as well :-)
Dave.
On Thu, May 10, 2001 at 01:51:25PM -0500, Garrett Goebel wrote:
> > I'll say it again for the l^W^W^W - arrays and hashes are conceptually
> > very different beasts.
>
> strings, integers, longs, and floats are conceptually very different beasts.
No, not really. Integers, longs and floats are al
Dave Mitchell writes:
: Content-MD5: FiIz8m/ma8enU5CTBqhsQw==
: X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
: X-Spam-Rating: onion.valueclick.com 1.6.2 0/1000/N
:
:
: > Briefly: We want the Perl 6 runtime to be an equivalent of the Microsoft
: > CLR, so that if you can so
On Tue, 8 May 2001, Me wrote:
> yes?
>
> And, despite perl5's use of no as the opposite
> of use, and given that there may be no use in
> perl6 (;>), and thus perhaps no no, (on and off?),
> then maybe no could be used as not yes?
>
> no?
Your Honor, I would like to stipulate that t
Edward Peschko writes:
: Although I would amend what he said to saying 'perl6 will eat perl 5 code
: close to painlessly as possible including typeglobs'. Typeglobs are a central
: part of a lot of CPAN's core modules; I don't think we could get away with
: abolishing them willy-nilly.
Much of t
> On Thu, May 10, 2001 at 10:00:13PM +0100, Michael G Schwern wrote:
> > On Thu, May 10, 2001 at 01:49:30PM -0700, Edward Peschko wrote:
> > > We need to keep syntactic compatibility, which means we need
> to keep the
> > > ability for perl6 to USE PERL5.
> >
> > I think you're in violent agreemen
> If you talk that way, people are going to start believing it. The
> typical Perl 6 program is not going to look very different from the
> typical Perl 5 program. The danger of us continually talking about
> the things we want to change is that people will forget to notice the
> tremendous amou
On Thu, May 10, 2001 at 02:06:59PM -0500, Jarkko Hietaniemi wrote:
> Maybe, but for one I'm starting to wonder. TomC's rant rang true in
> my ears. How much can we change and still call it the same language?
> I'm not yet panicking, I'm just trying to hug some firm ground here.
The Apocalypses
David Grove writes:
: "A slow transition" may be a catchphrase nowadays, but with Perl 5 stagnant,
Perl 5 is far from stagnant--please don't bend the truth to fit your
points. My impression is that there's quite a bit more constructive
activity on p5p than there was a year ago.
: Unless Perl 6
Michael G Schwern writes:
> It might be useful to draw up a list of functions and features which
> we don't plan on changing? Maybe just run through each Perl 5 man
> page and highlight everything that will still be the same and post
> this somewhere?
Damian's converted a program from the Cookbo
I've been wondering for quite some time whether we were creating a Perl for
the purpose of cleaning up the ridiculously rigged Perl 5 internals, or
creating a Perl for the simple enjoyment of creating a new programming
language. Certainly, recent discussions would point to the latter; as we
move f
Michael G Schwern writes:
> 5.6.0 style was jarring enough (and fairly well justified). Its been
> so long since we've had an integer increment that it should be fairly
> shocking.
And we can always think of a scheme for codenames, and have that
scheme be the theme for perl6.
Hmm, if perl5 was
Incompatible continuity. Sounds like Microsoft marketing.
"We're strongly considering keeping compatibility, and rejecting it wherever
we can insert something that looks momentarily cool. Of course your Perl 5
programs will still work, as long as you convert them to Perl 6. We'll have
a parser th
Nathan Torkington writes:
> Here's a program I use to count messages in my mailfile:
My point being that perl6 is not a bizarre froofroo language bearing
no relationship to perl5, and that all the good stuff from perl5 will
be alive and kicking in perl6. I think a lot of the panic here is
ground
Here's a program I use to count messages in my mailfile:
#!/usr/bin/perl -w
while (<>) {
if (($who) = /^From\s+\S+\s+\S+\s+(\S+\s+\S+)/) {
@r = reverse split ' ', $who;
$r[0] = sprintf("%02d", $r[0]);
$count{"@r"}++;
}
}
foreach (sort keys %count) {
printf(
On Thu, May 10, 2001 at 12:47:34PM -0400, David Grove wrote:
> So, I'll go you one farther. What about creating a cleaned up perl, and
> letting those who want to play with a new language entirely do so in the
> form of a true fork.
If all you're concerned about is providing a cleaned up Perl 5 w
* 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
On Thu, May 10, 2001 at 12:56:36PM -0400, David Grove wrote:
> Of course your Perl 5 programs will still work, as long as you
> convert them to Perl 6. We'll have a parser that will be able to do
> this. Of course, you will have to write it yourself.
I think there's a communications foul-up here.
At 12:47 PM 5/10/01 -0400, David Grove wrote:
>Unless Perl 6 is capable of parsing and running that 99.9% (or higher) of
>Perl 5 scripts originally foretold, I foresee a far worse outcome for Perl 6
>than has happened for an almost universally rejected 5.6 and 5.6.1.
>
>Fun is fun. But work costs
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.
: (Granted, that's not what I'd prefer, but the changes are getting
: rather massive and are starting to
At 05:36 PM 5/10/01 +0100, Michael G Schwern wrote:
>Version numbers are, at best, an indication of the magnitude change.
>At worst they are a cheap marketing ploy. I've always liked that
>Perl's version numbers are relatively free of marketing hoopla (the
>jump from perl3 to perl4 notwithstandin
On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
> If you talk that way, people are going to start believing it. The
> typical Perl 6 program is not going to look very different from the
> typical Perl 5 program. The danger of us continually talking about
> the things we want to chang
I've just put this into a program:
warn "about to unlink @{[<$FRname*>]}";
unlink <$FRname*>;
(wow, the MUA is a lot less vivid than a colorful code editor --
does mutt or emacs color-code code in e-mails?)
Demonstrating, the p5 "cast" can be performed. I guess p6 will
optim
> On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
>
> > If you talk that way, people are going to start believing it.
> [snip]
>
> Some of us are are talking that way because we already
> beleive it. You can't make the transition from Attic
> Greek to Koine without c
> -Original Message-
> From: Adam Turoff [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 3:31 PM
> To: David Goehrig
> Cc: Larry Wall; [EMAIL PROTECTED]
> Subject: Re: Perl, the new generation
>
>
> On Thu, May 10, 2001 at 12:13:13PM -0700, David Goehrig wrote:
> > On Thu, May 10
On Thu, May 10, 2001 at 12:13:13PM -0700, David Goehrig wrote:
> Some of us are are talking that way because we already
> beleive it. You can't make the transition from Attic
> Greek to Koine without changing how people fundamentally
> view their language.
Oh, hyperbole
On Thu, May 10, 2001 at 08:22:17PM +0100, Simon Cozens wrote:
> Oh, hyperbole! It's more like going from Katharevousa to Demotic.
(To pre-empt Philip Newton: Yes, I know, but going the other way wouldn't
have sounded like an advancement.)
--
An algorithm must be seen to be believed.
On Thu, May 10, 2001 at 12:13:13PM -0700, David Goehrig wrote:
> On Thu, May 10, 2001 at 11:55:36AM -0700, Larry Wall wrote:
> > If you talk that way, people are going to start believing it.
> [snip]
>
> Some of us are are talking that way because we already
> beleive it. You can't
On (03 May 2001 10:23:15 +0300) you wrote:
> Michael Schwern:
> >
> > Would be neat if: my($first) = grep {...} @list; knew to stop itself, yes.
> >
> > It also reminds me of mjd's mention of: my($first) = sort {...} @list;
> > being O(n) if Perl were really Lazy.
>
> But it would need a
1 - 100 of 110 matches
Mail list logo
