Re: Format strings are wrong

[Paul Schlie <schlie@xxxxxxxxxxx>]

Alex Shinn wrote:
> The SRFI process isn't just about porting, but also standardizing
> libraries....In this case almost all Schemes at least support
> SRFI-28, and many support some or all of the full Common-Lisp format,
> so it is definitely something people find useful and should be
> standardized.  Many people feel SRFI-48 doesn't go far enough, so
> there will likely be at least one more format SRFI.  Perhaps that will
> explicitly make the individual formatting procedures accessible as
> they are in Dirk Lutzebaeck's implementation, which would give you the
> option of using both styles.

I appreciate that the SRFI process enables the definition of proposed
language/library features by providing a forum for such proposals; some
of which may be adopted, discarded, and/or refined through time for
incorporation into recommended practice.

I just simply believe that although a language/library-collection may enable
a particular capability through a variety of approaches, the approach which
should be recommended/adopted should strictly as reasonably possible follow
the philosophy of the language itself in a unifying manor; where by so
doing, multiplicatively extends it's expressive power. Which is basically
why I tend to believe that rather than simply attempting to "standardize"
potentially poor practices simply because they may exist in some form, it
may be better to reformulate unified solutions where possible based the
principles and philosophy of the core language itself for the fore
mentioned reasons.

>> Possibly something along the lines of simply adopting the notion that:
>> (philosophy ....) [or (string ...) be extended] to accept mixed string,
>> symbol, character and numerical arguments, and produces a string resulting
>> from the concatenation of its argument's string equivalences
>
> Probably best not to overload string, especially in light of recent
> discussions as to just what a character is.  Also, the procedure
> should definitely output to a port, not a string.  But even using a
> port this becomes inefficient if you inline write's:
> 
>   (define (write-to-string x) (with-output-to-string (cut write x)))
>   (fmt #t "list: " (write-to-string ls) #\newline)
> 
> and likewise for performing different number->string conversions in
> the middle of a format.  You really have to break it apart as:
> 
>   (display "list: ")
>   (write ls)
>   (newline)
> 
> which when compared with
> 
>   (format #t "list: ~S\n" ls)
> 
> looks clumsy and verbose, ... All around, format is more consice...

Huh? 

(display (string "list: " ls #\newline) to-what-ever-port-you-like)

Free form linguistic text processing is likely beyond the scope, as both
of these approaches simply deal with the handling of text within the
character set defined for the scheme language itself.

(Personally I see no reason not to consider advocating simply backward
 compatibly extending (string ...) rather than advocating "standardization"
 of a function with limited additional utility which is arguably
 inconsistent with the language's philosophy; but that of course is the
 benefit that the SRFI process/forum provides us all.)

-paul-