lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It was thus said that the Great Nagaev Boris once stated:
> On Sat, Jun 27, 2015 at 6:34 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> > 2015-06-27 3:22 GMT+02:00 Soni L. <fakedme@gmail.com>:
> >> Lua is a programming language. You should be able to use it to its fullest
> >> extent from itself.
> >
> > This is a little like saying: "Mathematics is logical. You should
> > be able to build it up logically from within itself."
> >
> > Lua is an extension programming language. It has no notion of a "main"
> > program: it only works embedded in a host client.
> >
> > The API contains mainly routines needed when you want to augment
> > Lua with stuff better done in C, but it also contains the routines needed
> > for writing a host client.
> >
> > I'm willing to agree that routines whose first argument is a lua_State*
> > should be accessible from a standard library. Even this point has not
> > been conceded by the Lua team: I've several times asked for access
> > to lua_concat (which respects __concat), always without success.
> 
> Would it work like
> 
> local a = "foo"
> local b = "bar"
> local c = debug.lua_concat(2)
> print(c) --> "foobar"
> print(a) --> nil?
> print(b) --> nil?
> 
> ?

  I would think like:

	local c = lua.concat("foo","bar","baz","blah")
	print(c) --> "foobarbazblah"

And it's not like the C code to add it would be that hard---a very simple
implementation (that expect only strings or integers) would be:

	int concat(lua_State *L)
	{
	  lua_concat(L,lua_gettop(L));
	  return 1;
	} 

  -spc (Adding support for __tostring left as an excercise for the reader)