Email list hosting service & mailing list manager

floating point and other comments Alex Shinn (18 Dec 2003 02:58 UTC)
Re: floating point and other comments Ken Dickey (18 Dec 2003 16:17 UTC)
Re: floating point and other comments Alex Shinn (19 Dec 2003 01:55 UTC)
Re: floating point and other comments Ken Dickey (20 Dec 2003 02:34 UTC)
Re: floating point and other comments Alex Shinn (20 Dec 2003 08:56 UTC)
Re: floating point and other comments bear (20 Dec 2003 19:00 UTC)
Re: floating point and other comments Alex Shinn (22 Dec 2003 02:16 UTC)
Re: floating point and other comments bear (23 Dec 2003 02:01 UTC)
Re: floating point and other comments Alex Shinn (23 Dec 2003 04:38 UTC)
Re: floating point and other comments Ken Dickey (22 Dec 2003 02:56 UTC)
Re: floating point and other comments Per Bothner (20 Dec 2003 18:05 UTC)
Re: floating point and other comments Ken Dickey (22 Dec 2003 00:41 UTC)
Re: floating point and other comments Alex Shinn (22 Dec 2003 03:50 UTC)
Re: floating point and other comments Ken Dickey (22 Dec 2003 17:05 UTC)
Re: floating point and other comments Alex Shinn (23 Dec 2003 05:23 UTC)
Re: floating point and other comments Alex Shinn (23 Dec 2003 05:26 UTC)

Re: floating point and other comments Ken Dickey 21 Dec 2003 15:45 UTC

On Saturday 20 December 2003 07:05 pm, Per Bothner wrote:
> I think an "intermediate format" that doesn't support "~8,2F" is
> missing the boat.

Despite the name "intermediate", I consider the srfi-48 level of format to be
basic support in any Scheme runtime.  Admittedly, I am biased toward small
runtimes, including embedded implementations--Scheme in a doorknob with led
display or in real-time robotics (e.g. BIT, Scheme48).

For runtime routines I like to see
  [1] no consing--bounded stack use, no heap allocation (if not output to a
string)
  [2] no assignment = no side effects
  [3] a small amount of code which carries its weight

[1] I will claim without proof that
	(display (number->string <num> <radix>) <port>)
can be replaced by a function
	(display:number->string <num> <radix> <port>)
which does not allocate heap storage and uses a bounded, calculable stack
space.

[2] The reference implementation does no assignments

[3] The complied reference implementation is compact:
	mit-scheme  format.com    8864 bytes  -- bytecode
	gambit         format.so     16448 bytes -- cross-compiled to C

I have not done the work, but it I would guess that supporting ~w,dF would at
least double the size of the reference implementation.  Looking at the ~F
section in the CommonLisp Hyperspec, I likewise suspect that specifying the
complex, rational, rounding, and error conditions would double the size of
SRFI-48.

Given this amount of effort, I would add ~W for writing circular structures,
~H for help (summary line, comment line, one line of text per option, staring
with the option), and so forth.

I am reluctant to go down this path for (what I see as) such a basic service.
E.g. for use in implementing ERROR.

So the crux of the issue is this.  Would acceptance of the current SRFI-48 be
helpful to the community or not?  Is there enough benefit for the level of
agreement?

Alternately, is there enough benefit from ~F (et al) to mandate inclusion for
a small runtime?

My bias is apparent.

What does the Scheme community think?

-KenD