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)
|
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