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