Re: Pandoc Document Model in Python

["Sébastien Boisgérault" <sebastien.boisgerault-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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

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 
<https://hackage.haskell.org/package/pandoc-types-1.22.1/docs/Text-Pandoc-Definition.html>, 
then you're already covered. 
If you don't know it, it is documented 
<https://boisgera.github.io/pandoc/api/#pandoctypes> 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 
<https://hackage.haskell.org/package/pandoc-types-1.22.1/docs/Text-Pandoc-Definition.html#t:Block>
)
    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 
<https://boisgera.github.io/pandoc/>, 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/1e952a20-a77f-4987-9e7f-bac963ba4385n%40googlegroups.com.

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