Given the fragility of rewrite rules (and the fact that they don't happen
at all at the default optimization level) that seems too delicate of a
solution to endorse.
That doesn't prevent us from adding the rewrite rules to try to help
existing code that already uses filter (`S.member` set), in addition to
these combinators, though. That idiom is already rather common given the
lack of an alternative to date and improving its performance wouldn't hurt.
-Edward
On Mon, Jul 25, 2016 at 6:05 PM, Joachim Breitner
Hi,
Am Montag, den 25.07.2016, 14:59 -0400 schrieb David Feuer:
Both `restrictKeys` and `withoutKeys` are special cases of `filterWithKey` (although they should be considerably more efficient than implementations using that function).
I’m risking to derailing this discussion, but how viable would it be to *not* add a new exported name for this, but recommend (e.g. in the docs) to use
filter (`S.elem` set) map
and then rely on rewrite rules to get the desired performance effect (by rewriting this expression to an non-exported restrictKeys)?
I guess the answer is: Not viable enough, because rewrite rules are not applied reliably enough, and because you cannot easily have the effect of a partial "map `restrictKeys`". But nevertheless it is an interesting idea to imagine a programming language where APIs can be minimal, modular and composable without performance penalties.
Greetings, Joachim
-- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries