Re: Lua interface standards

[Sean Conner <sean@...>]

It was thus said that the Great Martin once stated:
> On 04/23/2017 12:54 AM, Sean Conner wrote:
> > It was thus said that the Great Martin once stated:
> >> Should standard provide .verify(t) function?
> > 
> >   What should this do?
> 
> verify(data) should return true if codec fully understand given <data>.
> Else it should return nil and error message. So it guaranties that
> subsequent call to encode() or decode() will not raise data-dependent
> errors. (In many cases checking input before actual work is cheaper in
> resources than interrupting work due inconsistent data.)

  Um ... what?

  The work that verify() would do is pretty much the same that
encode()/decode() would do, so it doesn't make sense.  Besides, someone
could *still* call encode()/decode() and skip calling verify() entirely, so
you *still* have to do the work in eocode()/decode().

> But this conflicts with least-common-denominator philosophy, 

  I'm not sure if I made myself clear, but I'm decrying the
"least-common-denominator" philosophy [1], not praising it.

> so
> let's drop this function. (Else we should provide one verify() to check
> string before decoding and other verify() to check table before
> encoding.)

  And how do you enforce calling verify() prior to encode()/decode()?

> >> What if I want to serialize parts that can be serialized and omit
> >> others? Should standard provide .align(t) function?
> > 
> >   Least-common-demoninitor behavior is to assume error() and if it can't
> > serialize what you give it, then error().
> 
> error() is too ridiculous. Suppose user calls json.encode(_G).
> Can it be fully serialized? 

  Maybe.  See below.

> No. Can it be partly serialized? Yes.
> What should be done to serialize it partly? align() data before
> encoding.

  The name "align()" is a bad name for this.  "sanitize()" would be better.

> So user have options to call
>   s = json.encode(_G)
> 
> which will return nil or raise error() but
> 
>   data = json.align(_G)
>   s = json.encode(data)
> 
> will do job to some degree.
> 
> Similar problems will rise if we want standard for lua table
> serializers, which encodes table to string with lua code.
> AFAIK noone of them can handle table with cycles, with
> metatables and with table keys.

  My CBOR [3] module [4] can deal with cycles, metatables and tables as
keys.  An earlier version (not released) could also deal with serializing
_G, or even _G.io, _G.math, etc.  One of the neat things about CBOR is that
one can semantically mark data, so I got around serializing _G by marking
the string literal "_G" as "standard Lua object" (same with serializing
functions like print() or userdata like io.stdio).  So it can be done, to a
degree.  I even started on serializing actual Lua functions (as long as they
were written in Lua)---first by sending the actual code if avaiable and
failing that, as PUC Lua bytecode in an architecture neutral format (never
finished that part).

  -spc 

[1]	One of the worse offenders of this is Danial Bernstein, who's code
	assumes *no standard library whatsoever* and provides his own
	version of routines like memcpy() or strlen() [2].

[2]	Granted, back in 1990, that might have made a bit of sense since C
	(and its standard library) was only standardized the previous year. 
	But most of his code was written nearly a decade later.

[3]	Concise Binary Object Representation http://cbor.io/

[4]	https://github.com/spc476/CBOR

	Also available via LuaRocks as "org.conman.cbor"