On Mon, Dec 22, 2003 at 09:09:03AM +0100, Ken Dickey wrote:

> A good start.

Ugh, no it wasn't, it was a very sloppy rip-off of my previous code
which introduced several bugs.  The ~A fix was also broken.  I
apologize for the poor code and attach a new version.

> Unfortunately,  the code did not do the whole job.

I don't think anybody has suggested doing the whole job.  This is,
after all, "Intermediate Format."  The problem is choosing the right
balance of features to include in SRFI-48.  I really think ~w,dF
should be included and it does not complicate the code greatly.

> E.g.:

[snip]

All examples work now as you expected, and the code is no larger.  I
specifically don't handle non-numbers for ~F, I'm not sure if we want
to support that.  It also handles complex numbers but we may want to
remove that.

> I am willing to do the work, but I suspect that handling such cases
> would make the code larger--and cons more.

The code only cons' more if you use ~F or parameters.  So if you don't
use the new features it behaves just as it did before.  There are
still no set!s.  ~F is kind of a clumsy (I was too lazy to lookup a
real floating point formatter algorithm :) but I suspect it is more
compact as it is now.  Generally your goals of code space efficiency
and runtime heap efficiency are at odds with one another - better
algorithms tend to be longer.  Specifically you claim
display:number->string can be more efficient than (display
(number->string ...)) but the reference implementation doesn't take
advantage of that.  Which is more important, and does either really
matter for a SRFI?

--
Alex