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

Re: floating point and other comments

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.



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