Ristex 0.1.0 Released

At about 11:46 pm, I got version 0.1.0 of Ristex released to Maven central. This marks the first Scala library I would be releasing! Yay!! 🎉

It should now be available for inclusion with the following sbt configuration:


// ${version} = 0.1.0
libraryDependencies += "io.geekabyte.ristex" %% "ristex" % "${version}"


And by the way, the release process was not as painful as I envisaged. Read further, for my thought on this.

What is Ristex

Ristex is a parser combinator library for parsing the RIR Statistics Exchange files. In theory it should work with the files published by all regional internet registry, in practice, it has only been used with files published by RIPE NCC.

Ristex uses Atto, which is a compact, pure-functional, incremental text parsing library for Scala. Infact, Ristex essentially extends Atto to cater for parsing the RIR Statistics Exchange files, and it makes no attempt to abstract it away, hence all of Atto's API are directly available for use with Ristex.

The idea for Ristex came up when I started working on a fun project to create a JSON format for the CSV like format of the RIR Statistics Exchange files. While working on this, it became apparent that it would be good to have a nicer way to parse the exchange files instead of relying on regex. And since I have always wanted to explore the idea of Parser Combinators in general and the Atto library in particular, it took little persuasion to temporarily shelf the project to create a JSON format, and create a parser combinator library to parse them instead.

Releasing to Maven Central Via SBT

Releasing the library to maven with sbt was relatively painless. I was expecting it to be much of a frustrating experience but I was pleasantly surprised. I guess having previously documented How To Publish Software Artifacts To Central Repository, also helped.

I found this post: An in depth guide to deploying to Maven Central with sbt by Leonard Ehrenfried to be particularly helpful.

The only snag I encountered was related to getting the PGP key published to a public key server. For reasons I still do not know, running the command:

`pgp-cmd send-key ${keyname} hkp://pool.sks-keyservers.net` 

as specified in the post above was not working. This caused the release process to fail a couple of times since maven could not verify the integrity of what was being published.

I had to result to manually uploading the PGP key using the web interface provided by https://pgp.surfnet.nl/. Apart from this, everything went smoothly.

Anyways, the source of Ristex is available on Github, so do feel free to poke around!

Musing on Monad Transformers (II)

Musing on Monad Transformers (II)

Easing Into Cats, And The Case For Category Theory Inspired Abstractions

Cats is a lightweight, modular, and extensible library for functional programming in Scala. On its website, it is stated that the name “cats” is a playful shortening of the word, category - so it has nothing to do with the animal: cat (if you ever wondering), but with category theory :)

It is a library that I have personally found to be helpful in making functional programming in Scala less confusing. It does this by being more concrete and more obvious with regards the various patterns and abstractions that arises from a valid logical conclusion of programming with functions in a statically typed language that has higher-kinded types.

Unfortunately, due to the relative unfamiliarity with functional programming and the various abstraction that comes with it, the Cats library is usually approached with hesitation amongst a sizable amount of software developers.

The sentiments I have seen expressed directly or indirectly is that introducing Cats would inadvertently fling developers into the deep ends of various unknown, academic and good for nothing, category theory inspired abstractions, that only confuses and add complexity. Since nobody wants this, the decision usually gets made not to bother with a library like Cats.

Nothing can be farther from the truth.

Musing on Monad Transformers

Musing on Monad Transformers

Rolling Your Own Monad To Deal With Nested Monads In Scala

In Thoughts On Working With Nested Monad Within The Future Monad In Scala, I wrote about how nested contexts (or technically accurate: nested monads) usually end up creeping into any Scala codebase. And how these nested contexts end up leading to unwieldy code base, that is hard to read and hard to work with.

In that same post, I then mentioned two techniques that can be used to regain readability when dealing with such nested monads. Since the post used the Future Monad as its focus, the first suggested technique was to encode the failure in the Future. The second technique was to use monad transformers.

The blogpost inspired a talk that I gave at the Amsterdam Scala Meet-up group. (You can find the slides from that talk here by the way). In the discussions that ensued after the talk, Devlaam suggested an alternative technique for dealing with the situation: which is to basically create a monadic structure that wraps around the value in the nested context.  Doing this would allow us to regain readability by being able to use for comprehensions with the created monadic structure.

