Re: [WIP][PATCH 2/2] pkl,pvm: add support for regular expression

[Jose E. Marchesi]

> Hi Jose.
>
> On Wed, Feb 15, 2023 at 09:38:31PM +0100, Jose E. Marchesi wrote:
>> 
>> > On Wed, Feb 15, 2023 at 11:01:01AM +0100, Jose E. Marchesi wrote:
>> >> 
>> >
>> >> I don't think it is a good idea to expose the regexp machinery in std
>> >> like this.
>> >> 
>> >> I thought we were targetting adding support for STRING ~ REGEXP at the
>> >> language level?  The compiler can then generate calls to _pkl_re_gmatch
>> >> and DTRT...
>> >> 
>> >
>> > Yes, I wanted to enable us to use regexp for problems we already have
>> > sooner.
>> > Because we have to think about the struct patterns as a general mechanism
>> > and rushing to implementing regexp at language level can cause problems
>> > for us.
>> 
>> Well, it is difficult to support regexp matching with an operator while
>> also supporting matching groups, etc.
>> 
>> The operator would only evaluate to true or false.  How to convey the
>> other information while having ~ return a value that can be used in a
>> conditional?
>> 
>> What we could do is to have both: a ~ operator that returns true/false,
>> and also a pk_regexp_gmatch that returns a Pk_Regexp_Match.
>> 
>
> What about having a new compile-time type for matched entities.
> Both useful in regular expression matching for strings and array of
> characters.
>
> Something like this:
>
> ```poke
> var m1 = "Hello pokers!" ~ /[hH]ello/,
>     m2 = [0x00UB, 0x11UB, 0x22UB] ~ /\x11\x22/;
>
> if (m)
>   {
>     printf "matched at index %v and offset %v\n", m.index_begin, 
> m.offset_begin;
>     assert ("Hello pokers!"[m.index_begin:m.index_end] == "Hello");
>   }
> else
>   {
>     assert (m.index_begin ?! E_elem);
>     assert (m.offset_begin ?! E_elem);
>   }
> ```
>
> We can use other fields for the giving the access to sub-groups.
>
> We can take an approach similar to `Exception` struct.  But for `Matched`.
> Compiler can cast it to boolean when necessary.

The idea is interesting.  But I don't like the part of changing the
semantics of `if' like this: it is not orthogonal.

Note that the syntactic construction that uses Exception only works with
exceptions:

  try STMT; catch if EXCEPTION { ... }

If we could come with a syntactic construction for regular expression
matching, then it would be better IMO.