4 ms·
>> Too many to enumerate I take back my previous claim, this is a wrong exaggeration. > The tool could be extended to support Unicode Not an easy task. There
by bmn__ 6y ago
>> Too many to enumerate
I take back my previous claim, this is a wrong exaggeration.
> The tool could be extended to support Unicode
Not an easy task. There are some things in the standard that do not map neatly to states, notably foldcasing of characters that change the count of characters and the treatment of the generic line boundary. Edit: after browsing UTS#18, I am almost certain that a conforming implementation cannot be mapped as exemplified in the tool. Maybe there's a neat work-around possible.
> features that would be impossible to support?
(?=, (?!, (?<=, (?<!, (?{, (??{, (?&, (?(…), (?>, (*asr:, (*SKIP)
- abecedarius 6y agoIntersection and complement are both expressible in regular expressions (in the CS sense). Is that not what you mean by impossible to support? (I'm too lazy to look up what the other listed notations mean.)
- bmn__ 6y ago> Is that not what you mean no, I mean generic line boundary
- allanrbo 6y agoSome of these are in fact possible, though with some restrictions. I wrote a blog post on how to support some negative lookbehinds: http://allanrbo.blogspot.com/2020/01/alternative-to-negative-lookbehinds-in.html http://allanrbo.blogspot.com/2020/01/alternative-to-negative...