On 05/20/2013 07:02 PM, John Cowan wrote:
>> Another issue is the interaction with format specifiers.
>
> I personally detest these: I much prefer Alex Shinn's fmt library
> <http://synthcode.com/scheme/fmt> and hope it becomes the formatting
> solution for R7RS-large.  Much cleaner, more Schemey, and easier to
> extend coherently.

A fmt-style facility might also integrate pretty well with
SRFI-10[789]:

   &{abc&[<format> ...]xyz}

where the currently constructed string is the output destination.

Studying the fmt document, some possible variants suggest themselves:

* Instead of a format closure being a one-argument function taking
a format-state, it could be a zero-argument function that uses
a parameter for the current state, and returns a string.  This could
be simpler and more flexible.  For example: Initially there could
be a "null" format state, so the format just evaluates to a string.
Such zero-argument functions may also be easier to understand
for some.

* Instead of zero-argument functions, each format is a promise,
evaluated when needed.

* Maybe generally use parameters more.  Maybe use macros more.
E.g. fmt is a syntatic sugar for a parameterize, and the
<format> are just simple string expressions evaluated in that context,

* Possibly use keyword arguments - if the language supports them.
Some of the format functions take a long list of parameters,
and using kewords might help.

* If fmt were a macro (instead of a function) if could introduce
into the body scope short (single-letter or double-letter)
abbreviations for format functions.  For example credit, only
introduce these abbreviations in the "function position", while
evaluating arguments in the normal scope.

Anyway this is off-topic.  Just suggesting that while fmt is
an elegant idea, variations of the idea might worth considering,
when the time comes.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/