Re: Feature request: plain option for gsub

[Coroutines <coroutines@...>]

On Fri, Aug 22, 2014 at 3:01 AM, Sean Conner <sean@conman.org> wrote:

>   One reason I use Lua so I can avoid having to think about string
> manipulations.  The above ... sounds complicated.

I don't want the 'string' type to disappear, just be hosted from a
standard library like one would require('table').  Tables already
"exist" in the runtime without that library, but I mean to say I would
be happy having a 'string' library that I must require and it will
inherently manage deduplication for strings I add to the pools I
create (on-demand).  I argue that most of the strings added to Lua's
global string pool don't get compared against enough to justify
pooling, even if there are measurable gains on memory use -- memory
has just never been a big concern for me.  I'm one of the
general-purpose Lua scripters -- I'd still want immutable strings
available for those with harsher hardware constraints.  I like Lua's
lua_Buffer but once it becomes a string it can be a performance
concern to realloc() and grow.  I wish userdata were "enhanced" for
more buffer-like activities and mutable strings were the norm (hosted
off of userdata).  Really I just deal with too many third-party
libraries that expect strings so I must promote userdata to string for
these APIs.  [/religious-war-in-the-making]

>   Um ... I thought by using immutable data you do less locking, not more, if
> I understand the functional programmers arguments.  Could you explain how
> mutable strings leads to *less* locking?

One of the things I wanted to do a while back was start multiple
threads from the main process where Lua is embedded.  Then, without
locking, index _G from different threads so data within the Lua state
could be shared in a sort of "read only and if you want, modify
carefully" schenario.  When I talked about doing this (Roberto?) said
by indexing _G with a string that potentially doesn't exist would mean
having to lock the state to first add the string to the pool within
the state (I think this is the global_State object?).  If strings
weren't pooled then I might be able to get away with this, but I am
not entirely sure -- anyway, it just seems like a speed bump that
would come up quite often.  I dream of a world without data channels
and serializing things -- it *can* be expensive. :\

>   I would accept a string.replace() function that doesn't use patterns.  I
> will not accept an even more complicated string.gsub() function.  Such a
> proposal is leading to a "candy machine interface" that is hard or
> troublesome to use [1][2].

This feels like exaggeration to me -- would my proposal for adding
another parameter to gsub() honestly be too hard to remember or
follow?  I almost never find myself using the n-replacements argument,
few people even realize gsub has a 4th parameter to begin with.  F#ck
it, let's just tear out the spaghetti 500 lines of C for patterns and
hoist in LPeg.  It's a better hammer anyway :-)))