From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/29673 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:17:46 -0800 (PST) Message-ID: <1e952a20-a77f-4987-9e7f-bac963ba4385n@googlegroups.com> References: <3b5d75fe4e2a45e38ab45a820d110faf@unibe.ch> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1196_220966.1638634666215" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14538"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBCIOBSUCXMMRBK5JV2GQMGQE5P67KEY-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Sat Dec 04 17:17:51 2021 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-oi1-f183.google.com ([209.85.167.183]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mtXjS-0003dP-3p for gtp-pandoc-discuss@m.gmane-mx.org; Sat, 04 Dec 2021 17:17:50 +0100 Original-Received: by mail-oi1-f183.google.com with SMTP id r15-20020acaa80f000000b002bcc50ca40dsf4484246oie.5 for ; Sat, 04 Dec 2021 08:17:50 -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=ZpHW03M0hq8bqfMxAxS1QOEXN2yTzinSFMMXVmxvR84=; b=Fub1J2Egev2dT9yzxVzpKyQHH/YlaaF/T6U6BtNt612KUj3FWhNGeKIp4xa1YAYt40 zy1m5sPrrDSLAOnxvsKfnWcNsPWJ6D1nrIlNCvHyQD5Gy86Kg9Z9Wyl3EDeDTUQ2RAZz IDCOemYk+01QotuWEFRgybeudCMsGZJid8Ywo15PO8GM9R52E4MLWEDVjoqxVO0pVx7N bg97jI4YdiF4heZZ8eVEvfqr0AOdXXAH+Ngf7SgutHaTagxfL6wcbSqYh7VeWWPG+yUW Pq2jTH1evnNtn7jF1uOlo/UkwpAHcS8FkuCbHYoQDbiG4tJk9rqPO/7udFACreGt2WRu qt7A== 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=ZpHW03M0hq8bqfMxAxS1QOEXN2yTzinSFMMXVmxvR84=; b=BTcNpFSX8xJshjmmRBLSfLkNmQLakwFemTSTUKB5SYhOXzjLEJAKLfBoSQ7QJB4mVJ HdB7RpKbiw+xY/2umhvfWbk+SpRbcNJk/IeqwaDtEMHz6RaifBTCA5+YR2Ivqn1SMPYY EZv6ICr0naOuug6YSlzLKS1Q6DAflgYI8hBrrEPWk0dZZn15R9XIjqvfSWof8jrAd7mt 36dT32K0szKiib/5mEZsa+awMF2WeaWrMLaKBHFTRHzkkzBj6asMb2k5XNGsNcjwxgYF oBnqMMxcPtmweDZuO97b5bsZClzubTqENA/IeKOB1Gz/evzZWVDW8yUYYa8Lc4YZctsr bf7A== 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=ZpHW03M0hq8bqfMxAxS1QOEXN2yTzinSFMMXVmxvR84=; b=6EQWIB/pGKXFx2+HL2SMXqIcCHlow6hNeHLgjazBoYMJxBnvmAUUtGHx2U2JrptVSG sqNGpQc3K6pWUQ986klTrpxuRSBdyG+leNjKtg+vO0xjWwzoOgS8xwSlZSAyFuR7hIyu AU5ez4Y3A49uy1048dkDcU8Fju3RDGi2PsoBm0lExtnCI0j9NCkPbNx2JdUo2tY+3xdK MXLw6gMKeCLWLSa/4WY38xDoXkPZZ1xECbeoMRplonfCq/xY3M4TNYmT/Pgc9lV9SiEq Pb/CgNd9P+darCn5WMJSvOqWQPB+kAc2LmXt9OGvzcjs13wZQGRHlifRFgYKL+TrkLkJ oA8g== Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: AOAM530+PhXg6C1qiNOCdksgT6ckTEubtpVq1RIcWAFPO2IusAPEUJRV KkrWip/v+PT3DTcdYYG50L4= X-Google-Smtp-Source: ABdhPJzJr9sGjgQ1B8zjdoFYfwiZ0Y1Wx/uKAwjao67vX61OY2JgujUDfdP9P+tXT288XPWO3ubn1w== X-Received: by 2002:aca:b843:: with SMTP id i64mr15857832oif.109.1638634668614; Sat, 04 Dec 2021 08:17:48 -0800 (PST) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:aca:ad44:: with SMTP id w65ls4744334oie.5.gmail; Sat, 04 Dec 2021 08:17:47 -0800 (PST) X-Received: by 2002:aca:b843:: with SMTP id i64mr15857744oif.109.1638634666884; Sat, 04 Dec 2021 08:17:46 -0800 (PST) In-Reply-To: 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:29673 Archived-At: ------=_Part_1196_220966.1638634666215 Content-Type: multipart/alternative; boundary="----=_Part_1197_1548584925.1638634666215" ------=_Part_1197_1548584925.1638634666215 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 the= =20 common use cases ?) and pandoc (Python) more minimalistic and slightly more= =20 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 deal= =20 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 much= =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 don'= t have the=20 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, I'd= =20 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? > > http://scorreia.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 Python= =20 > library, docs (Pandoc instances) represent this AST, so a typical AST=20 > (in-place) transform would be: > --=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/1e952a20-a77f-4987-9e7f-bac963ba4385n%40googlegroups.com. ------=_Part_1197_1548584925.1638634666215 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 cover= ed yet).
I guess that there is a lot of common ground here but wi= th different elements of style, so if you are a happy user of panflute, i d= on't avise you to change.
I'd say that panflute probably fee= ls higher-level (and maybe terser for the common use cases ?) and pandoc (P= ython) 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),
&nbs= p;   so you will probably only need a single version of it, even = if you deal with several pandoc binaries.
 
&= nbsp; - Our hierarchy of classes is automatically generated (from the regis= tered Haskell type info). So if you know the orig= inal 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 Pyth= on interpreter (which I like very much =E2=9D=A4=EF=B8=8F):

>>> from pandoc.types import *=
>>> Pandoc
Pandoc(Meta, [Block])
>>> Block
B= lock =3D Plain([Inline])
      | Para([Inline])=
      | LineBlock([[Inline]])
  &= nbsp;  ...
      | Div(Attr, [Block])
&= nbsp;     | Null()
>>> Para
Para([Inline= ])
>>> Inline
Inline =3D Str(String)
   &n= bsp;   | Emph([Inline])
       |= Strong([Inline])
       | Strikeout([Inli= ne])
       ...
    = ;   | Note([Block])
       | Spa= n(Attr, [Inline])

    I don't know how the= panflute type hierarchy is generated (manually ?) and exactly what the tra= de-offs are in each case.
    For example we don't= use named arguments for the pandoc element arguments since there is no suc= h 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 a= lgebraic data types) which is a matter of taste I guess (?).
&nbs= p;   But overall the (AST) type hierarchy feels very similar.
=

  - I think that apart from the AST, the cor= e 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 =F0=9F=91=8D. I don't have the equivalent (yet) and that can honestly someti= mes be a pain.

If you are a regular panflute u= ser and can have a quick look our docs, especially the examples of code, I'd appreciate some feedba= ck 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=C2=A0:
Can you speak to what the advantages of = this 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/1e952a20-a77f-4987-9e7f-bac963ba4385n%40googlegroups.= com.
------=_Part_1197_1548584925.1638634666215-- ------=_Part_1196_220966.1638634666215--