ssing. What is more, I
> believe that the changes above can remove most of the
> significant bottlenecks for the problems we have in text-
> processing of today. At least I know a lot of problems which
> would have feasible solutions given these changes.
>
> And I need not repeat that a handful of small extensions to
> the expressive power of the regular expression engine could
> radically extend the domain of its applicability. ;-)
>
That's exactly the kind of thing we can do by exposing regexp engine's guts.
Tags in the string we can implement by using lists, just as lisp would do
it. If we have SVs that actually independ from the implementation, we can
create a ``tagged-string'', that's seen as a string by the script but
internally implemented as a list. And, if we have access to the regexp
engine's guts, we can implement matches and substitutions against those
magic tagged strings.
The other thing about copy-on-write would be piece of cake, using the same
magic SVs for implementing strings that are substrings of other strings.
Branden.
Damian Conway wrote:
> # As Branden proposes:
>
> package From_STDIN;
>
> sub new { bless $_[1], $_[0] }
>
> sub MORE_DATA { $_[0]->getn($_[1]) }
> sub ON_FAIL { $_[0]->pushback($_[1]) }
>
> use overload "=~" => 1;
>
> pack
