Guile Haunt configuration with little markdown parser

[Amirouche Boubekki]

Héllo,

I pleased to share with you the haunt [1] configuration I use for my 
english only blog [2]. It includes an implementation of little markdown 
parser powered by a parser combinator. Everything is in the file, so you 
should just drop the haunt.scm file somewhere and run it with haunt.

An article must look like what follows:

----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8

title: Do It Yourself: a search engine in Scheme Guile
date: 2015-09-20 13:00

I don't have the prentention to know all of those but with a help of 
background
knowledge, [NLP coursera](//class.coursera.org/nlp/lecture)
and [another description of a search 
engine](//aakashjapi.com/fuckin-search-engines-how-do-they-work/)
I will try to buiolg *ahem* build and blog about a **search engine** 
mocking
the different parts and hopefully make a proper release at some point.

----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8

The little markdown support:

- metadata in the header via key, value string pair separated by a 
double dot `metadata-name: metadata-value`
- heading via `#` syntax, `#` means h1, `##` means h2 etc.
- inline styles: *italic, **bold** `inline code`
- [links](http://hypermove.net)
- code blocks through the github syntax e.g.

----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8

``` lang
some code
```

----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8----->8

lang must be provided or the parser fails.


Regarding the parser combinator, it's based on 
https://github.com/epsil/gll
without the meoization and continuations stuff. One area that is really 
poor is how the output tree is built. And that's the reason I did not 
port
little markdown parser to guile-parser-combinators [3], both lake a good 
way to build the output tree. guile-log does all this, I did not find 
time to study it more closely.

My dirty explanation of parser combinators is that it's composition of 
procedure that return parser procedure ie. (some-parser input-stream) so 
they are parser functors. A parser can fail or succeed.

Those functor are composed using **control** procedures called 
combinators. Those combinator are split into two categories:

- single step combinators e.g. and, or, maybe, not, alt/any
- multiple step combinators e.g. seq/each, many/zero-or-more (star 
glob), one-or-more (plus glob)

E.g. (many (parse-string "guile")) will parse as many "guile" token 
there is in the input stream and step in the stream as many times so the 
next parser will reads things that are not "guile". Whereas (not (and 
(parse-string "love") (parse-string "like"))) will parse any token that 
is neither "love" or "like" but only consume one token in the stream.

There is actually no magic, on how parser combinators can parse diverse 
kind of grammars, it's only because they do try every parser and 
backtrack when it fails. It possible to backtrack without using call/cc 
because of the use of persistent data structure. This makes me think 
about minikanren.

Anyway! Happy hacking!


Amirouiche aka. amz3

[1] http://haunt.dthompson.us/
[2] http://www.hypermove.net
[3] https://git.dthompson.us/guile-parser-combinators.git

haunt.scm
Description: Text document