Re: UTF-8 patterns in Lua 5.3

[Dirk Laurie <dirk.laurie@...>]

2014-04-19 8:46 GMT+02:00 Philipp Janda <siffiejoe@gmx.net>:
> Am 19.04.2014 08:13 schröbte Dirk Laurie:
>
>>
>> Suppose the string library had a function `string.defineclass`.
>>
>>> string.defineclass("%u",utf8.charpatt)
>>
>> stdin:1: attempt to redefine a built-in character class
>>>
>>> string.defineclass("%Z",utf8.charpatt)
>>
>> stdin:1: bad argument #1 to 'defineclass' (must be lowercase)
>>>
>>> string.defineclass("%z",utf8.charpatt) -- then do some great stuff with
>>> %z and %Z
>>> string.defineclass("%z",nil) -- %z and %Z not available anymore
>>
>>
>> What could be allowed as second argument (string, table, function?)
>> will come out during implementation.
>>
>> If the proposed "text" mode could be implemented on top of
>> that, we will have gained a lot more.
>
>
> Unless I miss something, it seems the `defineclass` function is supposed to
> modify some global state in the pattern matching engine. I thought we agreed
> by now that this is a bad idea ...

For a given meaning of "we"?

I'll confess to agreeing that it is a bad idea to modify built-in functions,
and my examples demonstrate that.

> string.defineclass("%u",utf8.charpatt)
> stdin:1: attempt to redefine a built-in character class

The proposal allows for customizable character classes. We already
have that. Nothing (except the vast effort of actually doing it) stops you
from defining your own locale, activating it by os.setlocale(), and hey
presto! the character classes %l, %u, %g, %s and maybe other
classes too (the manual only says "and other character groups")
denote whatever you like.

So all I'm actually proposing is to make custom character classes
explicitly visible as unfamiliar escape sequences, defined from inside
Lua, instead of hiding them in the impenetrable reaches of the
user's OS.