Using rib with my own parser - Rib

so, for this project I am trying to build

it does seem like asciidoc is unsuitable, it doesnt have a good way to "embed" xml tags

which is fine, i can just use my own xml thing anyway

I could do like +++<my-tag>+++, have some other content, and end it with +++</my-tag>+++

but that just seems horrible

I find asciidoc's built-in syntax to be good enough. Is there anything you plan to define in XML that is not possible to do in asciidoc?

The other shortcoming of asciidoc is you won't get a Haskell parsed data-type, if we shell-out to its ruby html generator

Alternatively: perhaps asciidoc can be included in your xml markup?

So parts of your xml doc gets parsed with asciidoc, while you retain control over the rest of it

yeah, this is kindof what I was thinking of

plain text can be treated as asciidoc or markdown

its the way I have things working in pollen

actually, now that I think about it, I think i don't have markdown w/ pollen, just some subset of things I want are built in to the markup (e.g. double newlines -> paragraphs

So, as far as I can tell, I will have to modify rib itself, i can't just implement my own IsMarkup thing

Yes, but the only modification you need to do is to add a constructor to the Markup type. This is something we can obviate by improving the API.

cool!

Would it be worth it for me to try to figure it out?

Assuming you are using the master branch (and not one on Hackage)

Sure; I'm here to help

This type basically https://github.com/srid/rib/blob/master/src/Rib/Markup.hs#L26-L28

You'd add a constructor like Markup_MyXmlThingy :: Markup MyXmlDoc

(in addition to writing an instance for IsMarkup MyXmlDoc)

See https://github.com/srid/rib/blob/master/src/Rib/Markup/MMark.hs for an example. That adds mmark support.

Tomorrow I'll figure out if there is a way to obviate it. But meanwhile you may just modify rib ...

The only reason the Markup doc type exists is to build the patterns dict for passing to buildHtmlMulti.

well what I meant was figuring out how to get rid of it

        Rib.buildHtmlMulti patterns $
          renderPage . Page_Doc
    -- File patterns to build, using the associated markup parser
    patterns =
      Map.fromList
        [ ([relfile|*.md|], Some Rib.Markup_MMark)
        ]

That tells the function, "yea, build *.md files using this markup parser"

(the need to modify RIB itself)

sure

:thumbs_up:

id def prefer to adoid having my own fork for long

question @Sridhar Ratnakumar does the desire I am describing ring true for you too? (that is, writing in an extensible markup language)

Perhaps buildHtmlMulti can take the IsMarkup constraint, and then you call it multiple times, one for each markup type:

mdPages <- buildHtmlMulti @MMark [relfile|*.md] ...
xmlPages <- buildHtmlMulti @MyXmlType [relfile|*.xml] ...
let allPages = mdPages <> xmlPages

its weird to me that it seems like most people do not care about it

im not sure if i'm just a weirdo, or if its like people never think about it, or what

yea thats kinda what I was thinking

I've thought about something like xml. Or yaml. Or even dhall ... as representation of structured data (if not text).

For example, links.dhall - which gets processed and rendered into a page of links.

really the reason I like xml over those options is that i think its a bit more flexible

like, xml already supports e.g. CDATA

If i want to embed something funky, its there

but yeah i'm with you

I just wouldn't want to use xml for formatting text content.

same

But for structured data, it is fine.

One of these days I want to add dhall support.

i mean, something like adding *bold* to the xml processing would go a really long away

during development of rib you may find nix-shell --run ghcid to be handy.

text separated by a blank line to mean new paragraph, etc

cool

And to test your library changes, you can clone https://github.com/srid/rib-sample and run nix-shell --arg rib /path/to/your/rib --run 'ghcid -T ":main serve -p 9876"' (spins up http://localhost:9876). though you'd have to re-run the command after changing rib library.

would it be appropriate to add as ection to the readme

for "developing rib"

ya, good idea

i almost always do that

like for my own stuff

because i freaking forget which version of a command works

for some reason i have a very hard time figuring out the right way to make ghcid do what I want it to do

i almost never have to configure ghcid.

defaults work fine for me

ah

except for the -T argument, which is kind of needed if you also want to run the program in addition to compiling it

ghcid -T "blah" will basically evaluate "blah" in the ghci repl it launches

(right after every successful compile)

liek i had to do this to make the tests run

ghcid -c 'stack ghci joelmccracken-hs:joelmccracken-hs-test' --test 'Main.main'

