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/