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 Alex Shinn 23 Dec 2003 04:38 UTC

On Mon, Dec 22, 2003 at 06:01:12PM -0800, bear wrote:

> Since authoring SRFI-38 I have also thought of things it doesn't
> adequately cover.  But the ones I've thought of are often subtle,
> like the behavior of non-tree-structured data under eval.

That's interesting.  I don't think shared data-structures pose a
problem, but applying an infinite argument list is interesting.
However, since SRFI-38 is specifically about external representations
I don't think it needs to specify eval behavior.  That could be
covered in a future SRFI which perhaps also provides general circular
data structure traversal procedures.

> What specifically would you like to do differently?

One is mostly aesthetic, I really think read/write should handle
circular structures by default.  The same names are used in CL, they
match the format ~W mnemonic, and it just seems right that the
fundamental Scheme read/write operations are the most complete.  I
also fail to see the point of a separate read procedure, since for
non-shared data structures there is no difference and no overhead, and
for shared data structures the difference is between handling them and
signalling an error, which doesn't seem useful.

For write, however, there is significant overhead since you can't
avoid an O(n) lookup table.  If you've built a data structure that
takes up most of your memory you can't call write/ss on it.  So I
provided a non-shared-write (name undecided) which guarantees minimal
space usage.

--
Alex