A simple example of using java builder in a Functional Way!

Problem

Assume you have 2 optional parameters: Maybe(firstName), Maybe(lastName) You want to instantiate (or build an instance of) Name class which is possibly written in Java with these parameters, if they exist (ie; Maybe.Just, or Option.Some).

Ok! Let us try writing it.

  new Name
   .withFirstName(param1.getOrElse(..well I dont know))
   
   
  // Oh! That doesn't work. We could try this 
   val s = new Something
   
   (firstName, lastName) match {
     case (Just(f), Just(l)) => (new Name).withFirstName(f).withLastName(l)
     case (Empty, Just(l)) => (new Name).withLastName(l)
     case (Just(f), Empty) => (new Name).withFirstName(f)
     case (Empty, Empty) => new Name
   }
 

Think of multiple classes similar to Name with multiple (a list of) optional parameters. Now, this is our problem definition. A quick solution would be abstracting out the above function (say f) and fold the list of optional parameters (using f), but that is in fact, discarding the possibility of using a better mechanism provided by Functional Programming paradigm. Below given is one of the solutions. While this may not be the only solution, it is still a cleaner way of solving this problem.

A Solution

State Monad

@   // Assume that Name is not a scala class, and is a Java bean kind of thing ; 
@   // Name.withFirstName("afsal").withLastName("thaj").withBlaBla.withFirstName("changingafsalsname").withLastName("thoughtofchangingitagain")
 
@   case class Name(firstName: String, lastName: String) {
      def setFirstName(newFirstName: String): Name = Name(newFirstName, lastName)
      def setLastName(newLastName: String): Name = Name(firstName, newLastName)
    } 

@   def buildInstance[A, B](a: Maybe[A])(f: B => A => B) : State[B, Unit] = {
      for {
        instance <- State.get[B]
        modifiedInstance <- State.put(a.cata(f(instance)(_), instance))
      } yield modifiedInstance
    } 
    
    

    

@   val initialStateOfName = Name("wrongfirstname", "wronglastname") 

@   (for {
      _ <- buildInstance[String, Name]("afsal".just)(_.setFirstName)
      _ <- buildInstance[String, Name]("thaj".just)(_.setLastName)
    } yield ()).exec(initialStateOfName) 
res44: Id[Name] = Name("afsal", "thaj")

// What if your lastName parameter was Maybe.Empty (Optional `None`)

 (for {
      _ <- buildInstance[String, Name]("afsal".just)(_.setFirstName)
      _ <- buildInstance[String, Name](Maybe.Empty[String])(_.setLastName)
    } yield ()).exec(initialStateOfName) 
res37: Id[Name] = Name("afsal", "wronglastname")


// And a very simple thing to note, our initialState is immutable, it hasn't changed
@ initialStateOfName 
res38: Name = Name("wrongfirstname", "wronglastname")

  
@   // If you know about only firstName, and doesn't know anything about last Name
@   val initialStateOfName = Name("nonafsal", "thaj") 
@   buildInstance[String, Name]("afsal".just)(_.setFirstName).exec(initialStateOfName) 
res35: Id[Name] = Name("nonafsal", "thaj")

I have intentionally avoided the use of State.modify function in scalaz, since it is less expressive at this stage.

If you don’t know State..

You can see some of my code scribblings on State data-type (without scalaz) in the following links. You may read them in its order. The comments in code may give you some idea on what is state data type. That will make you feel comfortable with some notes in scalaz tutorial (Google).

• Part 1
• Part 2
• Part 3
• Part 4

Interface Segregation Principle.

We have heard about this design principle in software development. Let’s get straight into a problem and try and understand what this principle says!

Let us design an ATM (Automated Teller Machine). An ATM has transactions. A transaction can be WithdrawalTransaction, DepositTransaction, TransferTransaction etc. Next, we have a UI for ATM, and UI can be Braille UI, Screen UI and Speech UI. Different transactions can speak to UI methods to publish their message, however, the message might differ based on a transaction. Having a single UI interface having RequestTransferAmount, RequestDepositAmount that can work with all the types wouldn’t be the right solution here. It is because, a type of transaction, say DepositTransaction, can enforce a change to UI interface to add a new functionality, which would further lead to changes in all the other transactions that extended the same UI. In short our the problem is:

“A change in UI for solving a problem withDepositTransaction resulted in changes with TransferTransaction.

It looks like we need a UI for Withdraw, Deposit and Transfer.i.e, DepositUI, WithdrawUI and TransferUI.

