Re: Feature request: plain option for gsub

[Sean Conner <sean@...>]

It was thus said that the Great Coroutines once stated:
> On Fri, Aug 22, 2014 at 2:31 PM, Sean Conner <sean@conman.org> wrote:
> 
> >  Clarification:  by "userdata" do you mean the underlying string-type
> > userdata, or *any arbitrary* userdata?
> 
> I mean any userdata.  We're free to do what we want with their
> contents from C, but not from Lua -- I wish we had functions available
> to read and modify userdata from Lua.

  Okay, now I'm totally confused as to what you are trying to do.  Let's
take, for example, LPeg.  

	> lpeg = require "lpeg"	-- I'm using 0.12 BTW
	> x = lpeg.P "Coroutines"
	> print(type(x))
	userdata: 0x8835e7c
	> show(getmetatable(x))
	__unm    function: 0x88339e8   
	__len    function: 0x88339b8   
	__gc     function: 0x881d998   
	__add    function: 0x8833128   
	__div    function: 0x88339d0   
	__pow    function: 0x88336a8   
	__index  table: 0x8833958      
	__sub    function: 0x8833940   
	__mul    function: 0x882e498   

  Okay, what exactly, are you trying to modify?

  And before you say, "well, we can get the contents of the of a structure
in C"---not always.  All I get when I use Lua is the following definition:

	typedef struct lua_State lua_State;

and that's it.  No indication of how big it is, or what's inside it.  Try to
compile the following:

	#include <lua.h>
	#include <lualib.h>
	#include <lauxlib.h>

	lua_State g_state;

When I do I get:

	x.c:6: error: storage size of _state' isn't known

So I can't, in any meaningful way, read and modify lua_State from within C. 
Yes, sure, I can include some other header files from lua-5.[123]/src to get
the internal structure but that's not the expected behavior.

  Even with the standard C library, I really have to scour the headers to
see how FILE is defined [1].  So yeah, I can reach in there, but 1) the
resulting program will probably only work on my computer, with the
particular version of the library.  

  In other words, it's not portable and you stand to break your warranty.

> >   Clarification:  by "thread" do you mean an OS thread, or a Lua coroutine?
> 
> I mean OS thread.

  Okay.  There are so many problems with multi-threaded programming that I
tend to use a "share-nothing, message passing" paradigm when working with
threads.  Mutable, shared data structures are just too fragile or slow (or
both) for me to feel safe using them.

  I also don't fully understand what you mean by:

> I dream of a world without data channels and serializing things

  -spc (But as long as the Internet and Intel chips exist, you'll have
	serialization issues ... )

[1]	I ended up running "gcc -E file.c >i.i" and track stuff down in
	there.