I also don't know if panflute supports pattern matching (not seen any examples in the doc). For example is there a pattern like this one ? >>> doc = pandoc.read("Hello world!") >>> match doc: ... case Pandoc(Meta(meta), [Para(inlines)]): ... assert meta == {} ... print(inlines) [Str('Hello'), Space(), Str('world!')] Cheers, Sébastien Le samedi 4 décembre 2021 à 17:17:46 UTC+1, Sébastien Boisgérault a écrit : > To be honest I have not studied panflute in great details (started my own > project before panflute 1.0 was released when my use case was not covered > yet). > I guess that there is a lot of common ground here but with different > elements of style, so if you are a happy user of panflute, i don't avise > you to change. > I'd say that panflute probably feels higher-level (and maybe terser for > the common use cases ?) and pandoc (Python) more minimalistic and slightly > more Haskell-ish. > > Some misc. things I can think of: > > - Pandoc (python) adapts the AST model which is used to the pandoc > version discovered on your system (or to the one you specify), > so you will probably only need a single version of it, even if you > deal with several pandoc binaries. > > - Our hierarchy of classes is automatically generated (from the > registered Haskell type info). So if you know the original data model > , > then you're already covered. > If you don't know it, it is documented > but you can also > discover it interactively in the Python interpreter (which I like very much > ❤️): > > >>> from pandoc.types import * > >>> Pandoc > Pandoc(Meta, [Block]) > >>> Block > Block = Plain([Inline]) > | Para([Inline]) > | LineBlock([[Inline]]) > ... > | Div(Attr, [Block]) > | Null() > >>> Para > Para([Inline]) > >>> Inline > Inline = Str(String) > | Emph([Inline]) > | Strong([Inline]) > | Strikeout([Inline]) > ... > | Note([Block]) > | Span(Attr, [Inline]) > > I don't know how the panflute type hierarchy is generated (manually ?) > and exactly what the trade-offs are in each case. > For example we don't use named arguments for the pandoc element > arguments since there is no such thing in Haskell. > There are differences such as Para(Str('eggs')) for panflute but Para( > [Str('eggs')]) for pandoc (Python) (to compare with the Haskell type info > > ) > The panflute types have also more methods while ours are rather "dumb" > (mere algebraic data types) which is a matter of taste I guess (?). > But overall the (AST) type hierarchy feels very similar. > > - I think that apart from the AST, the core of panflute is probably > run_filter, while our core tool is pandoc.iter, a (top-down, > document-order) iterator. > > - The dynamic type checking of panflute is very nice 👍. I don't have > the equivalent (yet) and that can honestly sometimes be a pain. > > If you are a regular panflute user and can have a quick look our docs > , especially the examples of code, > I'd appreciate some feedback about what you like and don't like! > > Cheers, > > Sébastien > > Le samedi 4 décembre 2021 à 16:30:46 UTC+1, Joseph a écrit : > >> Can you speak to what the advantages of this would be over panflute? >> >> http://scorreia.com/software/panflute/ >> >> On 21-12-04 09:43, Sébastien Boisgérault wrote: >> > AFAICT filters are document AST to AST transformations. In this Python >> library, docs (Pandoc instances) represent this AST, so a typical AST >> (in-place) transform would be: >> > -- 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/42a53bd7-98db-4bca-a6c8-d052a03fbf40n%40googlegroups.com.