public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: Ilia Zaihcuk <zoickx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: pandoc-discuss <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
Subject: Re: Removing parts of the document with [walk] in Haskell
Date: Sun, 5 Sep 2021 08:09:32 -0700 (PDT)	[thread overview]
Message-ID: <1473b62b-4b33-49b5-ac6d-52a5571d8068n@googlegroups.com> (raw)
In-Reply-To: <m2mtorlhoo.fsf-jF64zX8BO0+FqBokazbCQ6OPv3vYUT2dxr7GGTnW70NeoWH0uzbU5w@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 4838 bytes --]

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 
<https://git.sr.ht/~zoickx/pandoc-benchmark>. 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 <zoi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 
> > <https://groups.google.com/g/pandoc-discuss/c/idlbnOk1ooE/m/_QVvaRprHVcJ> 
>
> > 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.

[-- Attachment #1.2: Type: text/html, Size: 7416 bytes --]

  parent reply	other threads:[~2021-09-05 15:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-04 19:09 Ilia Zaihcuk
     [not found] ` <915213fc-e4c4-480b-a6a2-fd3420777ddan-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2021-09-04 19:26   ` Gwern Branwen
2021-09-05  5:23   ` John MacFarlane
     [not found]     ` <m2mtorlhoo.fsf-jF64zX8BO0+FqBokazbCQ6OPv3vYUT2dxr7GGTnW70NeoWH0uzbU5w@public.gmane.org>
2021-09-05 15:09       ` Ilia Zaihcuk [this message]
     [not found]         ` <1473b62b-4b33-49b5-ac6d-52a5571d8068n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2021-09-05 15:42           ` Gwern Branwen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1473b62b-4b33-49b5-ac6d-52a5571d8068n@googlegroups.com \
    --to=zoickx-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).