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 20 Nov 2018 15:36 UTC

On 11/20/18 2:45 AM, Shiro Kawai wrote:
> It occurred to me that if we allow to pass a formatter procedure as element-format, it's better for it to receive the entire subarray as well, i.e. (array, object) -> string.
> For example, while we're formatting #2a((#u8(1 2)) (#f32(1.0 2.0))), the formatter F will be called four times, with these arguments:
>
> (F #u8(1 2) 1)
> (F #u8(1 2) 2)
> (F #f32(1.0 2.0) 1.0)
> (F #f32(1.0 2.0) 2.0)
>
> With the array argument, it can make more informed dispatch.

I can't think of a use for this. Do you have an example?

On 11/20/18 7:06 AM, John Cowan wrote:
> I recommend that the format string be replaced by a procedure that accepts two arguments, the object to be printed and a port to print it to, with the default procedure being `display`.  This will make `format-array` equally useful to template systems like SRFI 48 and combinator systems like SRFI 159.

Note that sub-objects will always printed to a string port, since it would have to
write to a temporary buffer, so you can "tile" the sub-outputs together.
A procedure that returns a strings is somewhat easier to work with (and more
"functional") than one that takes a port argument.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/