Shorthand procedures? scgmille@xxxxxx (28 Jul 2003 15:29 UTC)
Re: Shorthand procedures? Jim White (28 Jul 2003 18:11 UTC)
Re: Shorthand procedures? scgmille@xxxxxx (28 Jul 2003 19:37 UTC)
Re: Shorthand procedures? Jim White (28 Jul 2003 18:22 UTC)
Re: Shorthand procedures? scgmille@xxxxxx (28 Jul 2003 18:55 UTC)
Re: Shorthand procedures? Jim White (29 Jul 2003 00:52 UTC)
Re: Shorthand procedures? scgmille@xxxxxx (29 Jul 2003 03:11 UTC)

Re: Shorthand procedures? scgmille@xxxxxx 29 Jul 2003 03:03 UTC
On Mon, Jul 28, 2003 at 05:53:41PM -0700, Jim White wrote:
> xxxxxx@freenetproject.org 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