On Wed, 28 Aug 2002, Steve Fink wrote:
> On Wed, Aug 28, 2002 at 12:55:44PM -0400, Deven T. Corzine wrote:
> > On Wed, 28 Aug 2002, Dan Sugalski wrote:
> > > At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote:
> >
> > On the other hand, :, ::, ::: and don't ne
On Wed, 28 Aug 2002, Larry Wall wrote:
> That is a worthy consideration, but expressiveness takes precedence
> over it in this case.
I see nothing wrong with expressiveness taking precedence -- I'm only
saying that it would be best to be cognizant of any restrictions we're
hardcoding into the
On Wed, 28 Aug 2002, Larry Wall wrote:
> : (1) Can we have a ":study" modifier in Perl 6 for patterns?
> :
> : It could be a no-op if necessary, but it could take the place of Perl 5's
> : "study" operator and indicate that the programmer WANTS the pattern
> : optimized for maximum runtime spe
On Wed, 28 Aug 2002, Dan Sugalski wrote:
> At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote:
> >Would it be _possible_ to create a non-backtracking implementation of a
> >Perl 6 pattern engine, or does the existence of backtracking-related
> >operators preclude this p
On 28 Aug 2002, Simon Cozens wrote:
> [EMAIL PROTECTED] (Deven T. Corzine) writes:
> > Would it be _possible_ to create a non-backtracking implementation of a
> > Perl 6 pattern engine
>
> I don't believe that it is, but not just because of : and friends.
> Why do
I have no objection to pattern operators like ::: in principle, but I do
have a potential concern about them.
Given that the operators are actually defined in terms of "backtracking"
within the RE engine, does this constrain the implementation such that it
MUST be a backtracking implementation
On Thu, 15 Aug 2002, Larry Wall wrote:
> On Thu, 15 Aug 2002, Deven T. Corzine wrote:
> : I've got another idea. How about using a copy-restore technique?
>
> I suspect that would make Perl 6's sub calls even slower than Perl 5's.
Yes and no.
For the normal case (p
On Wed, 14 Aug 2002, Luke Palmer wrote:
> Why? We could make arglists exactly equivilent to the way they're done in
> Perl 5, which is a good way.
>
> sub foo($a, $b, *@c) {...}
>
> Would be exactly equivilent to Perl 5's
>
> sub foo { my ($a, $b, @c) = @_; ... }
I've got anothe
On Tue, 13 Aug 2002, Nicholas Clark wrote:
> On Tue, Aug 13, 2002 at 03:06:40PM -0400, Deven T. Corzine wrote:
>
> > The only accurate way to know if the code modifies the variables is to do
> > some sort of dataflow analysis, and it can't be 100% accurate even then.
On Tue, 13 Aug 2002, Larry Wall wrote:
> On Tue, 13 Aug 2002, Deven T. Corzine wrote:
> : However, will the "func($x{1}{2}{3})" case cause an implementation problem?
>
> This is why the new function type signatures will assume that
> parameters are constant. If you wa
On Mon, 5 Aug 2002, Dan Sugalski wrote:
> At 1:30 PM +1000 8/6/02, Damian Conway wrote:
> >Luke Palmer asked:
> >
> >>Does:
> >>
> >> print %foo{bar}{baz};
> >>
> >>still create %foo{bar} as a hashref if it doesn't exist?
> >
> >It is my very strong hope that it will not.
>
> Unless Larry de
On Sat, 23 Dec 2000, Graham Barr wrote:
> This has been discussed on p5p many many times. And many times
> I have agreed with what you wrote. However one thing you did not mention,
> but does need to be considered is
>
> func($x{1}{2}{3})
>
> at this point you do not know if this is a read o
Can the autovivication behavior be changed slightly for Perl 6?
Specificly, can we suppress autovivication in read-only circumstances, and
evaluate the expression as "undef" immediately instead of autovivicating
empty data structures that didn't exist before?
The current behavior in Perl 5 is i
13 matches
Mail list logo
