Re: The hypothetical __serialize metamethod (was Re: [ANN] luaproc 1.0-4)

[Sean Conner <sean@...>]

It was thus said that the Great steve donovan once stated:
> On Wed, Oct 7, 2015 at 7:01 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> > One question: In a human readable format, how would you represent
> > floating point numbers that don't have a perfect string
> > representation?
> 
> Well, most floating-point numbers don't have an exact representation
> in 64-bits anyway. There are the 'specials' INF and NAN but they can
> be special-cased.

  The issue is one INF, one -INF and 2^53 NaNs.  That's a lot of special
cases.

> It's the old trade-off between efficiency and discoverability, really.
> Diagnosing problems with binary formats is harder.

  It's only marginally harder as it requires a tool to dump the binary.  For
my CBOR stuff, I do have a script that does a literal dump of the data. 
Example:

	D8 1C A2 D8 1C A3 01 01
	02 02 03 03 D8 1D 00 D8
	1D 00 D8 1D 01

  Output from my CBOR debugging tool:

TAG	_shareable
MAP	2
	TAG	_shareable
	MAP	3
		UINT	1
		UINT	1
		UINT	2
		UINT	2
		UINT	3
		UINT	3
	TAG	_sharedref
	UINT	0
	TAG	_sharedref
	UINT	0
	TAG	_sharedref
	UINT	1

  Perhaps a bit better output would be:

	D81C	TAG	_shareable
	A2	MAP	2
	D81C		TAG	_shareable
	A3		MAP	3
	01			UINT	1
	01			UINT	1
	02			UINT	2
	02			UINT	2
	03			UINT	3
	03			UINT	3
	D81D		TAG	_sharedref
	00		UINT	0
	D81D	TAG	_sharedref
	00	UINT	0
	D81D	TAG	_sharedref
	01	UINT	1

  Or perhaps the formats used in RFC-7049:

	_sharable([ 
		_sharable([1: 1, 2: 2, 3: 3]): _sharedref(0),
		_sharedref(0): _sharedref(1)
	])

  -spc (Six of one, half-dozen the other ... )