Re: Pooling of strings is good

[Coroutines <coroutines@...>]

On Fri, Aug 22, 2014 at 2:27 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

>
> Except that userdata is advanced, whereas strings are very,
> very basic indeed, there are languages like SNOBOL that have
> nothing but.
>
> Think of pooling strings as Lua's way of dispensing with the
> need to write "const" zillions of times as in C++ (or even C, for
> that matter). It gives me great comfort that I can write
>
>    if line=="rather long string that appears only once"

I am aware of what immutable, pooled strings affords me -- I simply
argue that it can be useful to have both facilities at your disposal.
Mutable, potentially duplicated strings and immutable, pooled strings.

I would rather we stop treating 'string' like a distinct type when it
really carried on the back of userdata.  I'd much rather see
type('cat') == 'userdata'.  We have the ability to create subtypes of
userdata in Lua, we could even manage string pooling directly in a
lookup table.  In my opinion, it might be a big "win" to drop the
responsibility of handling pooled, immutable strings in C -- as
designed by upstream.

I play with networking.  I've written maybe 2-3 different (but
similar) socket libraries for Lua that I've never had the courage to
release.  While doing so, it's always been a loss to use Lua's
standard string type when I want to fetch data from a socket and pass
it to the user to be worked on easily with the string library or
third-party libraries.  It's *expensive* to create long, immutable
strings but the libraries I've come across for unpacking data deal
mostly with strings and not userdata.  A lot of the time it's come
down to just passing data from a connection directly through to a
string parser for human-readable protocols.

I'm simply saying: Let's take a look at how many pooled strings are
compared against.  It's great if you can do a pointer comparison to
check for equality -- I know that -- but I'd rather see 'userdata'
become a 'buffer' type, extended for arbitrary filling and
extending/growing -- which you can then define into the 'string' type
we already love with things like __type and __next for iterating over
utf8.

Sorry if this is a bit confused, I have a lot of ideas in different
directions :\  At minimum I wish more of the standard library were
written in pure Lua, so things like string.match() not accepting
patterns with NULs in them can't happen again.  I like eliminating
liability.  I wish pretty much only the debug library and and the C
API were exposed to Lua, then we could write the rest in Lua directly
at a [negligible] performance loss.  From there we can define a pooled
string type under userdata as the community needs -- I wouldn't want
to see it gone, I just think both mutable and immutable strings are
useful.  And really I love things getting more generic -- this is very
off-topic but I was sad to see __pairs go.  I understand (Luiz's?)
argument that it'd be horrible to have 'one true iterator' for an
object, but I also feel like an iterator wrapped in a function is an
interface you can't predict if you wanted to wrap it in something
else.

Bah.  I've been working more in Javascript lately, reading the Lua
list over the last few weeks has been frustrating because it seems
like 5.3 is going to be jostling for all of us...

Kirk out.

PS: String are userdata :(  I don't want to treat them like a special
type when they *are* just userdata with added magic.  We could do it
in Lua.  userdata used for a buffer type would be much more applicable
~everywhere~, I feel like I have to turn to C to make the best of it
and that frustrates me.  I like working only in Lua if I can.