Re: Lua interface standards

[Sean Conner <sean@...>]

It was thus said that the Great Dirk Laurie once stated:
> The topic is inspired by several recent threads, and may well have been
> addressed on this list before.

  Yes, but no consensus reached.

> Briefly, I think we do not need a Python-like standard library as much
> as we need standards for those common tasks that tend to entice module
> writers into inventing ever-better wheels.
> 
> The standard should be as sparse as possible, so that
>   (a) There is not much that the user needs to know.
>   (b) The quirks of particular existing implementation do not get
> so fondly described as 'standard' that no other implementation
> qualiifies.

  And so the lowest-common-demoninator wins.  Woot!

  I'll bring up syslog as an example---most implementations are a literal
wrapper around the C API [1] on the grounds that it's often easier [2] and
leave the "Luaization" of the module to actual Lua code (that never gets
written for some odd reason) that means that any "standard Lua mdoule" will
be horrible to use (if I want to program in C, I know where to find it [3]).

  Now I'll switch topics and bring up signal().  Again, most Lua modules
around signal() follow the same approach as syslog() and worse, usually wrap
the POSIX version, completely ignoring ANSI C (POSIX has more functionality,
but not everything uses Lua on a POSIX system).  As such, the API I present
works the same for ANSI C and POSIX (with a bit more available under POSIX). 
The minimum API (ANSI C) consists of:

	-- signal can be
	--	vwl imprd vrsn	fully spelled out version
	-- 	------------	--------------
	--	'abrt'		'abort'
	--	'fpe'
	--	'ill'		'illegal'
	--	'int'		'interrupt'
	--	'segv'		'segfault'
	--	'term'		'terminate'

	signal.catch(signal[,handler]) -- either set a flag, or run handler on signal
	signal.ignore(signal)
	signal.default(signal)
	signal.caught([signal]) -- if no signal given, all signals will be checked
	signal.raise(signal)
	signal.defined(signal)	-- check for support of a given signal
	signal._implemetation	-- "ANSI" or "POSIX"

  The POSIX version will support the above as is, but has further
functionality that I won't go into right now.  That's the bare minimum for
an API for signals.

  Could I implement the above using, say, luaposix?  Or some other Lua
signal module?  Probably yes, but this is why I am not hopeful about
this---because the lowest-common-demoninator, non-Luaesque version of
modules will win.

> For example, a module conforming to the 'json' standard should
> be loadable as `json = require "bestjson"` and provide methods
> json.decode (string to table), encode (table to string), and a unique
> immutable value json.null. In this case it is obvious how the table
> should look, but the standard should document it. Anything else is extra.

  So what about

        __tojson
        __jsonorder
        __jsontype
        __is_luajson
        __json

> When it comes to XML, it is no longer so obvious (does the attribute
> table go into [0] or a member named 'attr'? must the code/decode be
> deterministically reversible?), so the foundation or user association
> or benevolent dictator has some decisions to make.

  It's obvious:

        <xsl:call-template name="common-index">
          <xsl:with-param name="objects" select="section[@id != 'Errors']" />
        </xsl:call-template>

will translate to:

	{
	  [0]   = "call-template",
	  xmlns = "http://www.w3.org/1999/XSL/Transform";,
	  name  = "common-index"
	  [1] = {
		[0]    = "with-param",
		xmlns  = "http://www.w3.org/1999/XSL/Transform";,
		name   = "objects",
		select = "section[@id != 'Errors']",
	  },
	}

  -spc (Oh, and let us not forget about metatables ... )

[1]	http://lua-users.org/lists/lua-l/2015-03/msg00001.html

[2]	"Because I'm lazy and don't like programming in C"

[3]	I think I've said this before ... oh yeah ...

	http://lua-users.org/lists/lua-l/2016-03/msg00010.html
	http://lua-users.org/lists/lua-l/2016-03/msg00152.html
	http://lua-users.org/lists/lua-l/2016-07/msg00113.html
	http://lua-users.org/lists/lua-l/2015-01/msg00687.html

	and possibly other messages ...