lua-users home
lua-l archive

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

Hi David,

Here is what I came up with based on this discussion:


  dump -- dump fully serialized value
  line -- pretty single-line output, no self-ref section
  long -- pretty multi-line output, no self-ref section


  name     nil/string -- name; triggers full serialization
  indent   nil/string -- indentation; triggers long multi-line output
  comment  True/false -- provide stringified value in a comment
  sortkeys true/False -- sort keys using alphanum sorting
  sparse   true/False -- force sparse encoding (no nil filling based on #t)
  compact  true/False -- remove spaces around = and after ,
  fatal    true/False -- raise fatal error on non-serilizable values
  custom   function   -- to provide custom output for tables
  nocode   true/False -- disables bytecode serialization for easy comparison


dump(a, ...) serialize(a, {name = '_', compact = true, comment =
false, sparse = true ...})
line(a, ...) serialize(a, {sortkeys = true, ...})
long(a, ...) serialize(a, {indent = '  ', sortkeys = true, ...})

You can also provide parameters that overwrite defaults. For example,
for diff optimized output:

diff(a) dump(a, {nocode = true, indent = ' '})

Or for AST printing:

asast(a, ...) serialize(a, {custom = function(tag, head, body, tail), ...})

The custom function can print lineinfo on one line or put the tag
value first and so on.

I also plan to use the alphanumeric sort as you suggested
but only when the sortkeys option is on.


On Tue, Jun 12, 2012 at 12:00 AM, David Manura <> wrote:
> On Sun, Jun 10, 2012 at 12:38 AM, Paul K <> wrote:
>>> (2) A "--[[table: 0x9aa7988]]" style comment is appended after each
>>> (3) The keys are not currently being sorted.
>>> (10) Dumps of bytecode are probably not useful for pretty printing
>>> (12) In "nil values are included when expected ({1, nil, 3} instead of
> The above four points all are related to whether the dumper should
> have the property of deterministic output under structural equality.
> Either way, this property may be worth discussing in Features.
> Arguments for deterministic output:
> - Dumping may be used as a poor man's test of structural equality:
> serialize(a) == serialize(b).  This can be useful in test suites.
> More sophisticated alternatives include
> .
> - Sizes of diffs between dumps is reduced.  This may be useful when
> the serializer is used to write data or configuration files to be
> maintained under revision control.  It may also be useful in
> debugging, such as diffing dumps from two separate runs.  However,
> deterministic output is not the only factor affecting diff size.
> - Sorting may improve readability, particularly for tables with many
> elements (e.g. thousands).  However, optimal sort order is subjective
> --
> .
> Arguments against:
> - Impact on performance and code complexity?
> - Not needed in some cases.