I didn't design the API, but my guess would be that re-matcher, re-find, and re-groups are a thin wrapper around what the Java libraries provide in the way of regex matching, and to do so they make the mutable Matcher object visible to the caller. Reimplementing regex matching code from scratch would be a monumental chore.
I suppose one could create a new ImmutableMatcher class that is a thin wrapper around a Matcher, and makes a copy of the mutable state every time you call re-find so that the Clojure code never sees any mutation directly. My guess would be that if such a thing was even considered, it would be rejected as throwing performance on the floor for no significant gain. If you wish to avoid directly touching mutable data in your code, and one of the following functions serves your purpose, all of them are "purely functional at the API level", even though internally they mutate data. By "purely functional at the API level", I mean that the only mutable data accessed by the function is allocated by it, and becomes garbage before the function returns. re-pattern, re-matches, re-seq, clojure.string/replace, clojure.string/replace-first Andy On Nov 14, 2012, at 9:46 PM, Jon Degenhardt wrote: > I've recently been looking at Clojure, still trying to understand the key > ideas. I went to write some regex code, and was surprised to see that > re-matcher returns a mutable object. > > I am curious about this. It could simply be that creating an immutable > version is low on the priority list. Or, it could be that I'm missing > something basic, and if so, it'd be very useful to understand. > > --Jon -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
