Sunday, December 10, 2017

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.

Sunday, December 03, 2017

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.

Sunday, November 26, 2017

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 Typeclass 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 almost 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.

Wednesday, October 11, 2017

Declaration Files in TypeScript: An Introduction

This is the first post in what I believe would be a series where I capture some of the things I learned about TypeScript while developing ip-num, a library for working with IP numbers.

Picking up TypeScript, the language, was relatively painless. As it is often said, it is just JavaScript with types right? so how hard can it get?

What was not relatively painless was the "other things" around the language. Things like tooling, the workflow, the configurations etc. Things you need to know before you can actually use TypeScript to make anything useful.

Declarations files were one of such "other things" that introduced some learning curve due to the lack of a clear and comprehensive explanation on it. There is also a lot of dated information due to historical reasons out there, and this adds to the confusion.

tsd you said? what about typings? Or what is the deal with that @typing thing in the node_module directory? How does a GitHub repository called DefinitelyTyped tie into the picture? What role is npm even playing? etc. These were some of the not so obvious things that needed clarification.

This post captures some things I have come to understand regarding declaration files that make them less confusing. Hopefully, someone else who is just starting with TypeScript will find it useful.

If you have some vague idea of how declaration files work and you just need a quick, straight to the point listing of the key concepts and how they tie together? Then head to the Summary section.

For a more expository explanation, do read on.

Friday, September 29, 2017

ip-num 1.0.0 is Released

ip-num, version 1.0.0 is now available.

ip-num is a TypeScript library for working with ASNIPv4, and IPv6 numbers. It provides representations of these internet protocol numbers with the ability to perform various IP related operations with them.

ip-num is released under the MIT license and can be found on Github here. Documentation is here.

The version 1.0.0 signifies a stable, well-tested core that contains minimal abstractions for working with IPv4, IPv6, and ASN.

The Road Ahead.

As the truism goes: software is never done. The version 1.0.0 although a milestone, signifies a beginning more than a completion. That means development does not cease with version 1.0.0 out of the door but will continue. The hope is that the effort will lead to the building of a comprehensive, well documented and intuitive library for working with IP numbers in the JavaScript ecosystem.

So, moving forward, the development efforts will largely be influenced by 3 factors:

  1. Dogfooding I would be working on a project that would be using ip-num. The plan is to have this experience of actually building a product with ip-num shape further design of the API.
  2. Richer IPv6 Support. IPv6 is more than just an increase from 32 bit to 128 bit when representing IP numbers. It offers a lot more semantics and features when compared to IPv4. The plan is to provide support for these unique IPv6 features moving forward.
  3. Continual Improvements. Quick wins, processing of TODO’s, evolving smarter abstraction to capture the domain using TypeScripts functionalities etc. 

If you work in a domain or industry that deals with IP numbers and you building with JavaScript, then do check ip-num out. It is just an npm install ip-num step away :)

Saturday, December 24, 2016

Exploring Currying and Partial Application using Scala


  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
    // 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
    // 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.