Re: [RFC/PATCH v2 1/4] output: Add a new library for plumbing output

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Apr 13, 2010, 09:43 UTC
Message-ID: <20100413094351.GA2558@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20100411232118.67460.52907.julian@quantumfyre.co.uk>

On Mon, Apr 12, 2010 at 12:21:14AM +0100, Julian Phillips wrote:

I'm writing S-Expression output backend as experiment (not yet even sendable as WIP) and hit an issue in general framework...

Also, some comments on documentation...

Show 6 quoted lines

> +The output consists of objects, arrays and the actual values, the term item is
> +used where any of these may be used, and container when either an object or
> +array may be used.  Objects are unordered collections of named items, and arrays
> +are ordered collections of unnamed items.  For simplicity a name is always
> +supplied when creating an item - though it may not always be used (e.g. if you
> +are adding the item to a list).

List? Above says types are 'object', 'array' and 'value'. Then it defines terms 'item' and 'container'. But what is 'list'?

> +* Unstructured Output Functions

Maybe add extra note about these. When one sees output_token used in code outputting stuff, one can get puzzled until one realizes that token output is ignored for non normal/zero outputs.

Show 5 quoted lines

> diff --git a/output.c b/output.c
> new file mode 100644
> index 0000000..ac8feb1
> --- /dev/null
> +++ b/output.c

Show 12 quoted lines

> +void output_end(struct output_context *context)
> +{
> +	while(context->current)
> +		output_end_current(context);
> +
> +	/*
> +	 * OUTPUT_NORMAL and OUTPUT_ZERO are special cases - the output format
> +	 * is _already_ defined so we have to stick to the rules, we can't add
> +	 * _anything_
> +	 */
> +	if (context->style > OUTPUT_ZERO)
> +		fprintf(context->file, "\n");

This is AFAIK really inapporiate for canonical S-Expression output. Point of canonical S-Expressions is to have only one way to serialize given tree (bit for bit identicality) and linefeeds are not allowed except as serialization of linefeed in string.

Perhaps one could add method/flag to output backend to tell wheither to print trailing linefeed?

> +
> +	free(context);
> +}

-Ilari