Email list hosting service & mailing list manager

Element-format argument Shiro Kawai (18 Nov 2018 01:17 UTC)
Re: Element-format argument Shiro Kawai (20 Nov 2018 10:45 UTC)
Re: Element-format argument Per Bothner (20 Nov 2018 15:36 UTC)
Re: Element-format argument Shiro Kawai (20 Nov 2018 18:43 UTC)
Re: Element-format argument Per Bothner (21 Nov 2018 03:14 UTC)
Re: Element-format argument John Cowan (20 Nov 2018 15:06 UTC)

Re: Element-format argument Per Bothner 21 Nov 2018 03:14 UTC

On 11/20/18 10:43 AM, Shiro Kawai wrote:
> On Tue, Nov 20, 2018 at 5:36 AM Per Bothner <xxxxxx@bothner.com <mailto:xxxxxx@bothner.com>> wrote:
>
>     I can't think of a use for this. Do you have an example?
>
>
> If you're printing #a(#f32(....) #f64(....)), you might want to have different format string (e.g. "~,6f" for f32 value, "~,15f" for f64 value) depending on the type of the subarray.
> Or, printing #a(#u8(...) #u32(...)) and "~4d" for u8array and "~11d" for u32array.

That seems a bit "non-Schemy" to have the format depending on the type of the
container, rather than any kind of semantic value.

More useful, perhaps, would be two outputs: a string, plus an alignment position:
Each output cell (in the same non-nested array) would be padded so the alignment
positions are above each other. Of course this makes for an awkward API. Perhaps
there an elegant way to specify alignment using combinators.

I'd rather not get down into a rat-hole trying to design this API.
Maybe just specify something like:

    It is implementation-defined if format-array can be called with more than 2 arguments.
    For example the Kawa implementation of format-array allows an optional 3rd argument, which
    is interpreted as a format string in the style of SRFI 48, used to each array element.
    Other implementations may allow a formatting procedure or combinator.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/