Xml vs Dhall - Rib

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

Sridhar Ratnakumar

I don't think I'm really happy with Dhall. It seems to be I'd be spending non-trivial time trying to get Dhall syntax right, which means I might as well use Xml (which is more simpler in syntax). With Dhall you also have to define types in Dhall itself, in addition to Haskell types.

Sridhar Ratnakumar

Actually the later is not true if we do this https://github.com/dhall-lang/dhall-haskell/issues/794

Today, I needed to use an Optional on a record with huge type… that I don’t have in Dhall code anywhere. Since Dhall won’t infer a Nothing _ on its own, I need some Nothing ./MyRecord.type. Could t...
Sridhar Ratnakumar

There is also TOML, which has an interesting Haskell library: https://kowainik.github.io/posts/2019-01-14-tomland

Architecture of the bidirectional serialization library with usage of profunctors, GADTs and Monad transformers
Sridhar Ratnakumar

@Joel McCracken What libraries do you use to parse and validate Xml?

Sridhar Ratnakumar

Here's what using Toml in Rib looks like: https://github.com/srid/website/pull/7/files

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Sridhar Ratnakumar

Toml is way better looking than writing Dhall: pasted image

Sridhar Ratnakumar

https://github.com/srid/website/pull/8

GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Joel McCracken

Right now I am just doing manual parsing with xml-conduit

Joel McCracken

i dont personally care if I have the xml -> types mapping done for me, writing my own stuff in this case is OK by me because I know i'm going to want to do a lot of custom stuff

Joel McCracken

ive thought abotu TOML, but for whatever reason it really didnt seem to be what I wanted

Joel McCracken

warning, if you decide to use xml, you are gonna be considered unbearably uncool

Sridhar Ratnakumar

For me types mapping is kind of important, philosophically. I really like tomland's bidirection mapping. Eventually I'd write a sub-command in my static generator, that will generate .toml entries (for new links, whatever) from the values of Haskell types. Neatly formatted too.

Sridhar Ratnakumar

That's what one thing I learned in Haskell, and particularly at Obsidian.

Sridhar Ratnakumar

I would have went with Xml if it had excellent Haskell libraries (with type mapping, that is)

Joel McCracken

So you want automatic bidirectional mapping?

Sridhar Ratnakumar

One directional mapping, definitely. Bidirectional is a nice to have.

Sridhar Ratnakumar

Types should be the boundary between what's on file system, and the code logic in Haskell.

Sridhar Ratnakumar

Once all the data is loaded into memory, my code can just deal with Haskell types instead of having to deal with the underlying file format specifics.

Sridhar Ratnakumar

Aeson is another example of this bidirectional conversion that everyone knows.

Sridhar Ratnakumar

XML is flexible. If there is a notion of 'transformations' ... say you create a special node <footnote> or whatever, and somehow have that translate to custom HTML or whatever ...

Sridhar Ratnakumar

And being able to _reference_ other nodes. So a <footnotes-list> would somehow collect all the footnote tags and list them,

Sridhar Ratnakumar

And someone can embed markdown using its CDATA section if they really want, and still retain control over the rest of the structure.

Sridhar Ratnakumar

Just need a nice Haskell library that does much of this.

Sridhar Ratnakumar

that hxt arrow thing seems to aim to do this.

Joel McCracken

what you're saying is like 100% what I want to do

Joel McCracken

and the reason why i dont like e.g. markdown

Joel McCracken

I dont think it even has to have markdown embedded in CDATA; you could just treat it as text!

Joel McCracken

I dunno, maybe working on a decent aeson-like lib for xml in haskell might be a decent idea

Joel McCracken

I mean, if you are not so opposed to XML, i'd love to haave someone to work on this with

Joel McCracken

BTW so I was thinking more about it, and I think the issue I have with relying on automatic codecs is that I do not necessarily desire to have the things i type so directly tied in to the data model

Joel McCracken

so at that point I have to have serveral data definitions of similar concepts; the one from which the XML is translated, and the one that I want to use in memory

Sridhar Ratnakumar

What sort of data do you plan to represent in Xml? Aside from text content (markdown, etc.) that is.

Sridhar Ratnakumar

On my website, that's site metadata. And a list of links. Perhaps a personal twitter-like as well, in future.

Joel McCracken

well its hard to say; i have several things I want to implement. For example, flexibly linking from one page to subsections in another

Joel McCracken

so for example, something I have already done in pollen is use the aliases thing I mentioned before to make links that are checked at generation time

Joel McCracken

so like i can say that my fp-jargon.xml file can be linked via jargon or fp-jargon

Joel McCracken

HOWEVER I also added a sub-linking funcitonality

Joel McCracken

so that for example within the @glossary{ ... } section, terms can be linked to

Joel McCracken

so i could link to the main page as fp-jargon, but linking to a specific section would be e.g. fp-jargon monads

Joel McCracken

so again like what I WANT to do is have an initial stage where i derive various data from all my site content, but the "link targets" map I would make would NOT be a direct mapping of the XML content; in the future i'd like to definine other things as having the ability to be linked to, too!

Joel McCracken

now if just use dhall to do what you're suggesting, then adding a new term would require me to both add the glossary term in the text and add link metadata via dhall

Joel McCracken

its kindof like lisp; text is data is code is text is data

Joel McCracken

or haskell, where funcitons and data are both first-class

