[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: format strings are the Right Thing

This page is part of the web mail archives of SRFI 48 from before July 7th, 2015. The new archives for SRFI 48 contain all messages, not just those from before July 7th, 2015.

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

- 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.

- 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.

- 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)


> From: Alex Shinn <foof@xxxxxxxxxxxxx>
> 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