* 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]
> 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
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
> >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,
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
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
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 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
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
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
27 matches
Mail list logo
