Thanks for the detailed replies! The trick with using Span is neat, although it does seem more like a workaround than a true solution - it *is* making additional changes to the AST after all. Can I be sure that they won't influence my output in unexpected ways? (e.g. some obscure issue like auto-hyphenation in LaTeX, page breaks, etc.) @jgm, I don't really care about performance that much in my application, but I did do some benchmarking by your suggestion: here's a separate repo . This is actually my first ever encounter with the GHC profiler, so it's rather crude. Do let me know if you'd like any more info. TLDR: it does look like using the Span trick is more performant than concatMap (%time 0.8 vs 0.9), while the number of invocations of the base function (theFine in my original example) remains perfectly unchanged. @gwern *> If you do the concat trick, you start running into issues with how the `walk` operates exactly so it'll sometimes repeat operations or omit substitutions you expected to happen, and bottomUp/topDown sometimes cause issues like their own different omissions or just infinite loops (always fun).* This is scary! Correctness is certainly more important than speed. Do you have a concrete example where this issue occurs? If @jgm (the original author of pandoc!) is using this method and there are cases in which it behaves unexpectedly, this sounds worthy of an issue and/or a pull request on GitHub. On Sunday, September 5, 2021 at 8:23:19 AM UTC+3 John MacFarlane wrote: > > I have often used the method > > > allIsFine = walk $ concatMap theFine > > But I don't think this will be any more efficient than your > first version with `walk (filter $ not . isThe)`. > Actually, I'd be interested in seeing benchmarks with these > approaches, if efficiency matters enough to you to research > this more. > > Another possibility is to walk with a function like > > killThe :: Inline -> Inline > killThe (Str "the") = Str "" -- or: Span ("",[],[]) [] > killThe x = x > > This should be more efficient than the list versions, though > again it would be interesting to see benchmarks. > > > > Ilia Zaihcuk writes: > > > Hi all, > > > > Using pandoc-types' Walkable > > < > https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Walk.html#t:Walkable> > > > class, what is the best-performing/most idiomatic way to filter out > certain > > elements from a document? > > > > Say I wanted to remove all occurrences of the word "the" from a Pandoc. > The > > best implementation I've been able to write for this is > > > > isThe :: Inline -> Bool > > isThe (Str "the") = True > > isThe _ = False > > > > removeThe :: Pandoc -> Pandoc > > removeThe = walk (filter $ not . isThe) > > > > Is this right? Does the use of filter here not mean an additional O(n) > > traversal happens on every list of Inlines? > > > > I feel like a better solution for this would be using > > > > filterThe :: Inline -> [Inline] > > filterThe (Str "the") = [] > > filterThe x = [x] > > > > or something similar, but of course > > > > removeThe = walk filterThe > > > > does not typecheck. We need a -> a, meaning [Inline] -> [Inline] here. > > > > > > The same question actually applies to any transformation which "changes > the > > number of elements": > > > > theFine :: Inline -> [Inline] > > theFine (Str "the") = [Str "the", Space, Str "fine"] > > theFine i = [i] > > > > allIsFine :: Pandoc -> Pandoc > > allIsFine = walk $ concatMap theFine > > > > Best, > > > > Ilia > > > > P.S. Sorry if this has been asked before. I feel it must be a common > issue, > > but all I've been able to find is this thread > > > > > with its links, which are 7 years old now and seem to be calling for > > changes in pandoc. Everything else suggests stepping outside Haskell. > > > > -- > > You received this message because you are subscribed to the Google > Groups "pandoc-discuss" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To view this discussion on the web visit > https://groups.google.com/d/msgid/pandoc-discuss/915213fc-e4c4-480b-a6a2-fd3420777ddan%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/1473b62b-4b33-49b5-ac6d-52a5571d8068n%40googlegroups.com.