On Tue, 26 Sep 2000 11:55:32 +1100 (EST), Damian Conway wrote:
>Wouldn't this interact rather badly with the /gc option (which also leaves
>C<pos> set on failure)?
Yes.
The easy way out is disallow combining /gc wit h/z. But, since this
typically one of the applications it is aimed for, I should find a
solution. A different interface, is one option.
>This question arose because I was trying to work out how one would write a
>lexer with the new /z option, and it made my head ache ;-)
Heheh. Your turn. ;-)
>I'm not sure I see that this:
...
>is less intimidating or closer to the "ordinary program flow" than:
>
> \*FH =~ /(abcd|bc)/g;
>
>(as proposed in RFC 93).
Was that what was proposed? I think not. It was:
sub { ... } =~ /(abcd|bc)/g;
But I kinda like that syntax. But, in practice, it looks too much like
black magic:
* where is the sting stored? It looks like it disappears into thin air.
* What about pushback? Your proposal depends on it, but standard
filehandles don't support it, IMO. Does this require a TIEHANDLE
implementation?
* Your regex shouldn't consume any more characters friom the filehandle
than it matches? Where are the reamining characters pushed back into?
> > After every single keystroke, you can test what he just
> > entered against a regex matching the valid format for a number, so that
> > C<1234E> can be recognized as a prefix for the regex
> >
> > /^\d+\.?\d*(?:E[+-]?\d+)$/
>
>Isn't this just:
>
> \*STDIN =~ /^\d+\.?\d*(?:E[+-]?\d+)$/
> or die "Not a number";
>
>???
No. First of all, you can't override the behaviour of STDIN. That reads
a whole line, then checks it, and then your script dies if it's not
right.
I want a test on every single keystroke, see if it's in sync with the
regex, and if it's not, reject it, i.e. no insertion in the uinput
buffer, and no echo on screen. Besides, you can't be sure your data
comes from a filehandle (or compatible handle). Not in a GUI.
--
Bart.
