[Nickle] Rationalizing printf format types

[Keith Packard]

Right now, nickle uses a ad-hoc collection of format specifiers for 
various datatypes to figure out how to display data.  I'd like a more 
rational approach.

I think we want at least two kinds of output:

 1) Straightforward human (and machine)-parsable values.

 2) Reparsable (by nickle) output guaranteed to exactly reproduce the 
    given value.

For the second, I suggest a single formatting code which ignores and width and 
precision and just presents the value in nickle parsable form.  We've 
almost got that now, except for floating point numbers which have no 
lexical form at all.  Tagging a numeric value with precision is the 
obvious solution, but I don't have a syntax suggestion.

The interesting case is the first, and there we (currently) have 
conflicts.

The first question is what (if any) typechecking should be done between the
format letter and the datatype.  Currently, some formats are type-specific
and some are polymorphic.  This lack of consistency doesn't seem right.

Secondly, we need to acknowledge that nickle output is often parsed by
other programs, and our strange rational number format is not useful in
that context.  Either the default format should be different or there 
should be a command line option to set the format to something reasonable. 
Right now, there is no "reasonable" format to use -- 'g' yields braces and 
'f' yields exceptions for non-strings.

Third, we need some idea of how these formats apply to composite values.  
Right now, composite types cannot use anything other than a polymorphic 
format, which means you get either 'v' or 'g' because everything else is 
typechecked.  This is a pain when you just want to print a list of numeric
values from an array; the obvious printf ("%8.3f ", array_of_real) doesn't 
work.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041214/a8bd6fae/attachment.pgp