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