From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/29674 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?S=C3=A9bastien_Boisg=C3=A9rault?= Newsgroups: gmane.text.pandoc Subject: Re: Pandoc Document Model in Python Date: Sat, 4 Dec 2021 08:48:58 -0800 (PST) Message-ID: <42a53bd7-98db-4bca-a6c8-d052a03fbf40n@googlegroups.com> References: <3b5d75fe4e2a45e38ab45a820d110faf@unibe.ch> <1e952a20-a77f-4987-9e7f-bac963ba4385n@googlegroups.com> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1546_2038982485.1638636538325" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38370"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBCIOBSUCXMMRB65XV2GQMGQEEUGQK7Q-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Sat Dec 04 17:49:02 2021 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-oo1-f57.google.com ([209.85.161.57]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mtYDd-0009nA-QW for gtp-pandoc-discuss@m.gmane-mx.org; Sat, 04 Dec 2021 17:49:01 +0100 Original-Received: by mail-oo1-f57.google.com with SMTP id r25-20020a4ae5d9000000b002c9ad00c5a5sf4657799oov.22 for ; Sat, 04 Dec 2021 08:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20210112; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=ta1ugT4EQMlXmainZj1j7s4Oe/uyPVwS2aWVZz+s98Q=; b=af1/isTcN+jBf4mI9xq+ergwZjC91ST24Y+bvsXwY2CjaKHbWzlbQYPyRBqv6nGACr dD5DWGRLN1Nxobt+VOT7cm9/QZ6FT8HDMBAWZnIzKNltd/h0Z1yeBN2pQ6cgqk09SOo/ l6OKeG1nN1fB2rKSP0QZbB2SPVLncrkhHqSZWl/uvFKucHiDPucu1rManBKDejyRJ8oN cBtudWpLqMX+jpoUQVM66CmANlPJr0qLMimlvbJz6iNxM/IKWbFbg8ENyZH88YhUQeaU jyyHhReTU86gQV5mNm50QoY9aV8a5a6FXbAFnbpxJpVdAsVCVvbX/UDXIC7fyX2Q/iS9 /C1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=ta1ugT4EQMlXmainZj1j7s4Oe/uyPVwS2aWVZz+s98Q=; b=HqXLnJ7ViNmcfbFDZYetkDYmcKvRZx96ZsnP7/fC5Lqld4Xb9Bw2JrgAY8m4mOr9Bv S5pZO6+Yhi6y920OuCooO3G21lZcSaDJlWRXK+xVPvT1y9LTwSthxeslvzLaC65fpO5u 3kL39TY+eNLBKWKFL+dBJzrN0TH0xp150bkui7esWclhsaBiym+WhfuEuYLGFh0KPbL9 VUmLiSb2oyUkp2NbON1u8LHx2ypqBcmnoVyhQHst2Vkff/IPwpkQyMprTTwFC30f+Xla O6D2T4+09znpQNHtH6gXX0x1mnxBkAufBWRmyt1YJbIys0O9y8tJRNsnXpseC5h5FrOl 6cbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=ta1ugT4EQMlXmainZj1j7s4Oe/uyPVwS2aWVZz+s98Q=; b=ZyZo/ajf5DtN36rMmVcclz3JYJ5pJarJou2EiO5z3FklzE6tW3bTnpEcjNzr6Oz+JX 6G7emcxZjLAH3APQsPGuslDVy0DRxxLWjirLJgi6ivIfuPZhzd8eP7P2SfcJudoVOeqM +1QLAFXSme/Y3VoAYPaiQmIyyxv7W2qwZyV30VtJTbt5m7fmWeY1nPejpmhqBLX3Ahkn P5RiYkGp3jlewH3neJVX8xR764diZIMGZypt2FmvRL073eYvq0XBzd18XHdyKEhjLW20 Aga+UqPzOi/3ujG9satpKdNSGUDVx8gFUxbfMXAn6tE63i+kgXWcHca7H+Ti+oDxuiLy qd1A== Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: AOAM532AzWH0Wz1HKLcEbUHxRwzS08VNNgNHVb0G+w4Xc1xKSTRvI3FD HMhmnJ73yRccQj2aAQI8oEQ= X-Google-Smtp-Source: ABdhPJw3ftDtF9q0i3p1sW9PCdoKWiofVBYlp6OaziEp0jA4QwEEBzsRZ5zgEOu1e/FALFtEaDsC+w== X-Received: by 2002:a05:6808:120b:: with SMTP id a11mr16156193oil.128.1638636540743; Sat, 04 Dec 2021 08:49:00 -0800 (PST) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:a05:6808:209f:: with SMTP id s31ls4760057oiw.8.gmail; Sat, 04 Dec 2021 08:48:59 -0800 (PST) X-Received: by 2002:a05:6808:aa7:: with SMTP id r7mr15929257oij.120.1638636538921; Sat, 04 Dec 2021 08:48:58 -0800 (PST) In-Reply-To: <1e952a20-a77f-4987-9e7f-bac963ba4385n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> X-Original-Sender: Sebastien.Boisgerault-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.io gmane.text.pandoc:29674 Archived-At: ------=_Part_1546_2038982485.1638636538325 Content-Type: multipart/alternative; boundary="----=_Part_1547_1990222720.1638636538325" ------=_Part_1547_1990222720.1638636538325 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also don't know if panflute supports pattern matching (not seen any=20 examples in the doc). For example is there a pattern like this one ? >>> doc =3D pandoc.read("Hello world!") >>> match doc: ... case Pandoc(Meta(meta), [Para(inlines)]): ... assert meta =3D=3D {} ... print(inlines) [Str('Hello'), Space(), Str('world!')] Cheers, S=C3=A9bastien Le samedi 4 d=C3=A9cembre 2021 =C3=A0 17:17:46 UTC+1, S=C3=A9bastien Boisg= =C3=A9rault a =C3=A9crit : > To be honest I have not studied panflute in great details (started my own= =20 > project before panflute 1.0 was released when my use case was not covered= =20 > yet). > I guess that there is a lot of common ground here but with different=20 > elements of style, so if you are a happy user of panflute, i don't avise= =20 > you to change.=20 > I'd say that panflute probably feels higher-level (and maybe terser for= =20 > the common use cases ?) and pandoc (Python) more minimalistic and slightl= y=20 > more Haskell-ish. > > Some misc. things I can think of: > > - Pandoc (python) adapts the AST model which is used to the pandoc=20 > version discovered on your system (or to the one you specify),=20 > so you will probably only need a single version of it, even if you=20 > deal with several pandoc binaries. > =20 > - Our hierarchy of classes is automatically generated (from the=20 > registered Haskell type info). So if you know the original data model=20 > ,=20 > then you're already covered.=20 > If you don't know it, it is documented=20 > but you can also=20 > discover it interactively in the Python interpreter (which I like very mu= ch=20 > =E2=9D=A4=EF=B8=8F): > > >>> from pandoc.types import * > >>> Pandoc > Pandoc(Meta, [Block]) > >>> Block > Block =3D Plain([Inline]) > | Para([Inline]) > | LineBlock([[Inline]]) > ... > | Div(Attr, [Block]) > | Null() > >>> Para > Para([Inline]) > >>> Inline > Inline =3D 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 ?= )=20 > and exactly what the trade-offs are in each case. > For example we don't use named arguments for the pandoc element=20 > 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= =20 > > ) > The panflute types have also more methods while ours are rather "dumb= "=20 > (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=20 > run_filter, while our core tool is pandoc.iter, a (top-down,=20 > document-order) iterator. > > - The dynamic type checking of panflute is very nice =F0=9F=91=8D. I do= n't have=20 > 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=20 > , especially the examples of code,=20 > I'd appreciate some feedback about what you like and don't like! > > Cheers, > > S=C3=A9bastien > > Le samedi 4 d=C3=A9cembre 2021 =C3=A0 16:30:46 UTC+1, Joseph a =C3=A9crit= : > >> Can you speak to what the advantages of this would be over panflute?=20 >> >> http://scorreia.com/software/panflute/=20 >> >> On 21-12-04 09:43, S=C3=A9bastien Boisg=C3=A9rault wrote:=20 >> > AFAICT filters are document AST to AST transformations. In this Python= =20 >> library, docs (Pandoc instances) represent this AST, so a typical AST=20 >> (in-place) transform would be:=20 >> > --=20 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 e= mail 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. ------=_Part_1547_1990222720.1638636538325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I also don't know if panflute supports pattern matching= (not seen any examples in the doc). For example is there a pattern like th= is one ?

>>> doc =3D pandoc.read("Hel= lo world!")
>>> match doc:
...     case = Pandoc(Meta(meta), [Para(inlines)]):
...     &n= bsp;   assert meta =3D=3D {}
...     =     print(inlines)
[Str('Hello'), Space(), Str('world!')]=

Cheers,

S=C3=A9bastien
Le samed= i 4 d=C3=A9cembre 2021 =C3=A0 17:17:46 UTC+1, S=C3=A9bastien Boisg=C3=A9rau= lt a =C3=A9crit=C2=A0:
To be honest I have not studied panflute in great details (s= tarted 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 h= ere but with different elements of style, so if you are a happy user of pan= flute, i don't avise you to change.
I'd say that pan= flute probably feels higher-level (and maybe terser for the common use case= s ?) and pandoc (Python) more minimalistic and slightly more Haskell-ish.

Some misc. things I can think of:
=C2=A0 - Pandoc (python) adapts the AST model which is used to = the pandoc version discovered on your system (or to the one you specify), <= br>
=C2=A0=C2=A0=C2=A0 so you will probably only need a single ve= rsion of it, even if you deal with several pandoc binaries.
=C2= =A0
=C2=A0 - Our hierarchy of classes is automatically gener= ated (from the registered Haskell type info). So if you know the o= riginal data model, then you're already covered.
If = you don't know it, it is documented but you can also disc= over it interactively in the Python interpreter (which I like very much =E2=9D=A4=EF=B8=8F):

>&g= t;> from pandoc.types import *
>>> Pandoc
Pandoc(Meta, [B= lock])
>>> Block
Block =3D Plain([Inline])
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | Para([Inline])
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Lin= eBlock([[Inline]])
=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | Div(Attr, [Block])
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Null()>>> Para
Para([Inline])
>>> Inline
Inline =3D = Str(String)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Emph([Inline])
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Strong([Inline])
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | Strikeout([Inline])
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ...
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Note([Block])
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Span(Attr, [Inline])

= =C2=A0=C2=A0=C2=A0 I don't know how the panflute type hierarchy is gene= rated (manually ?) and exactly what the trade-offs are in each case.
<= div>=C2=A0=C2=A0=C2=A0 For example we don't use named arguments for the= pandoc element arguments since there is no such thing in Haskell.
=C2=A0=C2=A0=C2=A0 There are differences such as Para<= span>(Str('eggs')) for panflute but Para([Str= ('eggs')]) for pandoc (Python) (to = compare with the Haskell type info)
=C2=A0=C2=A0=C2=A0 The panflute types hav= e also more methods while ours are rather "dumb" (mere algebraic = data types) which is a matter of taste I guess (?).
=C2=A0=C2=A0= =C2=A0 But overall the (AST) type hierarchy feels very similar.

=C2=A0 - I think that apart from the AST, the core of pan= flute is probably run_filter, while our core tool is pandoc.iter, a (top-do= wn, document-order) iterator.

=C2=A0 - The dynamic= type checking of panflute is very nice =F0=9F=91=8D. 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 fe= edback about what you like and don't like!

Che= ers,

S=C3=A9bastien

Le samedi 4 d=C3=A9cembre = 2021 =C3=A0 16:30:46 UTC+1, Joseph a =C3=A9crit=C2=A0:
Can you speak to what the advantages of th= is would be over panflute?

http://scorr= eia.com/software/panflute/

On 21-12-04 09:43, S=C3=A9bastien Boisg=C3=A9rault wrote:
> AFAICT filters are document AST to AST transformations. In this Py= thon 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 &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@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.
------=_Part_1547_1990222720.1638636538325-- ------=_Part_1546_2038982485.1638636538325--