Simple honest and hopefully constructive feedback, w/ proposed alternative:

Good:
- it does likely satisfy most basic static text formatting requirements,
and doesn't stress implementations/memory by potentially producing large
intermediate strings; however there are other ways to skin the same cat.

Bad:
- format control is disassociated from the data itself (as it's embedded
within the the constant text field), thereby inhibiting the ability to
compose formatted text, and/or variable formatting, as a function of control
state or variable data at run time; which is likely it's true flaw.

Ugly:
- a function that may return nothing or a string, dual semantics?
- the constant text and formatted variable data parameters don't appear
in the same linear order as the resulting composed text/string/stream;
basically making the composition of the less ideal and likely error prone.

Potential alternative solution:

<input-port> (fmt-string <scheme-element> ...)

Which simply accepts a list of scheme data and formats them into their
default string equivalents based on their type, where elements other than
input-ports not enclosed in lists or vectors are formatted as their
display-equivalent, and elements enclosed in list or vectors are formatted
as their write-equivalent, and input port parameters are lazily read until
empty, thereby enabling a hierarchical composition of text from a sequential
combination of basic scheme elements, and/or higher-level formatters proving
access to their formatted text via input ports, thereby enabling simple
sequential efficient composition of basic output text streams.

<input-port> (fmt-XXXXX (<scheme-element> <format-specifier> ...)

Which is simply a generic template for the definition of arbitrary scheme
element formatters, producing a text input-port returning as a function of
its the element type and optional format-parameters, the element formatted
in a text stream of characters; thereby allowing both the definition of
standard format procedures, as well as arbitrary user defined ones following
the same template naming convention and semantics.

Yielding something reasonably flexible like:

(get-output-string (fmt-string "I have " N (fmt-plural "apple" N) "."))

-> "I have 3 apples."

Where then either display could be extended to accept input-port inputs, or:

<boolean> (pipe <input-port> <output-port> max-characters)

; which simply repeatedly writes to the output-port (which defaults to
(current-output-port) what it reads from the input-port until exhausted (or
exceeds max-characters, which defaults to 0 meaning infinite), returning #t
if input is exhausted, or #f if not.

Yielding something like:

(pipe (fmt-string "I have " (fmt-number N 'digits 4) " lbs. of stuff.\n"))

-> I have 3.234 lbs. f stuff. ; to (current-output-port)

-paul-

> From: Alex Shinn <xxxxxx@synthcode.com>
>
> I retract my previous apologetic attitude towards format and wishy-washy
> "it's ugly but handy" attitude.  I now consider format superior both
> practically *and* theoretically.  I won't fall into the "it's not
> functional, kill it!" camp.
>
> Yes, format is a mini-language.  Mini-languages are not inherently bad.
> R5RS itself uses a mini-language for macros rather than give the full
> functional power of Scheme to macros as CL does.
>
> In this case format is the bottom tier of a long and rich tradition of
> templated output.  If you work with HTML template systems you know that
> one of the Holy Grails of templating is to achieve a clean separation of
> data and logic.  Then you can just pour the data into the template, and
> re-use the same template for different data, or pass the data into
> different templates, or modify a template safely without risk of
> breaking any code.  Full CL format is Turing-complete and therefore
> falls short of this Holy Grail (as do most template systems in practice)
> but still has most of these properties for the common cases, and
> SRFI-{2,4}8 both *do* preserve this distinction.
>
> HTML template systems usually use a more verbose syntax, but that
> doesn't mean that format syntax is bad, nor does it mean we can't revise
> or extend format syntax.  One possibility is to define a full XML-based
> template system and use automatic abbreviations for short format
> strings.  This is a rich area of study and I don't think we should
> abandon it or label it as ugly just "because it's not functional."
>
> Don't be sheep!  The time for that is over, it's almost the year of the
> monkey!  Not everything has to be a function.
>
> --
> Alex
>