Egad!  My brain rotted out on this years ago.  Doing mostly Smalltalk
the last couple of decades.

Amazed you found the right rock to lift to find me.

Anyway,

[A] do whatever makes sense.  MacLisp, and anything pre-R6RS is antique
at this point.

[B] it appears that changing the initial value of last-was-newline to
#true on entry does most of what is desired:
...
              ; format-help main
              (anychar-dispatch 0 arglist #t)
             )) ; end format-help
...

[C] My recollection is that inexact->exact and exact->inexact are also
antique at this point.

Please fix the doc/code/examples to make them useful.  I am no longer
active in this area.

You can change the Copyright (e.g. to yourself, Per Bothner or Public
Domain)

Thanks much,
-KenD

================================================================
On 2020-03-18 16:50, Arthur A. Gleckler wrote:

> Hello, Ken.  I'm wondering whether you'd like to comment on Per's
> comment below about SRFI 48, in particular about the definition of
> freshline.  Since the SRFI was long ago finalized, it's too late to
> change the meaning.  However, if you'd like to add an editorial note in
> the Status section making a recommendation, I would be happy to add it.
>
> Thank you very much.
>
> ---------- Forwarded message ---------
> From: PER BOTHNER <xxxxxx@bothner.com>
> Date: Wed, Mar 18, 2020 at 4:36 PM
> Subject: questionable definition of "freshline" in srfi-48
> To: <xxxxxx@srfi.schemers.org>
>
> I just implemented (import (srfi 48)) for Kawa (partly to try out the
> srfi-64 re-implementation).
>
> In srfi-48 the ~& Freshline escape is defined as:
>
> "output a newline character if it is known that the previous output was
> not a newline"
>
> I think this is backwards.  Common Lisp has:
>
> Unless it can be determined that the output stream is already at the
> beginning of a line, this outputs a newline.
>
> I that is more useful.  It is what Kawa implements - even if you
> (import (srfi 48)):
> I'm not planning on changing Kawa's srfi-48 support to be compatible
> with what I
> think is a broken definition.
>
> Note there are two problems:
> (1) If the previous character is unknown, Common Lisp (and Kawa)
> writes a newline, while the SRFI 48 specification would not.
> (2) If known to be at the beginning of output, Common Lisp (and Kawa)
> would
> not write a newline, while the SRFI 48 specification would.
>
> This is probably not a pure editorial fix.  The specification includes
> an example, which I think
> is wrong in that it writes a newline at the start of the output.
> --
> --Per Bothner
> xxxxxx@bothner.com   http://per.bothner.com/