Chaim Frenkel wrote:
> The Bytecode representation should be mutable and contain enough iformation
> for type/data flow analysis.
What do you mean by "mutable"? Wouldn't the dataflow analysis for a
given bytecode be immutable? Or do you mean the implementation should
be hackable?
> (Do you think
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> That's the beauty of the entire existing Perl code base -- every
KF> program presents its complete source code to the interpreter. Once
KF> bytecode and native function calls arrive it will be a lot harder
KF> to get dataflow analysis implemen
Steve Fink wrote:
> There are many possible goals for any typing-related stuff we do. I'd
> say the top three are:
>
> - compile-time warnings
>- definitely unsafe operations
>- probably unsafe operations
> - runtime storage optimization
> - runtime time optimization
Yes. The last two ar
Ken Fox wrote:
>
> IMHO type inference is the best way to get typing into Perl.
> We don't lose any expressiveness or hurt backwards compatibility.
> About the only thing we need to make visible are a few additional
> pragmas to enable type inference warnings.
>
> Steve Fink wrote:
> > Types sho
IMHO type inference is the best way to get typing into Perl.
We don't lose any expressiveness or hurt backwards compatibility.
About the only thing we need to make visible are a few additional
pragmas to enable type inference warnings.
Steve Fink wrote:
> Types should be inferred whenever possibl
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 0 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
Types should be inferred whenever possible, and optional type qualifiers
may be used to
