Since joining JUST EAT I have been much more active in attending meetups because our office is walking distance to the *Code Node*. In particular, I have been a regular at Phil Trelford’s F#unctional Londoners group which meets twice a month.

In the last month alone, we’ve been spoiled with Phil’s Random Arts hands-on session and Mathias’s experience report on building the World Bank Facts twitter bot. You see where this is going…

So, combining the inspiration (and code ) from both, I decided to create a twitter bot for generating random arts.

@theburningmonk here you go pic.twitter.com/mFXYklbTVl

— RandomArtsBot (@randomartsbot) January 23, 2016

## Design Goals

I had a few goals in mind when I sat down to write the bot:

- periodically publish randomly generated images (like what the LSystem Bot does for L-Systems)
- support a simple DSL for expressing the maths equations used to generate the images
- allow others to tweet to it in the above DSL and reply with the generated image

## DSL

Let’s start with the AST, the syntax of the DSL is just how we get to the AST. This is an extended set of the expressions that Phil shared with us in his session:

One approach would be to use a natural maths syntax, e.g.

- x + y
- tan y
- cos x * const
- y + sqr x * sin y

The challenge with this approach is to clearly define and correctly support the precedence rules.

Another approach I considered is to use a LISP syntax, e.g.

- (+ x y)
- (tan y)
- (* (cos x) const)
- (+ y (* (sqr x) (sin y)))

This approach is slightly more verbose, but has the benefit of simplicity and precedence is very obvious. It’s also very easy to write a S-Expression parser, which also factored into my decision to go with this approach.

To go from the AST to the S-Expression is super easy, just override the *ToString()* method like this:

Now that the easy parts are done, let’s write a S-Expression parser for our DSL.

Broadly speaking, the two common approaches for writing parsers in F# is to use FParsec or vanilla active patterns. Having imagined how I’d write the parser with both approaches I decided the *FParsec* route is simpler.

The following 25 lines of code would build the foundation for the whole DSL, spend a moment or two to see if you can work out what it’s doing.

OK, going back to the AST, we can break things down into 4 categories:

- primitives :
*x*,*y*, and*cost* - unary functions :
*sin*,*cos*,*tan*,*well*,*tent*,*sqr*and*sqrt* - binary functions :
*add*,*subtract*,*product*,*divide*,*max*,*min*,*average*and*mod* - ternary functions :
*level*and*mix*

In the code snippet above, we first created parsers for *(* and *)*, then parsers for *x*, *y* and *const.* But this line is interesting…

This allows for a recursive parser for our recursive AST (expression is defined in terms of functions, which are defined in terms of expressions, and so on).

For all the unary functions we have right now and in the future, their structure is the same:

( func_name some_expr )

now see how we parse them:

up until the |>> operator we have captured the *Expr* object to invoke *op* with, whatever *op* is.

Interesting, so *op* is **any** function that takes *Expr* as argument. That’s convenient, because every clause of a union type is a function in its own right. For example, in our AST, *Sin* is a function that takes an *Expr* and returns an *Expr*..

Aha, so we can stay DRY and use the *unaryOp*, *binaryOp* and *ternaryOp* functions above to create corresponding parser for the unary, binary and ternary functions in our AST

To wrap things up on the DSL, we have to define the implementation for our *Expr* parser:

The use of the attempt function here is significant here, otherwise, each failed attempt to parse an expression would have consumed the leading parenthesis ‘(‘ and cause all subsequent parsers to also fail.

## What else?

Since I have *“borrowed”* heavily from both Phil and Mathias’s work, much of the building blocks I needed to write the bot was already there. But I also encountered a few new challenges along the way though.

### Random is not threadsafe

When you use an instance of *System.Random* from multiple threads you can mess up its internal state, it’ll then always return 0 which is hardly random at all…

Since I decided to go async from the start I was able to reproduce this problem regularly. The solution was to simply instantiate a new instance of *Random* before I need to generate a new formula or draw another image.

### Formulae are usually too long to fit inside a tweet

The randomly generated formulae are almost always too long and couldn’t fit into a tweet. To increase the chance of generating formulae that are tweet-sized, I limited the max depth of the expression generation logic to 6. For example:

(- (/ (tan (tan (* (tan const) (+ y const)))) (tan (avg (cos (cos const)) (+ (+ const x) (tan x))))) (cos const)) pic.twitter.com/214gR7NEU4

— RandomArtsBot (@randomartsbot) January 24, 2016

Now, roughly around half the generated formulae can fit into the 140 characters limit.

### Many boring images

Another thing that quickly became obvious was that, many of the generated formulae would yield a similar and kinda boring images (mostly a black screen). So, to improve the general quality of the bot’s output, I added another step in the pipeline to inspect the generated bitmap.

For now, this step would filter out images that are mostly a black screen.

### Loopy conversation with another bot

It’s easy to get into a loop between two bots, and so far I have some rudimentary measures in place to stop the conversation. However it is just as likely to prematurely stop the conversation with an innocent user who has made an error in his/her tweet.

There’s still work to be done to find the right balance here, if you’ve got some ideas/suggestions, I’d love to hear about them in the comments below.

### Auto-follow

If someone tweets at the bot then they’re probably showing an interest in it. Let’s auto-follow them, and maybe they’ll follow us back

### Supporting direct messages

Unsurprisingly, after a few people became aware of the bot’s existence I found someone sent direct messages to the bot to see if they can get an image back via DM as well as tweets. Sadly it’s not yet supported, but it’s a trivial effort to add so expect to see this in the near future.

So that’s it folks, a quick update on what I did last weekend, if you’d like to give the bot a try then feel free to send tweets to @RandomArtsBot. You can find the documentation for the DSL syntax here, or just tweet “help” at the bot.

@matopeto Thank you for your interest, plz see doc : https://t.co/J7s4atoKQk

— RandomArtsBot (@randomartsbot) January 23, 2016

There are also a number of other similar bots that you might like to play around with, for instance, @fsibot, @worldbankfacts, @SpirographBot and @LSystemBot.

**Yan Cui**

I’m an **AWS Serverless Hero** and the author of **Production-Ready Serverless**. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.

Further reading

Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.

- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong