Mark Kvale <[EMAIL PROTECTED]> wrote:
:As one of the 3 or 4 people in the world that understands the p5 engine, we
:would welcome your input.
'Understands' is a rather strong word ...
:The current thinking, and a5 just reinforces it, is that regexes will be
:compiled down to Parrot bytecode, so there should be no technical problem
:with preserving the metainformation at the end of a regex call.
:
:We do, however, have a set of specialized regex ops that may be used to
:simplify and/or speed up atomic matching operations. They currently maintain
:an internal state that is mostly opaque at the Parrot bytecode level. That
:state may need to be made more transparent.
Indeed - I don't really know what the 'state object' will look like,
but (except where static/dynamic analysis can determine it won't be
used) that's where such data will need to go.
Nor do I know what the 'result object' will look like. It may not need
to contain much more than a copy-on-write reference to the final state
object, though it'd want to be an intelligent copy to avoid preserving
unnecessary data.
The result object may also be tricky to get right, particularly in one
area (though there are other p6 objects that may suffer from this) -
because we'll be providing a useful stringify on it, it'll be natural
in some contexts to think of it as the string itself; however, when
you use it as a hash key (as in some A5 examples) we no longer coerce
to string by default, so you won't get the key you were expecting.
Larry was thinking you might have to tag the hash as taking stringified
keys in such cases, but that hasn't been finalised; certainly you
can always get around it with an explicit coercion:
$key := <{ %hash.prop{keymatch} // /\w+:/ }> # find key
- <( exists %hash{$key} )> # if exists
+ <( exists %hash{_$key} )> # if exists
Another really difficult area is going to be optimisation; I rather
look the idea of using 'observer properties' for this - do the
optimisation if it'll be useful now, without throwing away the
unoptimised version, and tag a callback on the string or other data
you relied on so that if changes to the data invalidate the
optimisation you can switch back to the original version. I envisage
that this approach could be used throughout parrot, so that when
you assign (say) an annotated string to a variable that previously
contained a simple string you'd trigger a cascade of layered
deoptimisations that would keep things working correctly.
Hugo