Sridhar Ratnakumar

So you want to be able to use hyperlinks to site content, but have the static site generator verify that those targets exist and are valid, right?

Sridhar Ratnakumar

If using markdown, this would be equivalent to one file referring to a particular section header of another markdown file; and then the static site generator should check these links for validity.

Sridhar Ratnakumar

This "linking between source files, or their section" seems like a nice idea to add to Rib (as long as it doesn't bring back the messy type class, I guess)

Sridhar Ratnakumar

... even if it as trivial a check as scanning for links like [some text](/foo/bar.html#section1) and then ensuring that "section1" ID exists in the HTML generated by a/foo/bar.md

Joel McCracken

yes exactly, you can link to a file/section from any other file/section

Joel McCracken

so yeah you could validate with markdown

Joel McCracken

in pollen i made an @elink[:to "http://theUrl.com"]{ someplace else} thing for external links

Joel McCracken

so i could differentiate which was an internal link and which was external

Joel McCracken

i suppose you could do something like this though by inferring that link should be checked because it is relative

Joel McCracken

but... that still might not be right; again this is why i've chosen to go beyond markdown, its just not extensible in the way I want

Sridhar Ratnakumar

In your specific use case, I can definitely see not having to codify types for all and sundry.

But thinking of it in terms of 'transformations' (a. la. XSLT?) seems useful to me. So you have foo.xml - and you want to 'transform' that to foo.html.

bar.xml would contain a section ref to somewhere in inside foo.xml, and during its 'transformation' to bar.html, that reference too would automatically 'transform' to the corresponding a tag with 'href' whose value would be checked by the transformer to be valid.

Sridhar Ratnakumar

Your XML format would perhaps be a superset of HTML, allowing you to use direct HTML syntax, but also escaping to custom abstractions (which would ultimately transform to HTML) you design

Sridhar Ratnakumar

The HTML5 semantic elements kind of come closer to that design

Joel McCracken

so my plan here is to follow what pollen does (because it works fine), and if I don't have any other behavior specified for an xml element, it just becomes html

Joel McCracken

so if i typed <img src=".../whatr.png" /> and I dont have any special behavior for img, it will get passed through

Joel McCracken

but yeah, a series of transformations is a good model

Joel McCracken

a lot of what i am doing is overlapped by xslt

Joel McCracken

I have no interest in using xslt, and if the kind of behavior I want to implement is actually implementable, i would not want to learn it

Joel McCracken

its still a major wip but it does build

Sridhar Ratnakumar
import Relude (readFileText, fromMaybe)
Sridhar Ratnakumar

Note: you do not necessarily have to use readFileText. prelude's readFile or shake's readFile' work too (but the later is preferred)

Joel McCracken

yeah right now its super inelegant; kinda still in a prototyping phase

Joel McCracken

I usually make a thing work first, then refactor

Joel McCracken

running into a lot of situations where I wish xml were statically typed, and I could assume that for example every <term> element has both <name> and <def> children

Joel McCracken

i wonder if smth like a DTD could be parsed to determine the haskell data for an xml format

Joel McCracken

So, i was talking it over with a buddy of mine and he suggested just using haskell direclty instead of xml

Joel McCracken

and , i sort of prototyped it out, and its not as bad as I thought it would be

Joel McCracken

so i think i'm going to try it

Joel McCracken

ive converted that glossary document I keep using as an example, and given some assumptions, i think i can make it work well

Joel McCracken

ehhh after spending a bit more time, though i really like the idea a lot, its not what I want

Sridhar Ratnakumar

That's what I did as well. Used free monad to make management of data prettier

Joel McCracken

BTW, I will probably be pausing on this project for a couple of weeks. I have some other stuff I need to work on in my free time. but I will certainly be back at it, hopefullly within a month!

Sridhar Ratnakumar

I've decided that it is time to move away from TOML. A flat list of TOML entries a) can grow to be huge, b) not flexible enough (for eg., can't simply represent longform tidbits without hacks). My plan is to migrate links to good ol' markdown files (each link gets its own .md file, with its YAML metadata specifying the link properties). This way if one of the tidbit is a longform post, rather than a link, the very markdown file will specify its content, in addition to a longform property set to True.

Sridhar Ratnakumar

https://github.com/srid/website/pull/13

Also switch from TOML to MMark's projectYaml. migrate rest of tidbits sort in chronological order remove ByAuthor tag (it is implicit)
Joel McCracken

cool; sometimes the best solution is the simplest.

Sridhar Ratnakumar

I went back to Dhall for links! Newer Dhall provides TH for auto generating of Haskell types ... and I'm coming to accept the relative verbosity of Dhall syntax as an acceptable compromise over the benefits. https://github.com/srid/website/tree/a0e8db490c18d3205ea6953568771f4e2e57fb5a/content/tidbits/links

Source for my website. Contribute to srid/website development by creating an account on GitHub.
Joel McCracken

Lol so basically the feature port from pollen to rib/haskell/xml is nearly complete, just a tiny bit remaining. But this code is cursed. I am going to need to ask around for some design advice for sure.

Joel McCracken

I generally vastly prefer porting more code and then cleaning things once i have more examples

Sridhar Ratnakumar

Feel free to ask for any sort of guidance. It would also, indirectly, help me with the guide-like documentation thingy I will be writing for Rib (using neuron, of course)