Announcing asciidoc-hs, an AsciiDoc parser in Haskell

Announcing asciidoc-hs, an AsciiDoc parser in Haskell

['Guillem Marpons' via pandoc-discuss]

I'm pleased to finally post here my attempt at an AsciiDoc parser and 
processor in Haskell:

   https://github.com/gmarpons/asciidoc-hs

It is meant to be both a library that some day could be integrated as a 
Pandoc dependency (similarly to commonmark-hs) and a separated executable.

My vision for the executable is that, in addition to generate Pandoc 
JSON, it can be used to generate AsciiDoc (for source-to-source 
transformations) and support other use cases needed by IDEs.

There's still a lot of work to do, but I'm reasonably confident this 
time we can finally get AsciiDoc input support for Pandoc.

I've tried to explain in a blog post the context in which this project 
has been developed (there's an ongoing standardization effort for 
AsciiDoc), the difficulties I've found, and how I've resolved them:

   https://www.tweag.io/blog/2021-06-15-asciidoc-haskell-pandoc/

Contributions are very welcome!

--
Guillem

Re: Announcing asciidoc-hs, an AsciiDoc parser in Haskell

[John MacFarlane]

This is exciting news, and I look forward to seeing this develop!
It would be great if the library allowed us to integrate asciidoc
reading directly into pandoc, and I'd be happy to help with any
pandoc integration questions.

One issue concerns includes.  The pandoc readers are
parameterized on any instance of PandocMonad, so they can be
run either "pure" or in an IO context.  PandocMonad provides
an abstraction for reading from the file system -- an ersatz
file system is used in "pure" instances.

So, for purposes of eventual integration in pandoc, it would be
great if your library was compatible with this (rather than,
e.g., exporting a parser that requires MonadIO).

"'Guillem Marpons' via pandoc-discuss"
<pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> writes:

> I'm pleased to finally post here my attempt at an AsciiDoc parser and 
> processor in Haskell:
>
>    https://github.com/gmarpons/asciidoc-hs
>
> It is meant to be both a library that some day could be integrated as a 
> Pandoc dependency (similarly to commonmark-hs) and a separated executable.
>
> My vision for the executable is that, in addition to generate Pandoc 
> JSON, it can be used to generate AsciiDoc (for source-to-source 
> transformations) and support other use cases needed by IDEs.
>
> There's still a lot of work to do, but I'm reasonably confident this 
> time we can finally get AsciiDoc input support for Pandoc.
>
> I've tried to explain in a blog post the context in which this project 
> has been developed (there's an ongoing standardization effort for 
> AsciiDoc), the difficulties I've found, and how I've resolved them:
>
>    https://www.tweag.io/blog/2021-06-15-asciidoc-haskell-pandoc/
>
> Contributions are very welcome!
>
> --
> Guillem
>
> -- 
> 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/1cee20e4-c8f5-9f6f-9903-a2ae35c1dc28%40mailbox.org.

Re: Announcing asciidoc-hs, an AsciiDoc parser in Haskell

['Guillem Marpons' via pandoc-discuss]

Thank you, John!

El 16/6/21 a las 17:01, John MacFarlane escribió:
> 
> One issue concerns includes.  The pandoc readers are
> parameterized on any instance of PandocMonad, so they can be
> run either "pure" or in an IO context.  PandocMonad provides
> an abstraction for reading from the file system -- an ersatz
> file system is used in "pure" instances.
> 
> So, for purposes of eventual integration in pandoc, it would be
> great if your library was compatible with this (rather than,
> e.g., exporting a parser that requires MonadIO).

I'm more than willing to make the changes needed to integrate with 
Pandoc-the-tool, when time arrives, and start planing for it. In fact, 
it seems that PandocMonad implements a lot of the functionality needed 
for AsciiDoc include/image/whatever expansion.

Now, is there some example of reader implemented as external library 
that needs access to included files? It seems to me that the easiest way 
for a library to integrate with PandocMonad would be to put the class in 
a different package that the library (asciidoc-hs in this case) could 
have as a dependency. Is there another way? What I understand is that 
readCommonMark[Body] calls to a pure parser defined in package 
commonmark, am I right? But it's not possible for the AsciiDoc parser to 
be pure.

--
Guillem

-- 
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/c4d2a88d-2edc-ef8c-5db4-dcf87353d634%40mailbox.org.

Re: Announcing asciidoc-hs, an AsciiDoc parser in Haskell

[John MacFarlane]

"'Guillem Marpons' via pandoc-discuss"
> El 16/6/21 a las 17:01, John MacFarlane escribió:
>> 
>> One issue concerns includes.  The pandoc readers are
>> parameterized on any instance of PandocMonad, so they can be
>> run either "pure" or in an IO context.  PandocMonad provides
>> an abstraction for reading from the file system -- an ersatz
>> file system is used in "pure" instances.
>> 
>> So, for purposes of eventual integration in pandoc, it would be
>> great if your library was compatible with this (rather than,
>> e.g., exporting a parser that requires MonadIO).
>
> I'm more than willing to make the changes needed to integrate with 
> Pandoc-the-tool, when time arrives, and start planing for it. In fact, 
> it seems that PandocMonad implements a lot of the functionality needed 
> for AsciiDoc include/image/whatever expansion.
>
> Now, is there some example of reader implemented as external library 
> that needs access to included files? It seems to me that the easiest way 
> for a library to integrate with PandocMonad would be to put the class in 
> a different package that the library (asciidoc-hs in this case) could 
> have as a dependency. Is there another way? What I understand is that 
> readCommonMark[Body] calls to a pure parser defined in package 
> commonmark, am I right? But it's not possible for the AsciiDoc parser to 
> be pure.

One idea would be to use a custom typeclass instead of using
MonadIO.  Something a bit like PandocMonad, with a pure instance
and an IO instance.  Say you call it AsciidocMonad. Then hooking
up your library to pandoc would just be a matter of defining

    instance AsciidocMonad m => PandocMonad m

-- 
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/m21r8z14wp.fsf%40MacBook-Pro-2.hsd1.ca.comcast.net.

Re: Announcing asciidoc-hs, an AsciiDoc parser in Haskell

['Guillem Marpons' via pandoc-discuss]

El 18/6/21 a las 19:03, John MacFarlane escribió:
> "'Guillem Marpons' via pandoc-discuss"
>> El 16/6/21 a las 17:01, John MacFarlane escribió:
>>
>> Now, is there some example of reader implemented as external library
>> that needs access to included files? It seems to me that the easiest way
>> for a library to integrate with PandocMonad would be to put the class in
>> a different package that the library (asciidoc-hs in this case) could
>> have as a dependency. Is there another way? What I understand is that
>> readCommonMark[Body] calls to a pure parser defined in package
>> commonmark, am I right? But it's not possible for the AsciiDoc parser to
>> be pure.
> 
> One idea would be to use a custom typeclass instead of using
> MonadIO.  Something a bit like PandocMonad, with a pure instance
> and an IO instance.  Say you call it AsciidocMonad. Then hooking
> up your library to pandoc would just be a matter of defining
> 
>      instance AsciidocMonad m => PandocMonad m
> 

Yes, this could work. Most of the functionality in 
AsciidocMonad/PandocMonad instances will be replicated, and in the long 
run we could look for different package boundaries that avoid the 
redundancy. But for now I think it's a good starting point and a 
feasible path for integration. Thanks!

--
Guillem

-- 
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/affe5bc0-6627-6edd-48a7-7863c13529c3%40mailbox.org.