[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua interface standards
- From: Sean Conner <sean@...>
- Date: Sun, 23 Apr 2017 05:05:39 -0400
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 , not praising it.
> let's drop this function. (Else we should provide one verify() to check
> string before decoding and other verify() to check table before
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
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  module  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).
 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() .
 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.
 Concise Binary Object Representation http://cbor.io/
Also available via LuaRocks as "org.conman.cbor"