This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
On Mon, Jul 28, 2003 at 05:53:41PM -0700, Jim White wrote: > scgmille@xxxxxxxxxxxxxxxxxx wrote: > >On Mon, Jul 28, 2003 at 11:23:42AM -0700, Jim White wrote: > > > >>I have a second thought that addresses my concerns: > >> > >>collection-fold[-keys]-left and collection-fold[-keys]-right are not > >>specified with regard to the order of enumeration. For unordered > >>collections, collection-fold-right the implementation may either raise > >>an error or provide an enumeration in reverse order or > >>collection-fold-left. > > > >In other words, collection-fold-right is undefined on unordered > >collections. > > It puts it in the same class as what the current document says about > (in)stability and enumeration with respect to mutation. > > I think that collection-fold-right should be defined, but it is > permitted to raise an error if not supported. Thats what I meant by undefined, that its behavior is undefined. > > > >I like this proposal, but how does it address your enumeration stability > >concerns? > > You raised the possibility that an enumeration might not even be stable > for a single enumeration. I agree that that is a plausible scenario. > But it conflicts with this in the current document: > > >Enumeration Stability > >... > >Note that if a collection is purely functional, it will by > >definition be stable in enumeration, as the modified collection > >will be space-distinct from the enumerated collection. > > The ones that especially have this problem are collection-fold-left and > collection-fold-right. I wanted them to be defined as being reverses > (whenever reasonable). But if we can't rely on an enumeration to > complete even without mutation (say because of side effects such a GC, > file i/o, or what-have-you), then clearly I can't expect that what I get > for two enumerations to be the same. Well, thats a bug in the spec. Enumerations should be stable during the enumeration at least. They need not be stable between iterations. I can see though that thats a line in the sand, and that it may be better to just specify stability without update. > I do think that if an enumeration is begun, but cannot be continued for > any reason (say because of that GC which reordered things) that it must > raise an error (as you defined in the mutation/stability section). Sure. I'd like to hear some other opinions one way or the other. (hint hint) > -- > "I love deadlines. I love the whooshing sound they make as they fly by." > -- Douglas Adams How appropriate. ;) Scott
Attachment:
pgpCaEXKGVyKo.pgp
Description: PGP signature