First off, I think Idris is pretty great. Over the past several months, I've
been thoroughly enjoying reading and working through Type-Driven Development
with Idris, as well as chatting with the community on IRC (#idris on
freenode).

For every MEAP book, Manning provides a forum. To be honest, though I've
partaken in quite a few MEAPs, I've never really participated in the fora. In
the Type-Driven Development with Idris forum, however, I've made a whopping
two posts so far. One was a clarifying question about a possible error in the
text and the other was an answer to a fellow reader's question. My answer seemed
like a good example of how Idris works, so I thought I'd turn it into a blog
post. Here goes.

In this example, we're trying to prove that addition of natural numbers is
commutative, i.e.
\[\forall n,m \in \mathbb{N}\ (n + m \equiv m + n)\]
… which we can express in Idris as follows:

myPlusCommutative: (n, m:Nat) ->n+m=m+n

The type signature for myPlusCommutative can be read as something like, "For
all natural numbers n and m, n plus m is exactly equivalent to m plus
n."

Back in December of 2014, I set up a blog using Ghost and Buster. That was all
fine and good, but left quite a bit to be desired. I'm not a Python user and the
whole workflow was a bit too clunky for my taste.

In July of 2015, I decided to migrate to Jekyll. It's pretty widely used and the
integration with GitHub Pages promised to be smooth and easy. In practice, I
found its workflow to be similarly annoying. Worst of all, it made me install,
write and use Ruby1. What's more, GitHub seems to have a predilection for
breaking things so often and dramatically, that dragon was born.

Learning Haskell has been a fantastic voyage. Although I've not yet used it for
any "real" projects, I'm sold on its expressivity and general
mind-expanding-ness. I had seen Hakyll pop up on my radar a few times and
considered migrating to it for quite a while. Last night, I finally made the
leap. The experience was so great, I can't believe I didn't do it sooner.

From now on2, my blog will be powered by Hakyll. You can find my site.hs,
which will undoubtedly grow and change over time, on GitHub.

Since much of my time these days is spent (or 'writing 'developing
'evangelizing)LFE, it should come as no surprise that I use the rebar3
compiler plugin extensively. In doing so, I noticed it always recompiles every
.lfe file it finds, irrespective of the staleness of the corresponding .beam
file. Having compiled a fair amount of vanilla Erlang via rebar3, I knew it
didn't have to be that way.

To further my quest, tristan__ pointed me to run/7, specifically its use of
[check_last_mod]. Before I forkedlfe-rebar3/compile, it was using run/4,
which does NOT make use of [check_last_mod], hence the unnecessary
recompilation.

After this discovery, I took to #erlang-lisp and tried to figure out why.
Discussing the issue with @rvirding for a few minutes, we decided adding ++*
and having patterns like (++* "prefix" suffix) expand to nested cons-es was
a solid approach.

N.B. In v0.10.1, exp_append/1 had the following clause, commented out.

Rather than take the overly complicated approach of counting and limiting the
number of expanded cons-es and bottoming out to a call to erlang:++, we
decided to keep it simple and just let ++* patterns do their own thing.

Just as you'd expect from Erlang or another Lisp, in LFE, lists are composed of
cons cells and when you use pattern matching to bind the head and tail of a
singleton list, head holds the single element and tail is the empty list.

So, lately I've been getting increasingly into Lisp Flavoured Erlang (LFE). If
you haven't tried it yet, or even if you have, check out the Exercism.io track I
helped organize. My latest endeavour is porting Robert Levy's swiss-arrows from
Clojure to LFE. It's been going well so far, despite having to rename it to
pynchon, since Erlang wasn't down with the hyphenated name and a few people on
the LFE Google group suggested it.