First stage of Solution:

• All Transaction classes extend Transactions as expected.
• We have separate DepositUI, WithdrawUI and TransferUI that gets mixed into UI.
• A particular transaction won’t work with UI since it is already fatty. (We call such an interface fatty because not all of these functions would be relevant for a particular implementation. That is, TransferTransaction would have to provide a fake/dummy/empty implementation for RequestDepositAmount if it is extending this fatty interface)
• All transactions can then be provided with its corresponding UI type as given below

Intent of doing this, clients should not be forced to depend on interfaces they don’t use. This is called interface segragation principle

So, here we go: A part of the solution:

interface DepositUI {
    public int requestDepositAmount();
}

interface WithDrawUI {
    public int requestWithDrawAmount();
}

interface UI extends DepositUI, WithDrawUI {
    
}

interface Transaction {
    public void execute();
}

class DepositTransaction implements Transaction {
    private DepositUI ui;

   public DepositTransaction(DepositUI ui) {
        this.ui = ui;
   }
    
   public void someCommonTransactionMethod(){
        // ..some implementation
   }

   public void execute() {
        ui.requestDepositAmount();
    }
}

class WithDrawTransaction implements  Transaction {
   private WithDrawUi ui;

   public WithDrawTransaction(WithDrawUi ui){
        this.ui = ui;
   }

   public void execute() {
     ui.requestWithDrawAmount();
   }
}

This is it!

A few more points to note

You may note that, DepositTransaction must know about DepositUI and Withdraw Transaction must know about WithDrawUI. As you can see, we solved this problem by making the constructor of each type of transaction expecting the right type of UI. We could pass in the UI as given below

class ATM {

   UI gui;  //global object;

   DepositTransaction dt = new DepositTransaction(gui);
}

Another way of handling this problem is to have a global package listing down all types of UIs. i.e, static global objects. Hence we can avoid passing in the UI during the construction of different transactions. However, they are two different approaches that allow us to follow Interface Segregation Principle. Please note that if these globals are put into a class instead of a package, that would be violation of the principle as we are in a way combining all the interfaces together when we import this class to work with a specified transaction. Personally, I would go with the solution given in the above example, that is, pass the right UI to the right transaction.

The polyad and monad - Monadic is not always the best approach

Assume that, We might be in need of a function f that has to access both DepositUI and WithDrawUI. We could separately pass these UIs to f as given below.

  
  f(WithdrawUI, DepositUI)

We made the function polyadic, and passed multiple parameters into it. Let me quote a sentence from the book Clean Code written by Robert.C.Martin here

A function with two arguments is harder to understand than a monadic function. For example, writeField(name) is easier to understand than writeField(output-stream, name). Dyads aren’t evil, and you will certainly have to write them. However, you should be aware that they come at a cost and should take advantage of what mechanism may be available to you to convert them into monads.

In the above example, you might have noted that we are mixing in various UIs to have a UI type. Following the above quotes let us make our function monadic. (You may note that UI in our example is a mix of all interfaces)

  
  f(UI)

Here we made it monadic, however it comes with cost - it drifted us away from following our interface segregation principle. That is, any change in any of the interface affects the function f and all of its clients forcing it to recompile. Hence we prefer polyadic approach here..

State Transformers

What is State transformer and STRef trying to achieve?

• Encapsulating stateful computations that manipulate multiple mutable objects in the context of non-strict purely functional language.
• Once the actions are encoded in ST, that if we try to access a naked mutable object, it throws a compilation error.

Let us define the ST monad (in scalaz). In the simplified form it is,

case class World[A]()

case class ST[S, A](f: World[S] => (World[S], A)) {
  def apply(s: World[S]) = ..
  def flatMap[B](g: A => ST[S, B]): ST[S, B] = ...
  def map[B](g: A => B): ST[S, B] = ....
}
x
def returnST[S, A](a: => A): ST[S, A] = ...

• Monad with unit as returnST and flatMap as flatMap itself.
• The difference between State and State-monad is, the state is mutated in place, and is not observable from outside.
• The World represents some state of the world. (I have tried to use scalaz’s State instead of ST monad (basically, S instead of a World[S]) to solve the same problem, but got stuck in between. If interested, you may have a look at this line of code in my FP exercise repo. implementations)
• It encapsulates a state transformer.
• The contents of the state doesn’t really matter, but the type is (for what we want to do with ST monad - transform the state by mutating objects in place)
• Since type S is unique for a given ST, it is going to be a pure function.

STRef

STRef is a mutable variable (updatable location in the state capabale of holding a value) that’s used only with in the context of ST Monad. And that is, ST[S, STRef[S, A]] `

case class STRef[S, A](a: A) { private var value: A = a

// only path-way to access the value (it will be encapsulated in ST) def read: ST[S, A] = returnST(value)

// associate the new value `a` to this reference. // write mutates the object in place. def write(a: A): ST[S, STRef[S, A]] = ...

// modifies the value at this reference, that is `read` and then `write` def mod[B](f: A => A): ST[S, STRef[S, A]] = ... }

def newVar(a: => A) = returnST(STRef(a))

A simplified version is [here] (https://github.com/afsalthaj/supaku-sukara/blob/master/src/main/scala/com/thaj/functionalprogramming/exercises/part1/PureStatefulAPIGeneric.scala#L243)

Characteristics of STRef in a ST

• Playing around with STRef is going to be easy with the availability of monadic combinators. Have a look at the mod function as an example.
• STRef is type parameterized by type S.
• S represents the state thread that created the reference (STRef) holding a value (updatable).
• A single state thread can’t oversee other state thread, since they are of incompatible types.
• Since state transformers are composed sequentially, it’s guaranteed that both of them won’t mutate the same STRef/mutable-value.

Taking STRef out of ST ? No….

• You shouldn’t separate them.
• All your changes to the mutable value held by STRef, is done through ST (should be done)
• You might wonder, providing an initial value for world, and calling the run function in ST should be give STRef (that’s wrong again)
• Providing an initial state for World[S], sounds right. Scalaz has its implementation here, where it is Tower[A] and providing an IvoryTower as its initial value. https://github.com/scalaz/scalaz/blob/fabab8f699d56279d6f2cc28d02cc2b768e314d7/effect/src/main/scala/scalaz/effect/World.scala (doesn’t really matter)

So what are we trying to achieve?

Exposing STRef by any chance should lead to compile time error, or in other words no freedom to compose STRef by itself without a State thread.

Examples

• i.e, newVar(a).run in scalaz will throw a compile time error.
• newVar(a).flatMap(_.mod(_ + 1).flatMap(read)).run exposes only a and not STRef(a) to the client making it super safe.
• Rank 2 polymorphism technique is used here.

trait Forall[P[_]] { def apply[A]: P[A] }

def runST[A](f: Forall[({type F[S] = ST[S, A]})#F]): A = ... 

Refer to [my project]((https://github.com/afsalthaj/supaku-sukara/blob/master/src/main/scala/com/thaj/functionalprogramming/exercises/part1/PureStatefulAPIGeneric.scala#L243) for further examples, where we try to run the actions in many ways resulting in compile time errors.

General concepts of Symbol

I am writing this with a hope that you would get a wide angle perception on the term “Symbol” in programming. I am deliberately mixing multiple programming languages to make our understanding better, and at-least one of them would make sense to you - if not entirely - intuitively! As you read through, you would discover better reasons on why we use multiple languages to explain this concept.

Before we talk about Symbol….

Before we explain Symbols, let’s get familiarised with the behaviour of strings (instantiation, storage, etc.) in all these languages. let x be "afsal" and it’s a string type (not language specific). x will be allocated a memory space M and is identified by an id (sometimes we call object_id). Invoking x is getting the contents of x identified by id.

Note: Most of you would guess this to be an intro to reference identity, reference equality and related topic. But, for the time being, let us restrict ourselves on to the terminologies mentioned above.

Some code in Python

Let us use Python here as an example of getting the id of a variable. You may not see this feature in all languages. But the concept remains the same.

>>> x = "afsal"
>>> id (x)
4438888640
>>> y = "afsal"
>>> id (y)
4438888640
>>>

String with same contents share same id?

As seen above, the strings with the same content share the same id.

• It means, when we tried to define y with the same content as that of x, the application looked up the heap/memory and identified that y could reuse the contents of x.
• If y needs to re-use x, obvious that they should have the same object_id. id (x) == id (y)
• No extra copy of y is created, and we saved some space.

In Java/Scala?

• In computer science, the behaviour is termed as string interning. That is, internalising the strings will ensure that all strings with same contents share the same memory.
• One source of drawbacks is that string interning may be problematic when mixed with multithreading, but this discussion is out of scope.
• In the above examples with python/ruby, the string x is internalised automatically, so is for Java/Scala. (However, ou will find differences in behaviour across these languages soon)
• In java, String.intern() internalise the strings forcefully, but you don’t do this generally.
• The intern() method returns a canonical representation of the string object.

Again, for demonstration I am using Scala console. I strongly recommend to view this example as a conceptual explanation of String interning, and it doesn’t intend to explain the various functions in Scala/Java and its differences. For the time being, all that you would need to know is eq method in Scala verifies if two strings are pointing to the same memory location.

scala> val x = "afsal"
x: String = afsal

scala> val y = "afsal"
y: String = afsal

scala> x == y
res0: Boolean = true

// `eq` verifies if they point to the same memory.
scala> x eq y
res1: Boolean = true

// In the above example, strings are automatically interned, 

// Now, please have a look at the below examples. You can see strings are not automatically interned here:
scala> val x = new String("afsal")
x: String = afsal

scala> val y = new String("afsal")
y: String = afsal

scala> x == y
res2: Boolean = true

scala> x eq y
res3: Boolean = false


// Let's look at the below example where we intern strings forcefully, resulting in `eq` giving a result `true`

scala> val x = new String("afsal").intern
x: String = afsal

scala> val y = new String("afsal").intern
y: String = afsal

scala> x == y
res4: Boolean = true

scala> x eq y
res5: Boolean = true

Automatic String interning: naive testing in Scala (Skip through if you don’t care)

Let’s do a simple test on the automatic interning of Strings. For simplicity, let’s use Scala console. Let’s create ten strings, each with 10000000 characters of ‘a’. All ten long strings have same contents, and ideally, they should share the same id.

scala> val longString = List.fill(10000000)("a").mkString
longString: String = aaaa..............
scala> val strings = List.fill(10)(longString)
strings: List[String] = List(aaaaaaaaaaaaaa.............
scala> strings.forall(t => t eq longString)
res0: Boolean = true

Is interning a property of Strings?

Yes, it is a property of strings. You won’t find an intern method for an Integer variable. However, you may note that ids are constant for certain primitives. Ex: id of integer 1 is always the same.

Example: In python, it would look like this. You can verify the same in Ruby, and it behaves in the same manner.

>>> x = 12121212121321232432453234123
>>> y = 12121212121321232432453234123
>>> id (x) == id (y)
False
>>> x = 1
>>> y = 1
>>> id (x) == id (y)
True

Is this a consistent behaviour for Strings?

Surprisingly, the answer is NO. In java world, we say there is no guarantee that strings would be internalised and it depends on JVM’s whim, and probably the content itself. Python doesn’t intern strings with special characters for example.

Let’s analyse the consistency of this string interning in back to python/ruby (programming language does matter here). We will come to know String interning, being such a generalised term, behave in different ways in different languages.

In python:

>>> x = "afsal11111111111111111111116789i|dsad!@##"
>>> y = "afsal11111111111111111111116789i|dsad!@##"
>>> id(x) == id(y)
False
>>> x == y
True
>>> x = "afsal"
>>> y = "afsal"
>>> id(x) == id (y)
True

No default string intern in Ruby?

In Ruby, you would see something known as object_id. It is the equivalent of id in python. But as per documentation, the object_ids always differ for 2 active objects. Hence, the following code gives different object_id (or id) for two variables with the same content afsal. There is no string interning happening here!

afsalthaj@Afsals-MacBook-Pro ~> irb
irb(main)> x = "afsal"
=> "afsal"
irb(main)> y = "afsal"
=> "afsal"
irb(main)> x.object_id == y.object_id
=> false

How to intern strings in Ruby?

The answer is “Symbol”. To make it further simpler, call the method intern for a string in Ruby, and you get a “Symbol” in return.

irb(main)> x = "afsal".intern
=> :afsal
irb(main)> x.is_a?(Symbol)
=> true
irb(main)> y = "afsal".intern
=> :afsal
irb(main)> x.object_id == y.object_id
=> true
irb(main)> x = :afsal
=> :afsal
irb(main)> y = :afsal
=> :afsal
irb(main)> x.object_id == y.object_id
=> true

Now you must be wondering, can we solve the intern inconsistencies in any language using Symbols? Yes and No. Yes for languages who has specific Symbol type but we may not always use this in practice, and there are alternative methods in languages that don’t have symbols inbuilt. In other words, even if some languages don’t have the concept of Symbol, they have string internalising, and there is one or other way of doing it. In Ruby/Java/Scala it is done by making use of symbols. In Python, use the method intern, and in Clojure, we could use keywords or symbols. Let us try to understand it better.

Symbol

The concept of symbol is not language specific, but they differ in some or other ways. Let us explore.

Symbol in Ruby

As mentioned in above examples, the way Ruby handles intern is by converting it into symbols. i.e, Symbol representation of String "afsal" is :afsal.

If you are not using symbols, every time you define “afsal”, Ruby instantiates a new String object, interpreter looks at the memory (heap) and allocate a new memory, assign a new object_id to keep track of the object, and interpreter marks it for destruction if not used often, resulting in the repetition of the whole steps next time the String “afsal” is defined. It can affect the performance - especially when it comes to massive datasets.

Some performance comparison:

Let us define a string 100000000 times and similarly a symbol 100000000 times, and see which one performs better:

  def test_strings_performance
    x = Time.now
    100000000.times do
      "afsal"
    end
    y = Time.now
    y - x
  end

irb(main):020:0> test_strings_performance
=> 6.360865
irb(main):021:0> test_strings_performance
=> 6.381256

  def test_symbol_performance
    x = Time.now
    100000000.times do
      :afsal
    end
    y = Time.now
    y - x
  end

irb(main):018:0> test_symbol_performance
=> 3.76367
irb(main):019:0> test_symbol_performance
=> 3.773923

Hurray! symbols are performing almost ~2 times faster than string.

Usage of symbols:

Many times symbols are used as identifiers.Example: Every method name in Ruby is saved as a symbol under the hood. Symbols are widely used as keys in your hash. By using symbols as keys, Ruby need to compare only the object_ids of the already stored key with the new ones, and not its contents/compute-hash-of-each-value. It could be used anywhere with-in your application.

Are symbols always better than strings?

Be aware using excessive use of Symbols results in lots of memory usage. The frequent casting of Symbols to Strings can also slow down your application. Said that memory leakage due to the usage of Symbols is not a concern in Ruby anymore (for version > 2.2) as there is symbol garbage collector now.

Symbol in Python

There is no python equivalent for Ruby’s symbols. However, as you have seen from the above examples, they are interned by default. We have also seen a few examples of strings that were not interned by default in Python. But we can force the intern of those strings using the intern function.

>>> x = "sfbakjdbakjdbajhdbjadbjasbdjad&&&%^&'"
>>> y = "sfbakjdbakjdbajhdbjadbjasbdjad&&&%^&'"
>>> id(x) == id(y)
False
>>> x = intern(x)
>>> y = intern(y)
>>> id(x) == id(y)
True
>>> type(x)
<type 'str'>
>>> type(y)
<type 'str'>

Symbols in Clojure

Clojurists have Strings, Symbols and keywords. This trichotomy may confuse many. It may partly make sense to you as we need String and Symbol.

user=> :afsal
:afsal
user=> 'afsal
afsal
user=> (symbol? :afsal)
false
user=> (symbol? 'afsal)
true
user=>

According to documentation, the one which provides faster equality tests is given by keywords (i.e.,afsal). Also, you may observe that these keywords are not Symbols. As far as I can understand, a Symbol in Clojure/Lisp is mainly used to manipulate the function names, variables and also program forms (closely related to macros). We could use Symbols (‘afsal) to manipulate objects, but that is done less common in practice. Another difference is while Symbols are namespace qualified, keywords are not. However, we could explicitly qualify a keyword in Clojure to a particular namespace by giving an extra column

user=> :afsal
:afsal
user=> ::afsal
:user/afsal
user=>
  

Although the difference is not explained in detail here, it is important to know at-least this much if you are into Clojure.

Conclusion

In dynamic languages, symbols are often used to identify things that have a stronger meaning than a string content, identifiers that are often used more than once. Moreover, in homoiconic languages like Clojure, where code can act as data, the programmer has control over manipulating functions and variables using Symbols to produce various custom behaviours. However, in statically typed languages we could argue that your comparison space is already restricted by types, and most of the times the homoiconic nature doesn’t exist. Hence, although symbols have the same meaning in the context of Java/Scala (i.e., guaranteed interning and faster equality operations), they are probably less used in practice when we compare with Ruby or Clojure.

scala> 'afsal
res0: Symbol = 'afsal

scala> Symbol("afsal")
res1: Symbol = 'afsal