At 05:16 PM 8/4/00 +0100, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > Indirect calls might not be a problem, depending on how much flow analysis
> > we can do in the optimizer. While that won't be much in the
> > on-the-fly-compile version (a 10s runtime with a 50s compile ti
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Indirect calls might not be a problem, depending on how much flow analysis
> we can do in the optimizer. While that won't be much in the
> on-the-fly-compile version (a 10s runtime with a 50s compile time's not a
> good thing...) I'm hoping the optimiz
At 09:10 AM 8/4/00 -0600, Tom Christiansen wrote:
> >At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
> >>John Tobey wrote:
> >> > The Perl 5 (and older) behavior may preclude some optimizations.
> >>
> >>I can't think of any optimizations @_ assignment precludes.
> >>If we don't analyze dataflow to figur
>At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
>>John Tobey wrote:
>> > The Perl 5 (and older) behavior may preclude some optimizations.
>>
>>I can't think of any optimizations @_ assignment precludes.
>>If we don't analyze dataflow to figure out if a sub modifies its
>>args, then we just assume it wil
At 12:47 AM 8/4/00 -0400, Ken Fox wrote:
>John Tobey wrote:
> > The Perl 5 (and older) behavior may preclude some optimizations.
>
>I can't think of any optimizations @_ assignment precludes.
>If we don't analyze dataflow to figure out if a sub modifies its
>args, then we just assume it will.
If
At 08:20 AM 8/4/00 -0400, John Tobey wrote:
>Ken Fox <[EMAIL PROTECTED]> wrote:
> > John Tobey wrote:
> > > The Perl 5 (and older) behavior may preclude some optimizations.
> >
> > I can't think of any optimizations @_ assignment precludes.
> > If we don't analyze dataflow to figure out if a sub m
Ken Fox <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
> > The Perl 5 (and older) behavior may preclude some optimizations.
>
> I can't think of any optimizations @_ assignment precludes.
> If we don't analyze dataflow to figure out if a sub modifies its
> args, then we just assume it will.
Supp
John Tobey wrote:
> The Perl 5 (and older) behavior may preclude some optimizations.
I can't think of any optimizations @_ assignment precludes.
If we don't analyze dataflow to figure out if a sub modifies its
args, then we just assume it will.
Is this just a style issue? Why would you allow it
Peter Scott <[EMAIL PROTECTED]> wrote:
> So user subroutines should not be able to reproduce the semantics, of,
> e.g., sysread()? I was hoping for more equality in this respect (user subs
> being able to do anything builtins can) rather than less.
Let me clarify. Only unprototyped subs are a
At 08:18 PM 8/3/00 -0400, John Tobey wrote:
>Unprototyped subs should not be allowed to modify their callers' data
>simply by assigning to elements of the arg array. This form of
>passing by reference is obsolete now that Perl has hard references and
>C<\$> in prototypes. The feature is confusin
This is not quite finished yet, as I read the rest of the C-- garbage
collection paper.
-John
=head1 TITLE
Elements of @_ should be read-only
=head1 VERSION
Maintainer: John Tobey <[EMAIL PROTECTED]>
Date: 3 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number:
=head1 ABSTRA
11 matches
Mail list logo