In this post I explore how the idea of rolling your own monad can be applied as a third approach to dealing with the clunkiness of working with nested monad in Scala. Just as with the previous post, Future[Either[E, A] would be the nested monads that would be used for illustrations.

Thoughts On Working With Nested Monad Within The Future Monad In Scala

This post is about nested contexts, specifically with Future, or more accurately, nested monad within the Future monad. eg: Future[Either[E, A]], Future[Option[A]] etc. And how such nested context could easily lead to hard to read and hence hard to maintain codebase.

These sort of context nesting and its impact is not limited to Future, but I would be using Future as the reference in this post, strictly because they seem to be the form that appears the most in a particular Scala codebase I work on at my day job.

Also in this post, I would use Monad and Context interchangeable to mean the same thing. I would also mention terms like Monads, Monad Stack, Monad Transformers, or For Comprehension without providing any explanation of these terms. This is because the thrust of this post is not to expound on these concepts but to share some recent thoughts I have been having regarding nested context within Future.

A reader not familiar with these concepts should still be able to follow along though.

An easier way to interpret code blocks and curly braces in Scala

I recently realized a nifty way for reading a particular piece of Scala syntax that has always confused me.

Basically how to interpret code that makes use of curly braces when calling functions with multiple parameter lists or code that makes use of {} in place of () when acceptable.

Basically, code that looks like this:

foo() {
  val a = "Hello"
  val b = "world"
  s"$a $b"
}

or

foo() { (x:Int) =>
  val y = x * 2
  println(s"output is: $y")
}

Or a snippet of code defining a controller method using the play framework:

Action.async(action.parser) { request =>
  Logger.info("Calling action")
  action(request)
}

Or some slightly modified code from a code base at work:

extractActiveMembershipFromRequest(membershipKey) { requesterId =>
...some code here...
}

Or another slightly modified code from work:

secure.hasRequiredRole(user, role) {
submitRequest(user)
}

Exploring Type class in Scala: Conclusion

I remember watching Dan Rosen's excellent video tutorial on Type class in Scala, earlier this year. And I remember understanding what he was saying, but yet, I was not sure If I grokked the concept he was trying to explain.

I understood all the code snippets, I could follow along with the examples but yet I was not sure I was getting it. I could not really appreciate the rationale, it felt as if I was rote learning and after watching that video tutorial, I was not sure if I could think in type classes.

Moreover, the whole machinery he was describing just felt way too verbose. And this feeling was not just exclusive to the video, it was how I felt about almost every blog post on type class in Scala back then.

I have since then realized why I felt this way: I was working with the wrong mental model.

Three Real-world examples of Type class pattern in Scala

In this post, we are going to look at a couple of examples where the type class pattern has been put to use in Scala. This is the sixth post in a series of posts on the Type classes pattern.

This post assumes an understanding of main concepts and terms that come into play when encoding the type class pattern in Scala. If you are new to how type classes are encoded in Scala, then I advise to first read the previous posts in this series. You can do that by starting from the introductory post: Exploring Typeclass in Scala: A knowledge pack

That being said, let us now go ahead and explore 3 examples of the Type class pattern being used in Scala. We start with JSON serialization in the Play Framework.

Common forms of Type class pattern in Scala

This post will explore some of the various forms the type class encoding in Scala can take.

It is the 5th post in a series of posts on type class encoding in Scala. Check the introductory post: Exploring Typeclass in Scala: A knowledge pack, if you want to start reading the series from the beginning.

Typeclass is not a native language feature but a pattern in Scala, which might make it hard to easily spot when used in a codebase. To add to this confusion, there could also be slight variations to the approach taken to encode the pattern in Scala.

Encoding Type class in Scala

This post looks into how to encode the Type class pattern in Scala. It is the fourth post in the Type-class knowledge pack series.

The previous posts in this series covered the various language features of Scala that needs to be understood before approaching how to encode the Type class pattern.  As previously explained, Type class is not a native language features in Scala; it is a pattern that uses other native language features. Thus to be able to reason along with how the Type class is encoded, a good working knowledge of the main language feature that comes into play when encoding the pattern is needed.

Exploring Type Annotations in Scala

Do you come across code like this in Scala: def apply[T <% Mappable[T]](x: T): T or class ReferenceQueue[+T <: AnyRef] { .. } or def setValue[T1 >: T](value: T1): T? code that when you try to decipher, it always seems your brain grinds to a halt and fails to parse what it is seeing? At which point you silently go beserk and swear at this crazy thing called "Scala"?

Ok, take a deep breath. This post is for you. It will teach you what you need to know in other to be able to read and demystify such incantations. A skill that would come in handy when encoding or when reading code that uses Type classes in Scala.

This post is the 3rd post in the Typeclass knowledge pack series. It will take a brief look at types, type constructors, type parameters and the type annotations.

Implicit Scope and Implicit Resolution in Scala

Having a good understanding of implicits is necessary to fully appreciating how the type-class pattern is encoded in Scala.

This is because implicit is one of the core language features of Scala that makes it possible to encode the type-class pattern.

This post would, therefore, explore implicit in Scala with a focus on implicit resolution. It is the second post in the Type class knowledge pack series.

Revisiting Polymorphism: It is more than Inheritance and Subtyping

This post is part of the Type class knowledge pack series in which I explore the pattern for encoding Type classes in Scala. This post will be about polymorphism.

But why Polymorphism you might ask? isn't this series about the Type class pattern? Why do we have a single post dedicated to Polymorphism?

As it turned out, the type class pattern is really just one approach to writing polymorphic code.

And from experience, having a more in-depth appreciation for what Polymorphism is, will go a long way in understanding the why and how of the Type class pattern: which is why, before I go into the actual mechanism of encoding the Type class pattern in Scala, I think it will be of utmost benefit to first explore polymorphism.

Exploring Type class in Scala: A knowledge pack

This series of blog post seeks to provide an exhaustive exploration of the Type-class pattern in Scala.

Aptly described as a "knowledge pack", it won't only touch on the actual mechanism of encoding the type-class pattern in Scala, but it will also explore a bit of the underlining idea behind the pattern and the various language features that come together to make it possible to encode it the way it is done in Scala.

The reason for taking this approach is borne out of my own experience while trying to grok the concept.

I quickly discovered, as anybody new to Scala will do, that the idea of Type classes is widely used in Scala: both in the standard library and in popular third-party libraries. Thus it is imperative to have a good working knowledge of how it works, to be able to effectively use/read code/libraries that make use of the pattern.

Exploring Currying and Partial Application using Scala

tl;dr

1. Currying is different from Partial (Function) Application.
2. In Scala, it is possible to define a function that returns another function which can be called with arguments. Although this might look similar, it is not necessarily the same thing as either Currying or Partial (Function) Application.
3. What is currying? It is a process whereby the multiple arguments required by a function are passed in, one at a time, instead of the typical process of calling the function by supplying all its arguments at once.
   
   

   val volume = 
   (length: Double, breadth:Double, height: Double) => 
                                    length * breadth * height
   
   // called with the required argument at once
   volume(1,2,3) 
   
   // creates a curried version of the function
   val curriedVersion = volume.curried
   
   // with the curried version we can pass in the arguments 
   // one after the other
   
   // pass first argument
   val withFirstArg = curriedVersion(1) 
   
   // and now with second argument
   val withFirstArgAndSecondArg = withFirstArg(2)
   
   // and now with third argument which yields the result
   val volumeValue: Double = withFirstArgAndSecondArg(3) 
   
   

4. Partial Application what is it? It is possible to take a function that expects multiple arguments and pre-fill some of these arguments. Doing this, returns a function that can then be called by supplying the remaining argument(s) that were not pre-filled.
   
   

   val volume = 
   (length: Double, breadth:Double, height: Double) => 
                                    length * breadth * height
   
   // called with the required argument at once
   volume(1,2,3)
   
   // first and second argument pre-filled
   val withFirstAndSecondArgsSet: (Double) => Double = volume(1,2,_)
   
   // now third argument is supplied and result evaluated
   val volumeValue: Double = withFirstAndSecondArgsSet(3)
    
   

5. Currying can then be seen as a specialised outcome of Partial Application. The resulting function of Partial Application can have any number of arguments. With Currying it has to be a chained sequence of functions that take one argument at a time.
6. Currying can also be seen as a sequence of Partial Application where each step involves partially applying only one of all possible arguments defined by the function.
7. Partial (Function) Application is different from partial functions.

Making Sense Of Symbols In Scala's Collections API

Scala comes under a lot of criticism for the leeway it gives to the use of symbols. A criticism I can understand, since if abused, can easily lead to codebases that might be difficult to read at first glance.

But even with that, I still think the criticism is aggrandized, because when it is all said and done, symbols are still very valid and capable tools for capturing and expressing ideas. Especially when they can do so in very crisp and mathematically fashion without introducing the overhead/need for verbal processing.

"But it is almost impossible to google these symbols"! The complaint goes...

True, but when you think about it, this isn't an inadequacy of Scala, but the inadequacy with most search engines and their inability to deal with symbols in search queries.

To deal with this drawback, I have learnt to use http://symbolhound.com/ whenever I hap upon a symbol in Scala which I want to search. Symbolhound.com can deal with special symbols and does not escape them like Google et al. does.

Understanding Implicits in Scala

I knew about the maxim: "Implicits are evil" way before I started learning and using Scala. So by the time I started running into them in codebases, I was already biased. It was thus easier to raise my hands in despair at the "magic" that is implicit and just condemn their existence.

Obviously such a view is not healthy. So I decided to do what any sane human would do: If I am going to continually bitch about something, I should at least know some one or two things about what I am bitching about.

This post captures my understanding of how implicits work in Scala thus far. Not in the sense of how they work at the compiler or implementation level, but how they work in the sense of what they do and how to reason about them when encountered in a codebase.

It is not about when to make the decision to use or not use implicits. Or how to use them "tastefully". My current level of mastery of the Scala language does not permit me to make such pontification. Hopefully in the nearest feature, a post like this would follow.

Should in case you were like me a couple of months back, and just want a clue about what the hell is the magic going on with implicit, then you will find this post useful.

So let us get right to it.