This is a blatant copy of Atlassian’s https://blog.developer.atlassian.com/optional-broken/.

You can jump into below snippet and understand what’s the issue, and choose to skip rest of the blog.

public class Silliness { public static void main(String[] args) {

Map<String, String> mapp = new HashMap<>();

mapp.put("afsal", null);

Optional.ofNullable("afsal")

.map(mapp::get).map(String::toUpperCase)); // works but wrong Optional.ofNullable("afsal")

.map(v -> mapp.get(v).toUpperCase())); // fails, but right

}

An FP enthusiast may say, `java.Optional`

doesn’t follow Functor law, while it inherently tried to become a `Functor`

.

`functor.map(f).map(g) === functor.map(g compose f)`

Well the answer is if `null`

is considered a value (may be for some legacy/bad reasons), then…

This is a detailed explanation of Fix Point and Y combinator in Scala, that’s the foundation before you explore `Fix`

at a type-level.

The blog has been **moved to the below link**. Sorry for the inconvenience.

https://afsalthaj.github.io/myblog/posts/2021-04-15-fix-points.html

There are wonderful libraries in Scala ecosystem for resource handling. I recommend the following as a quick start.

- ZManaged from ZIO (https://github.com/zio/zio)
- cats.effect.Resource (https://github.com/typelevel/cats)

These are superior libraries to many of those in other popular* languages, though I find the comparison is mostly with java `try-with-resources.`

The simple story of this blog is, the resource management techniques that you can leverage with these libraries mentioned above is ** not just a shiny alternative** to Java

`try-with-resources`

, because some (well, many) important semantics are simply missing in `try-with-resources,`

(detailed further below). Hence, I find these libraries to be sort of a…**How do you implement square (or double) using Monads?**

Quite simple: Use the monad instance of a function and then `join` on a function that returns a function.

How on earth does that work?

You know the signature of Monad join.

`join :: Monad f => f (f a) -> f a`

join ffa = ffa >>= id

Consider `data Optional a = Full a | Empty`

has a monad instance. This implies:

`>> join (Full (Full 1))`

Full 1

In this case,`f`

is `Optional`

, and `ffa`

is `Full (Full 1)`

When you replace `Optional`

to be a function `f: t -> a`

…

For those who need to get straight into the code with explanations as comments, please feel free to jump to:

https://scastie.scala-lang.org/afsalthaj/4rTuhrx6Tw6wohdyaP73bg/2

Others, read on !

In type-driven development, it is often necessary to distinguish between different interpretations of the same underlying type. For example, for the underlying type ‘integer’, there are multiple possible Monoids — that is, multiple ways to accumulate integers. One Monoid is to sum all the values, with the ‘empty’ value being 0. Another Monoid for integer multiplies all the values, so the ‘empty’ value has to be 1. …

I hope we all are much familiar with building, compiling and running Scala applications with SBT.

Developers now write SBT plugins relatively quickly, especially to standardise builds across hundreds of applications in the organisation. For instance, packaging docker, fetching org-artifactory credentials, common entry scripts etc.

IMO, it is simple enough, because all we need to know is Scala and there isn’t actually a need of learning the entire SBT reference manual.

These days, I try to avoid a shell script / separate docker-compose.yml /other-language orchestrations alongside my Scala app. …

Stop unreadable logs……….. !!

Its good to talk about summary in an intro:

As a summary of requirements, there shouldn’t be any more separate docker related orchestrations. Everything that you do with docker are first class citizens in the project that can run along with other test cases in your project. We can see bits and pieces of code everywhere trying to achieve this, but here we strive for the best possible way of doing it.

Let’s list down our requirements first.

For certain test cases we need to run a docker-compose as the first step, which in turn depends on creating a few…

We tend to forget this quite often. An invariant functor or an exponential functor is, given `A => B`

and `B => A`

, it converts type `A`

to type`B`

in the same context `F[_].`

We call this `xmap`

.

That’s the famous `Functor`

! Covariant functor implements `xmap`

by discarding the function `B => A`

.

As expected, it discards `f: A => B`

and makes use of `contramap`

to implement `xmap`

As expected, it is `DecodeJson`

, where the type parameter in the type class comes at covariant position (method result)

If type…

Here is my gist that combines the various algebra defined in various parts of the application, using **Free Monad** with in **Scalaz**! For those who are impatient, jump straight to line number 58, that handles what Scalaz is missing !

Well, that was useless toy example.

I think , with my experience with Free (learning scalaz, learning the red book, reading Free things, Runar’s paper on Trampoling to Free and in fact implementing free things in production with Scala), I can say operations as data with Free is attractive, **but that can bring significant set of boiler plates that…**

A software engineer and a functional programming enthusiast at Simple-machines, Sydney, and a hardcore hiking fan. https://twitter.com/afsalt2