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