Thinking about it, map! could be implemented by creating and filling in a new Set, then moving the underlying members back to the original Set.
It's kinda kludgy, and wouldn't be any more efficient, but it would allow for a convenient and uniform interface. Thoughts? Andrew, I'll reiterate that a pull request would be very welcome. I think you would find the Set functionality rather self contained, and the map function implementation should be pretty straightforward. Cheers, Kevin On Tuesday, May 13, 2014, Andrew Dabrowski <[email protected]> wrote: > > Given that set replacement is a fundamental mathematical operation (e.g. > it's an axiom of ZFC) I tend to regard an implementation of map as slightly > broken if map( <function>, <set> ) doesn't return a set. I realize though > that unordered collections are unnatural from a computer's point of view. > > I take the point about map!: there is no performance benefit, and so no > reason for it, on sets. I'll just comment that the documentation on map! > doesn't suggest that there any circumstances in which map would work but > not map!. >