in this repo https://gitlab.com/JoelMcCracken/joelmccracken-hs

(this is where I was spiking out the xml processing for my xml version to validate i have a path forward)

you could just put those CLI in scripts/myscript

btw, development stuff may instead be added to https://github.com/srid/rib/blob/master/CONTRIBUTING.md

feel free to open a PR, otherwise i'll add it tomorrow

ok

i probably wont start tonight, about to go to bed

and i am going to be afk for a few days

but i might be hacking on it

family time

oh yea, merry christmas! :D

ha ty, i dont celebrate it but we are going to get together as family

Looks like Data.Some and Data.Proxy is coming in handy to achieve this (eliminating need to modify rib)

I'm wondering if the 'meta' from Document meta should be discarded, for simplicity.

@Joel McCracken If you are curious, in particular this commit: https://github.com/srid/rib/pull/65/commits/4f42517abb6d244e51013644cb09a571341c77e7

Actually there are some problems with this. I'll address them.

Looks to be like in the end IsMarkup type class will have only one method left, to parse the file into some type. That's greatly simplifying.

w00t! got dhall version working. both markdown and dhall at same time, without having to change rib

so its interesting, I really don't know if a "metas" section is necessary

meta is gone in the latest PR

https://github.com/srid/rib/pull/65

it is necessary if 1) you need some kind of meta support and 2) your markup doesnt support some kind of metas

nice

instead I exposed metadata functions from MMark.hs and Pandoc.hs that the user can explicitly call if they need to extract meta

excellent

yeah, that sounds good

but how do you handle like

I'm wondering if I can do away with the type class itself, and instead expect just a function Text -> IO a :-)

possibly? hard to say per se

I'm not sure yet; still exploring in code ...

if it were me, given your stated goal, i think what I would do is make handy, discrete functions

that can be combined arbitrarily

not saying you aren't doing that

The document type now looks like this:

data Document repr
  = Document
      { -- | Path to the document; relative to the source directory.
        _document_path :: Path Rel File,
        -- | Parsed representation of the document.
        _document_val :: repr
      }
  deriving (Generic, Functor)

Basically a tuple of filepath and parsed structure. That's the minimum rib will need to pass over to the user.

just like i feel like I am not sure what probelm that typeclass solves

if that makes sense

ahh nice

And type class's responsibility has been reduced to ... basically creating this Document value. That's all it essentially does.

Well , it's a learning process for me - rib being my first haskell library :-D so I'm not surprised to begin from a place of overengineering.

yea

haha

no worires man! its better than my first attempt would be, for sure

anywya, in your case, it would be Document MyXmlType

yea

replacing type class with something like:

type MarkupParser a = forall m b. MonadIO m => Path b File -> m (Either Text a)

wow it actually worked haha

okay, so the shake function will looke like this:

buildHtmlMulti patterns myMarkupParser myPageBuilder

patterns, input function, output function. that's it

It's gone now: https://github.com/srid/rib/pull/65/commits/89f4843676dbf0f10a8e773534761785a814a74f

do you think its stableenough to develop against? i fetched your branch

I think it is nearly done. What do you think of the API? Looking for some final tweaks before I merge.

(One last thing to do before I merge the PR is to update rib-sample)

I don't like "Rib.Markup". Dhall is not a markup. So I'm gonna rename it to something more general. Since there is now Rib.Source (renamed from 'Document', as 'source' reflects its nature more precisely), I'll try Rib.Parser

Okay, branch is stable. Going to test for bugs. Then merge. Here's the user-facing upgrade path you can expect: https://github.com/srid/rib-sample/pull/4/files

In that PR, notice the use of M.parseIO. That's where you would inject your Xml parser function.

@Joel McCracken Everything merged to master!

@Joel McCracken When you get to play with it, I'd be interested in hearing your feedback regarding the SourceReader type. Whether it does what you want re: your xml parsing. Personally I just found that I needed to switch from IO to shake's Action monad, when working with dhall parsing, so I am proposing this change: https://github.com/srid/rib/pull/69

I'm going to work with this today, at least I am planning on it. I'll let you know when I do

I merged this PR. Shouldn't be huge change in the user code. Just replace IO a with Action a in your reader function. And prepend all IO functions with liftIO. Prefer readFile' (from import Development.Shake) when reading some file, as it will track the dependency automatically.

Here's what adding Dhall parser support to a rib-based static website currently looks like :-) https://github.com/srid/website/pull/6/files

I think I'm gonna add that parse function into Rib.Parser.Dhall