> In this thread I've heard both "perl6 is too different from perl5" and
> "perl6 is too similar to perl5", without anybody naming the specific
> things that are problems and suggesting solutions.
The old adage about programmers being like cats, constantly at the
wrong side of the door, or at the
* Damian Conway <[EMAIL PROTECTED]> [05/11/2001 14:46]:
>
> Here's a translation table from my soon-to-be-released article, Exegesis 2:
>
> Access through... Perl 5 Perl 6
> = == ==
> Array slice @foo[$n]
Jarkko Hietaniemi writes:
> Yea, verily. I have more than once stared for more seconds than I
> care to admit being completely baffled at why my C compiler doesn't
> appreciate
>
> print "foo = $foo\n";
If I had a dollar for every time I've put $ on C variables, I'd have
enough to buy Wil
On Fri, May 11, 2001 at 05:02:39PM +, [EMAIL PROTECTED] wrote:
> Nathan Torkington <[EMAIL PROTECTED]> writes:
> >So now the changes are too SMALL, and we should have a language that
> > is completely different so that you won't be confused when you edit
> > different scripts?
>
> Speaking
> What about array and hash accesses starting with scalar-indicators?
> I guess it is easy to misread A2 to mean that not only will
>
>scalar(@trucks[5])
>
> return the sixth truck, but
>
>$trucks[5]
>
> will no longer work.
Just so everyone is clear: i
Larry Wall wrote:
>
> Why should it be deprecated?
>
> Oh, are you wondering because I said ...
What about array and hash accesses starting with scalar-indicators?
I guess it is easy to misread A2 to mean that not only will
scalar(@trucks[5])
return the sixth truck, but
$truc
On Fri, May 11, 2001 at 02:57:20PM -0400, James Mastros wrote:
> OTOH, we're already talking about having support for multiple languages
> (parsers) within one file, and having perl5 being another parser. Put them
> together, and you get exactly this.
Yeah, it'll probably be possible to wedge th
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Real Unix signals aren't going to get treated any differently from
DS> any other event, though, so I'm not sure there's much to be gained
DS> from treating them all that specially. They're just one more event
DS> to be fed into a
At 10:56 AM 5/11/2001 -0700, Hong Zhang wrote:
> > >There is no need to store pending signals. It will be impossible
> > >to achieve in a multi-threaded perl runtime.
> >
> > No, it won't be that tough to get multiple pending signals for a thread.
> > Not "real" Unix signals, perhaps, but what lo
All that follows is merely MHO, so feel free to disregard.
On Fri, 11 May 2001, Nathan Wiger wrote:
> Well, I think we should take a step back and answer a few key questions:
>
> 1. Do we want to be able to use Perl 5 modules in a
>Perl 6 program (without conversion)?
From: "Michael G Schwern" <[EMAIL PROTECTED]>
To: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Friday, May 11, 2001 2:27 PM
Subject: Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
> On Fri, May 11, 2001 at 10:56:38AM -0700, Nathan Wiger wrote:
> > 2. Do we want to be able to swit
On Fri, May 11, 2001 at 02:22:30PM -0400, David Grove wrote:
> The largest problem may be in non-compiled modules, perl-only,
> user-designed.
Actually, the largest problem will be *compiled* modules. XS, as it
is very chummy with the Perl internals, will flat out not work.
Anything that uses XS
"David Grove" <[EMAIL PROTECTED]> writes:
> > 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 a
On Fri, May 11, 2001 at 10:56:38AM -0700, Nathan Wiger wrote:
> Well, I think we should take a step back and answer a few key questions:
>
> 1. Do we want to be able to use Perl 5 modules in a
>Perl 6 program (without conversion)?
This would be desirable as it would allow people to c
> Well, I think we should take a step back and answer a few key questions:
>
> 1. Do we want to be able to use Perl 5 modules in a
>Perl 6 program (without conversion)?
For a while, quite possibly, I'd say.
When 5.6 came out, I was in module hell, trying to get 5.005 modules to
compi
> -Original Message-
> From: Nathan Torkington [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 11, 2001 10:20 AM
> To: Chaim Frenkel
> Cc: [EMAIL PROTECTED]
> Subject: Re: perl5 to perl6
>
>
> Chaim Frenkel writes:
> > Those are all major typo inducing changes.
> >
> > You'll need alternat
Nathan Wiger writes:
: I don't think we're seriously in danger of turning Perl into a wild
: froofroo language (we all love it too much). But it's easy to do so
: without realizing it by successive iterations of seemingly minor
: changes which together add up to a big difference.
Well, hey, even
> >There is no need to store pending signals. It will be impossible
> >to achieve in a multi-threaded perl runtime.
>
> No, it won't be that tough to get multiple pending signals for a thread.
> Not "real" Unix signals, perhaps, but what look like them, more or less.
If
> several alarms time o
* Dan Sugalski <[EMAIL PROTECTED]> [05/11/2001 07:19]:
> > >
> > > I think you're in violent agreement here. This has been declared a
> > > goal of Perl 6 from almost day one.
> >
> >Ok, fair enough, but until just a little bit ago I was hearing stuff different
> >from Dan. That has been changed,
* 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
On some date someone wrote:
> : >option in (say) perl5.8 which would allow folk to find typeglobs etc,
> : >and adjust code in advance.
It should be possible to do most of this externally as a B module.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Qualit
On Fri, 11 May 2001, Larry Wall wrote:
> Dave Storrs writes:
> : calling the function that produced the string, or whatever. I just think
> : that we could extend 'x' to have a general repetition meaning.
>
> I think just patching one operator from verbal status to adverbial
> status is not s
Nathan Torkington <[EMAIL PROTECTED]> writes:
>So now the changes are too SMALL, and we should have a language that
> is completely different so that you won't be confused when you edit
> different scripts?
Speaking as someone that has often had to work on C, Perl, Verilog and VHDL
at the same
Chaim Frenkel writes:
: Those are all major typo inducing changes.
That's why Cthulhu invented "use strict".
: You'll need alternative micro-code loads for your fingers, when
: switching between clients and when editing scripts that pre-date Perl
: 6.
People are actually quite adaptable when th
Carl Johan Berglund writes:
: At 08.32 + 01-05-11, <[EMAIL PROTECTED]> wrote:
: >On that topic - it may make sense to have a
: >
: >use warnings 'Perl6';
: >
: >option in (say) perl5.8 which would allow folk to find typeglobs etc,
: >and adjust code in advance.
:
: Excellent idea!
Yes, thoug
Dave Storrs writes:
: Hmmm...I see your point, but I think it depends on what you see as
: the operatee that 'x' is operating on. If it's the string(s) produced by
: <>, then you're certainly right. But if it is the act of iterating
: itself, then I think my suggestion is still valid. And
I consider that the biggest weakness of the regex implementation
currently is that it can't easily return nested data structures.
Of course, regex readability could always use work too.
Larry
David L. Nicol writes:
: Demonstrating, the p5 "cast" can be performed. I guess p6 will
: optimize any @{[...]} constructions into @(...) but still accept
: it as valid, deprecated syntax?
Why should it be deprecated?
Oh, are you wondering because I said that @{foo[bar]} was no longer
valid? J
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 wi
On Thu, 10 May 2001, Larry Wall wrote:
> Dave Storrs writes:
> : should stick with <>. Also, I'd prefer to use the 'x' operator for
> : specifying multiples:
> :
> : @foo = <$STDIN> x 4;
> : @foo = <$STDIN> x &mySub;
> :
> : The parallel with "$foo = 'bar'x2;", where bar is simpl
At 07:45 AM 5/11/2001 -0700, Dave Storrs wrote:
>On Wed, 9 May 2001, Larry Wall wrote:
>
> > Dave Mitchell writes:
> > : My thinking behind "if fails on one, avoid on all" was that if it failed
> > : on at least one, then it may well fail on others that you dont have
> access
> > : to - either
On Thu, May 10, 2001 at 04:26:56PM -0700, Daniel S. Wilkerson wrote:
> Flex - Put all of flex right into Perl.
Having a lexer in Perl is useful, but does it have to be built into
the core? There already are several lexer modules for Perl 5
(Parse::Lex, Lex, Parse::RecDescent...) and while they m
On Wed, 9 May 2001, Larry Wall wrote:
> Dave Mitchell writes:
> : My thinking behind "if fails on one, avoid on all" was that if it failed
> : on at least one, then it may well fail on others that you dont have access
> : to - either now or in the future, and thus perhaps isnt as good an optimi
On Fri, May 11, 2001 at 01:55:42AM +0100, Graham Barr wrote:
> On Thu, May 10, 2001 at 07:40:04PM -0500, Jarkko Hietaniemi wrote:
> > By far most of my use of typeglobs is making aliases, and then mostly
> > for code:
> >
> > *color = \&colour;
>
> I would say that probably the most common u
Chaim Frenkel writes:
> Those are all major typo inducing changes.
>
> You'll need alternative micro-code loads for your fingers, when
> switching between clients and when editing scripts that pre-date Perl
> 6.
So we can't change Perl, because changes have to be learned?
So now the changes are
At 05:23 PM 5/10/2001 -0700, Edward Peschko wrote:
>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 P
On Fri, 11 May 2001 08:29:07 -0500, Tad McClellan wrote:
>On Thu, May 10, 2001 at 04:26:56PM -0700, Daniel S. Wilkerson wrote:
>
>> Flex - Put all of flex right into Perl.
>Don't we already have that in Perl 5?
Sortof.
What he is proposing, is again the age old proposal of putting the
notion o
At 03:41 PM 5/10/2001 -0700, Hong Zhang wrote:
> > similarly, proper safe signals will store all pending signals and
> > deliver each one.
>
>There is no need to store pending signals. It will be impossible
>to achieve in a multi-threaded perl runtime.
No, it won't be that tough to get multiple p
Those are all major typo inducing changes.
You'll need alternative micro-code loads for your fingers, when
switching between clients and when editing scripts that pre-date Perl
6.
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Here's a program I use to count messages in my ma
On Thu, May 10, 2001 at 04:26:56PM -0700, Daniel S. Wilkerson wrote:
> Flex - Put all of flex right into Perl. Flex is simply an event
> engine (-compiler) for driving calls against code according to regular
> expression matching events. While it is often convenient to have the
> the flow of co
On Fri, 11 May 2001 08:20:53 -0400, John Porter wrote:
>> Let's not confuse Perl 6, the Language, with Perl 6, the Implementation,
>> which includes compatibility apparatus that knows about Perl 5.
>
>Maybe we need more difference in the names than "exactly one bit".
Then maybe it's a good thing
Larry Wall wrote:
> Let's not confuse Perl 6, the Language, with Perl 6, the Implementation,
> which includes compatibility apparatus that knows about Perl 5.
Maybe we need more difference in the names than "exactly one bit".
"PVM"? No, that's in use already...
--
John Porter
At 08.32 + 01-05-11, <[EMAIL PROTECTED]> wrote:
>On that topic - it may make sense to have a
>
>use warnings 'Perl6';
>
>option in (say) perl5.8 which would allow folk to find typeglobs etc,
>and adjust code in advance.
Excellent idea!
Cajo.
--
Carl Johan Berglund, [EMAIL PROTECTED], 0708-1
Nathan Wiger <[EMAIL PROTECTED]> writes:
>* 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 per
44 matches
Mail list logo
