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

Re: Format strings are wrong

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.

At Sun, 28 Dec 2003 23:52:03 -0500, Taylor Campbell wrote:
> On Dec 28, 2003, at 9:34 PM, Alex Shinn wrote:
> > You can do this with CL format too.


> >                                      Or just FORMATTER.
> ?

For the same reason that Scheme doesn't have FUNCALL.  Think about it.

> Er, please tell me how these differ significantly:
> (format #t
>      "~STRING~ my-local-variable = ~WRITE~; other-variable = 
>    debug-header
>    my-local-variable
>    other-variable)
> (format/port (sequence-formatter debug-header " my-local-variable = "
>                 (write-formatter my-local-variable)
>                 "; other-variable = " (write-formatter other-variable)
>                 (char-formatter #\newline)))


(begin (display debug-header) (display " my-local-variable = ")
       (write my-local-variable)
       (display "; other-variable = ") (write other-variable)

Please stop using FUNCALL, this is Scheme not CL.

The significant differences arise in the fact that the format string
cleanly separates data from logic.  Some advantages

1) As already mentioned, this allows easier runtime/data-driven
configuration.  eval opens up a whole can of worms involving concerns of
semantic errors, runtime speed and space usage, and security concerns.

2) It easier to optimize.  Just as Scheme without call/cc is easier to
optimize.  There are serious advantages to restricted languages when you
don't need anything more complicated.

3) In a localized environment you can fetch the format string above from
a gettext database, far more easily than you can come up with a
convoluted way to fetch alternating sequences of display and write to
act on variable names that are likely to be changed at any time.  You
can change your mind and edit the labels separately, and even give a
file containing the labels to a non-programmer for editing or
translation.  Show me a company providing translation services that will
give you results in terms of consecutive (writes ...) and (displays ...)
and I will show you a very expensive translation company.

... for a start.

> Much of your argument has been about conciseness; by extending the
> names of the formatting routines, you're going to lose a lot of that.

No, only a tiny portion of my arguments are about conciseness.  Ignore
conciseness if it bothers you, I will never mention it again in this