[Nickle] Rationalizing printf format types
keithp at keithp.com
Tue Dec 14 16:08:15 PST 2004
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
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20041214/a8bd6fae/attachment.pgp
More information about the Nickle