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 win in Perl 6.
:
: Clearly the promise can be broken, so there has
: to be a check somewhere along the line, right?
Depends on what you count as part of "the line". The check could be
eliminated in many cases at compile time, when it is known that the
subscript can only produce integers, and when it is known that the
variable is not tied. (It is difficult to know the latter in Perl 5,
but in Perl 6, lexical variables will only be tied over a lexical
scope, so it is possible to know that know that no check is necessary,
if the declaration does no tie.)
: If there is, and the check shows you don't have a
: (reasonable) integer, then perl can just switch to
: a hash lookup. I'd assume you are doing
: something vaguely similar to this any way, to do
: sparse arrays.
Sparse arrays are done currently with ties, but even sparse arrays are
indexed by integer, so we could probably still use that constraint in
Perl 6 as a basis for optimizing away that check, even if the
particular tied array implementation deals in sparsity.
: If such a check is done, and the compiler code
: is written appropriately, there should be no
: reason why it incurs extra machine instructions
: in the event of there being an integer subscript.
This assumes we're only targeting our own VM. This sort of design
decision might force every integer to be represented as an object
on other VMs.
But that's all beside the point, in a way. I think the distinction
between ordered and unordered in the mind of the programmer is more
important, particularly for those of us with disordered minds.
Larry
