DEV Community: Christian Neumanns

Simple Introduction to Monads - With Java Examples

Christian Neumanns — Thu, 02 Apr 2020 13:49:49 +0000

Simple Introduction to Monads - With Java Examples

Introduction

Far more than 100 articles about monads have been written! There is even a Monad tutorials timeline (from 1992 to 2015).

Why, then, yet another monad article?

Many people (me included) are intrigued and perplexed by the plethora of exotic, long-winded, or simplistic attempts to explain monads. Explanations like "A monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor." don't help. They boost the already prevalent impostor syndrome. When I started my endeavor to 'get it' I often wondered if monads are indeed incomprehensible for normal humans, or if I was just a stupid noob.

On the other hand, some people seem to believe that understanding monads is as easy as understanding burritos - an idea to which user molemind comments on Reddit: "Ah cool now I understand what Burritos are!".

Anyway, I couldn't find an introduction to monads that was easy to understand for beginners with a good background in popular, but non-pure-functional programming languages, such as C#, Java, Javascript, Python, etc. If you are in the same boat then this article hopefully fills this gap and helps to answer the following questions:

What is a monad?
Why would I use a monad? What's in it for me?
Is it true that "Once you understand monads, you lose the ability to explain them to others"?

A Simple Problem

Suppose we have to write a simple function to 'enthuse' a sentence. The function should do this by transforming an input string as follows:

remove leading and trailing spaces
convert all letters to uppercase
append an exclamation point

For example, feeding the function with " Hello bob " should return "HELLO BOB!".

A Simple Solution in Java

In most programming languages this is trivial to do. Here is a solution in Java:

static String enthuse ( String sentence ) {
    return sentence.trim().toUpperCase().concat ( "!" );
}

Note: Examples in this article are shown in Java. But readers are not required to be Java experts. Only basic Java is used, and the examples could easily be rewritten in C#, and in other languages that support generic types and higher order functions (functions that can take a function as input argument). The full source code is available on Gitlab.

To write a complete Java 'application' including a rudimentary test, we can put the code below in file MonadTest_01.java:

public class MonadTest_01 {

    static String enthuse ( String sentence ) {
        return sentence.trim().toUpperCase().concat ( "!" );
    }

    public static void main ( String[] args ) {
        System.out.println ( enthuse ( "  Hello bob  " ) );
    }
}

Then we can compile and run the program with the following commands:

javac MonadTest_01.java
java MonadTest_01

The output looks as expected:

HELLO BOB!

So far so good.

Only Functions!

In the previous Java example we used object methods (e.g. sentence.trim()). However, as this article is about monads, we have to be aware that pure functional programming languages don't have methods (functions) executed on objects. A pure functional programming language (based on the lambda calculus) has only side-effect-free functions that take an input and return a result.

Let us therefore rewrite the previous code (still in Java) by using only pure functions. This is important, because we have to use functions in order to finally understand why monads have been invented.

Here is the new code:

static String trim ( String string ) {
    return string.trim();
}

static String toUpperCase ( String string ) {
    return string.toUpperCase();
}

static String appendExclam ( String string ) {
    return string.concat ( "!" );
}

static String enthuse ( String sentence ) {
    return appendExclam ( toUpperCase ( trim ( sentence ) ) );
}

public static void test() {
    System.out.println ( enthuse ( "  Hello bob  " ) );
}

The code starts with three pure functions (trim, toUpperCase, and appendExclam) that take a string as input, and return a string as result. Note that I cheated a bit, because I still use object methods in the function's bodies (e.g. string.trim()). But that doesn't matter here, because in this exercise we don't care about the implementations of these three functions - we care about their signatures.

The interesting part is the body of function enthuse:

return appendExclam ( toUpperCase ( trim ( sentence ) ) );

We can see that there are only function calls (as in functional programming languages). The calls are nested, and executed like this:

step 1: trim ( sentence ) is executed
step 2: the result of step 1 is fed into toUpperCase
step 3: the result of step 2 is fed into appendExclam
finally the result of step 3 is returned as the result of function enthuse

The following picture illustres how the initial input is transformed by chaining three functions:

To see if everything still works fine we can execute function test. The result remains the same:

HELLO BOB!

Function Composition

In functional programming languages, nested function calls (like our appendExclam ( toUpperCase ( trim ( sentence ) ) )) are called function composition.

Important: Function composition is the bread and butter of functional programming languages. In the lambda calculus, the body of a function is a single expression. Complex expressions can be created by composing functions.

As we will see later, monads provide a solution to a problem that can arise when we compose functions. Before going on, let us therefore see variations of using function composition in different environments. Readers familiar with this important concept can jump to the next chapter.

Unix Pipes

First, it is interesting to note that the idea of function composition is similar to pipes in Unix/Linux. The output of a first command is fed as input into a second command. Then the output of the second command is fed as input into a third command, and so on. In Unix/Linux the symbol | is used to pipe commands. Here is an example of a pipe that counts the number of files containing "page" in their name (example borrowed from How to Use Pipes on Linux):

ls - | grep "page" | wc -l

Pipe Operator

Because pipes are useful in many contexts, some programming languages have a specific pipe operator. For example, F# uses |> to chain function calls. If Java had this operator, then function enthuse could be written as:

static String enthuse ( String sentence ) {
    return trim ( sentence ) |> toUpperCase |> appendExclam;
}

... which would semantically be the same, but a bit more readable than real Java that uses nested function calls:

static String enthuse ( String sentence ) {
    return appendExclam ( toUpperCase ( trim ( sentence ) ) );
}

Function Composition Operator

As function composition is essential, most functional programming languages have a dedicated function composition operator that makes it trivial to compose functions.

For example, in Haskell a dot (.) is used to compose functions (derived from the ring operator symbol ∘ used in maths). The dot is itself a function whose signature is defined as follows:

(.) :: (b -> c) -> (a -> b) -> a -> c

This tells us that the function takes two functions as input (b -> c and a -> b), and returns another function (a -> c), which is the composition of the two input functions.

Hence, to state that function h is the composition of functions f and g, in Haskell you can simply write:

h = f . g

Note the totally different semantics of the dot operator in Haskell and object oriented languages like C#, Java, etc. In Java, f.g means applying g on object f (e.g. person.name). In Haskell it means composing functions f and g.

F# uses >> to compose functions. It is defined like this:

let (>>) f g x = g(f(x))

And it is used as follows:

let h = f >> g

Note: F#'s >> operator must not be confused with the Monad sequencing operator in Haskell, which also uses the symbol >>.

If Java had a syntax similar to F# for function composition, then function enthuse could be written as:

static String enthuse ( String sentence ) = trim >> toUpperCase >> appendExclam;

Errors, But No Exceptions

For the sake of this tutorial, suppose that our functions can fail in the following ways:

Function trim fails if the input string is empty or contains only spaces (i.e. the result cannot be an empty string).
Function toUpperCase fails if the input string is empty or contains characters others than letters or spaces.
Function appendExclam fails if the input string is more than 20 characters long.

In idiomatic Java an exception is thrown to indicate an error. But pure functional programming languages don't support exceptions, because a function cannot have a side-effect. A function that can fail must return error information as part of the result returned by the function. For example, the function returns a string in case of success, or error data in case of an error.

So let's do that in Java.

First we define a simple error class with an info field that describes the error:

public class SimpleError {

    private final String info;

    public SimpleError ( String info ) {
        this.info = info;
    }

    public String getInfo() { return info; }

    public String toString() { return info; }
}

As said already, the functions must be able to return a string in case of success, or else an error object. To achieve this we can define class ResultOrError:

public class ResultOrError {

    private final String result;
    private final SimpleError error;

    public ResultOrError ( String result ) {
        this.result = result;
        this.error = null;
    }

    public ResultOrError ( SimpleError error ) {
        this.result = null;
        this.error = error;
    }

    public String getResult() { return result; }

    public SimpleError getError() { return error; }

    public boolean isResult() { return error == null; }

    public boolean isError() { return error != null; }

    public String toString() {
        if ( isResult() ) {
            return "Result: " + result; 
        } else {
            return "Error: " + error.getInfo(); 
        }
    }
}

As we can see:

The class has two immutable fields to hold either a result or an error
There are two constructors.

The first one is used in case of success (e.g. return new ResultOrError ( "hello"); ).

The second constructor is used in case of failure (e.g. return new ResultOrError ( new Error ( "Something went wrong") ); ).
isResult and isError are utility functions
toString is overridden for debugging purposes

Now we can rewrite the three utility functions to include error handling:

public class StringFunctions {

    public static ResultOrError trim ( String string ) {

        String result = string.trim();
        if ( result.isEmpty() ) {
            return new ResultOrError ( new SimpleError (
                "String must contain non-space characters." ) );
        }

        return new ResultOrError ( result );
    }

    public static ResultOrError toUpperCase ( String string ) {

        if ( ! string.matches ( "[a-zA-Z ]+" ) ) {
            return new ResultOrError ( new SimpleError (
                "String must contain only letters and spaces." ) );
        }

        return new ResultOrError ( string.toUpperCase() );
    }

    public static ResultOrError appendExclam ( String string ) {

        if ( string.length() > 20 ) {
            return new ResultOrError ( new SimpleError (
                "String must not exceed 20 characters." ) );
        }

        return new ResultOrError ( string.concat ( "!" ) );
    }
}

Note: To keep this exercise code simple, we don't check and handle null values (as we would do in production code). For example, if a function is called with null as input we simply accept that a NullPointerException is thrown.

What matters is that the three functions who previously returned a string, now return a ResultOrError object.

As a consequence, function enthuse that was defined as follows:

static String enthuse ( String sentence ) {
    return appendExclam ( toUpperCase ( trim ( sentence ) ) );
}

... doesn't work anymore.

Unfortunately, function composition is now invalid, because the functions now return a ResultOrError object, but require a string as input. The output/input types don't match anymore. The functions can't be chained anymore.

In the previous version, when the functions returned strings, the output of a function could be fed as input to the next function:

But now this can't be done anymore:

However, we can still implement enthuse in Java like this:

static ResultOrError enthuse ( String sentence ) {

    ResultOrError trimmed = trim ( sentence );
    if ( trimmed.isResult() ) {
        ResultOrError upperCased = toUpperCase ( trimmed.getResult() );
        if ( upperCased.isResult() ) {
            return appendExclam ( upperCased.getResult() );
        } else {
            return upperCased;
        }
    } else {
        return trimmed;
    }
}

Not good! The initial simple one-liner has turned into an ugly monster.

We can improve a bit:

static ResultOrError enthuse_2 ( String sentence ) {

    ResultOrError trimmed = trim ( sentence );
    if ( trimmed.isError() ) return trimmed;

    ResultOrError upperCased = toUpperCase ( trimmed.getResult() );
    if ( upperCased.isError() ) return upperCased;

    return appendExclam ( upperCased.getResult() );
}

This kind of code works in Java and many other programming languages. But it's certainly not the code we want to write over and over again. Error handling code intermixed with normal flow makes code difficult to read, write, and maintain.

More importantly, we simply can't write code like this in pure functional programming languages. Remember: An expression returned by a function is made up of function composition.

It's easy to image other cases that lead to the same dilemma. And what should we do in situations where the same problem appears in many variations? Yes, we should try to find a general solution that can be used in a maximum of cases.

Monads to the rescue!

Monads provide a general solution for this kind of problem, and they have other benefits as well. As we will see later, monads enable function composition for so-called monadic functions that cannot be composed directly because their types are incompatible.

Some people say: "You could have invented monads if they didn't exist." (for example Brian Beckman in his excellent presentation Don't fear the Monad)

That's true!

So let's try to find a solution ourselves, ignoring the fact that a monad would solve our problem.

The 'bind' Function

In functional programming languages, everything is done with functions. So we know already that we have to create a function to solve our problem.

Let's call this function bind, because it's role is to bind two functions that cannot be composed directly.

Next we have to decide what should be the input of bind, and what should it return. Let's consider the case of chaining functions trim and toUppercase:

The logic to implement must work as follows:

If trim returns a string, then toUppercase can be called, because it takes a string as input. So the final output will be the output of toUppercase
If trim returns an error, then toUppercase cannot be called, and the error must simply be forwarded. So the final output will be the output of trim

We can deduce that bind needs two input arguments:

the result of trim, which is of type ResultOrError
function toUppercase, because if trim returns a string then bind must call toUppercase

The output type of bind is easy to determine. If trim returns a string then the output of bind is the output of toUppercase, which is of type ResultOrError. If trim fails then the output of bind is the output of trim, which is also of type ResultOrError. As the output type is ResultOrError in both cases, the output type of bind must be ResultOrError.

So now we know the signature of bind:

In Java this is written as:

ResultOrError bind ( ResultOrError value, Function<String, ResultOrError> function )

Implementing bind is easy, because we know exactly what needs to be done:

static ResultOrError bind ( ResultOrError value, Function<String, ResultOrError> function ) {

    if ( value.isResult() ) {
        return function.apply ( value.getResult() );
    } else {
        return value;
    }
}

Function enthuse can now be rewritten as follows:

static ResultOrError enthuse ( String sentence ) {

    ResultOrError trimmed = trim ( sentence );

    ResultOrError upperCased = bind ( trimmed, StringFunctions::toUpperCase );
    // alternative:
    // ResultOrError upperCased = bind ( trimmed, string -> toUpperCase(string) );

    ResultOrError result = bind ( upperCased, StringFunctions::appendExclam );
    return result;
}

But this is still imperative code (a sequence of statements). If we did a good job, then we must be able to rewrite enthuse by just using function composition. And indeed, we can do it like this:

static ResultOrError enthuse_2 ( String sentence ) {

    return bind ( bind ( trim ( sentence ), StringFunctions::toUpperCase ), StringFunctions::appendExclam );
}

At first sight the body of bind might be a bit confusing. We will change that later. The point is that we use only function composition in the body of enthuse.

Note: If you never saw this kind of code before, then please take your time to digest and fully understand what's going on here. Understanding bind is the key to understanding monads! bind is the function name used in Haskell. There are alternative names, such as: flatMap, chain, andThen.

Does it work correctly? Let's test it. Here is a class containing bind, the two variations of enthuse, and some simplistic tests that cover the success and all error paths:

public class MonadTest_04 {

    // start bind
    static ResultOrError bind ( ResultOrError value, Function<String, ResultOrError> function ) {

        if ( value.isResult() ) {
            return function.apply ( value.getResult() );
        } else {
            return value;
        }
    }
    // end bind

    // start enthuse_1
    static ResultOrError enthuse ( String sentence ) {

        ResultOrError trimmed = trim ( sentence );

        ResultOrError upperCased = bind ( trimmed, StringFunctions::toUpperCase );
        // alternative:
        // ResultOrError upperCased = bind ( trimmed, string -> toUpperCase(string) );

        ResultOrError result = bind ( upperCased, StringFunctions::appendExclam );
        return result;
    }
    // end enthuse_1

    // start enthuse_2
    static ResultOrError enthuse_2 ( String sentence ) {

        return bind ( bind ( trim ( sentence ), StringFunctions::toUpperCase ), StringFunctions::appendExclam );
    }
    // end enthuse_2

    private static void test ( String sentence ) {

        System.out.println ( enthuse ( sentence ) );
        System.out.println ( enthuse_2 ( sentence ) );
    }

    public static void tests() {

        test ( "  Hello bob  " );
        test ( "   " );
        test ( "hello 123" );
        test ( "Krungthepmahanakhon is the capital of Thailand" );
    }
}

Running function tests outputs:

Result: HELLO BOB!
Result: HELLO BOB!
Error: String must contain non-space characters.
Error: String must contain non-space characters.
Error: String must contain only letters and spaces.
Error: String must contain only letters and spaces.
Error: String must not exceed 20 characters.
Error: String must not exceed 20 characters.

The bind function defined above serves our specific problem. But to make it part of a monad we will have to make it more general. We will do that soon.

Note: Using bind as shown above, is the common way to solve our problem of function composition. But it's not the only way. An alternative is called Kleisli composition (out of the scope of this article).

A Monad, Finally!

Now that we have bind, the remaining steps to get to the monad are easy. We just need to make some improvements in order to have a more general solution that can be applied in other cases too.

Our goal in this chapter is clear: See the pattern and improve ResultOrError, so that we can finally enthuse:

"A MONAD!"

First improvement:

In the previous chapter we defined bind as an isolated function that fulfilled our specific needs. A first improvement is to move bind into the ResultOrError class. Function bind must be part of our monad class. The reason is that the implementation of bind depends on the monad that uses bind. While the signature of bind is always the same, different kinds of monads use different implementations.

Second Improvement:

In our example code, the composed functions all take a string as input, and return either a string or an error. What if we have to compose functions that take an integer, and return an integer or error? Can we improve ResultOrError so that it works with any type of result? Yes, we can. We just have to add a type parameter to ResultOrError.

After moving bind into the class and adding a type parameter, the new version now becomes:

public class ResultOrErrorMona<R> {

    private final R result;
    private final SimpleError error;

    public ResultOrErrorMona ( R result ) {
        this.result = result;
        this.error = null;
    }

    public ResultOrErrorMona ( SimpleError error ) {
        this.result = null;
        this.error = error;
    }

    public R getResult() { return result; }

    public SimpleError getError() { return error; }

    public boolean isResult() { return error == null; }

    public boolean isError() { return error != null; }

    static <R> ResultOrErrorMona<R> bind ( ResultOrErrorMona<R> value, Function<R, ResultOrErrorMona<R>> function ) {

        if ( value.isResult() ) {
            return function.apply ( value.getResult() );
        } else {
            return value;
        }
    }

    public String toString() {

        if ( isResult() ) {
            return "Result: " + result; 
        } else {
            return "Error: " + error.getInfo(); 
        }
    }
}

Note the class name: ResultOrErrorMona. This is not a typo. The class isn't a monad yet, so I call it a mona (just for fun).

Third Improvement:

Suppose we have to chain the following two functions:

ResultOrError<Integer> f1 ( Integer value )
ResultOrError<String>  f2 ( Integer value )

Here is a picture to illustrate this:

Our current bind function is not able to handle this case, because the output types of the two functions are different (ResultOrError<Integer> and ResultOrError<String>). We have to make bind more general, so that functions of different value types can be chained. The signature of bind must be changed from

static <R> Monad<R> bind ( Monad<R> monad, Function<R, Monad<R>> function )

... to

static <R1, R2> Monad<R2> bind ( Monad<R1> monad, Function<R1, Monad<R2>> function )

The implementation of bind must be adapted too. Here is the new class:

public class ResultOrErrorMonad<R> {

    private final R result;
    private final SimpleError error;

    public ResultOrErrorMonad ( R result ) {
        this.result = result;
        this.error = null;
    }

    public ResultOrErrorMonad( SimpleError error ) {
        this.result = null;
        this.error = error;
    }

    public R getResult() { return result; }

    public SimpleError getError() { return error; }

    public boolean isResult() { return error == null; }

    public boolean isError() { return error != null; }

    static <R1, R2> ResultOrErrorMonad<R2> bind ( ResultOrErrorMonad<R1> value, Function<R1, ResultOrErrorMonad<R2>> function ) {

        if ( value.isResult() ) {
            return function.apply ( value.result );
        } else {
            return new ResultOrErrorMonad<R2> ( value.error );
        }
    }

    public String toString() {

        if ( isResult() ) {
            return "Result: " + result.toString(); 
        } else {
            return "Error: " + error.toString(); 
        }
    }
}

Note the class name again: ResultOrErrorMonad.

Yes, now it's a monad.

Note: In the real world we don't add a "monad" suffix for types that are monads. I called the class ResultOrErrorMonad (instead of simply ResultOrError) to make it clear that the class is a monad.

How can we be sure the class is indeed a monad?

While the term 'monad' has a very precise definition in mathematics (as everything in maths), the term isn't yet unequivocally defined in the world of programming languages. However, Wikipedia states a common definition. A monad consists of three parts:

A type constructor M that builds up a monadic type M T.

In other words, there is a type parameter for the value contained in the monad.

In our case it's type parameter R in the class declaration:
```
class ResultOrErrorMonad<R>
```
A type converter, often called unit or return, that embeds an object x in the monad: unit(x) : T → M T

In Haskell, the type converter is defined as: return :: a -> m a

In Java-like languages, this means there must be a constructor that takes a value of type R, and returns a monad M<R> that contains this value.

In our specific case it's the constructor of class ResultOrErrorMonad:
```
public ResultOrErrorMonad ( R result ) 
```
A combinator, typically called bind (as in binding a variable) and represented with an infix operator >>=, that unwraps a monadic variable, then inserts it into a monadic function/expression, resulting in a new monadic value: (mx >>= f) : (M T, T → M U) → M U

In Haskell, bind is defined as: (>>=) :: m a -> (a -> m b) -> m b

In our example it's the bind function:
```
<R1, R2> ResultOrErrorMonad<R2> bind ( ResultOrErrorMonad<R1> value, Function<R1, ResultOrErrorMonad<R2>> function )
```

Wikipedia then states: "To fully qualify as a monad though, these three parts must also respect a few laws: ..."

In Haskell the three laws as defined as follows:

return a >>= k = k a
m >>= return = m
m >>= (\x -> k x >>= h) = (m >>= k) >>= h

Discussing these laws is out of scope of this article (this is an introduction to monads). The laws ensure that monads behave well in all situations. Violating them can lead to subtle and painful bugs as explained here, here, and here. As far as I know, there is currently no compiler able to enforce the monad laws. Hence, it's the developer's responsibility to verify that the monad laws are respected. Suffice to say that the above ResultOrErrorMonad fulfills the monad laws.

Although we are done, there is still room for improvement.

Maximizing Reusability

Besides having a type parameter for the result value, we could also add a type parameter for the error value. This makes the monad more reusable, because users of the monad are now free to decide which type of error they want to use. For an example you can look at F#'s Result type.

Finally we could make the monad even more reusable by letting the user define the meaning of the two values. In our example, one value represents a result, and the other one represents an error. But we can abstract more. We can create a monad that simply holds one of two possible values - either value_1 or value_2. And the type of each value can be freely defined by a type parameter. This is indeed a standard monad supported by some functional programming languages. In Haskell it's called Either. It's constructor is defined as follows:

data Either a b = Left a | Right b

Using our ResultOrErrorMonad class as a starting point, it would be easy to create an Either monad in Java.

Note: Some projects use an Either monad for functions that might fail. Im my opinion, using a more specific ResultOrError type is a better, less error-prone option (for reasons not explained here).

An OO Bind

Now that we know how a monad works in functional programming languages, let's go back to the world of OOP (object-oriented programming). Could we create something like an OO-monad?

If we look at class ResultOrErrorMonad, we can see that everything in this class is already standard Java, with one exception: Function bind is a static member of the class. This means we can't use the dot-syntax of object methods for bind. Currently the syntax for calling bind is bind ( v, f ). But if bind was a non-static member of the class, we could write v.bind ( f ). This would make the syntax more readable in the case of nested function calls.

Luckily, it's easy to make bind non-static.

To make the monad a bit more versatile, let's also introduce a second type parameter for error values. Then the users are not required to use SimpleError - they can use their own error class.

Here is the code of a ResultOrError monad, OO-style:

public class ResultOrError<R, E> {

    private final R result;
    private final E error;

    private ResultOrError ( R result, E error ) {
        this.result = result;
        this.error = error;
    }

    public static <R, E> ResultOrError<R, E> createResult ( R result ) {
        return new ResultOrError<R, E> ( result, null );
    }

    public static <R, E> ResultOrError<R, E> createError ( E error ) {
        return new ResultOrError<R, E> ( null, error );
    }

    public R getResult() { return result; }

    public E getError() { return error; }

    public boolean isResult() { return error == null; }

    public boolean isError() { return error != null; }

    public <R2> ResultOrError<R2,E> bind ( Function<R, ResultOrError<R2,E>> function ) {

        if ( isResult() ) {
            return function.apply ( result );
        } else {
            return createError ( error );
        }
    }

    public String toString() {

        if ( isResult() ) {
            return "Result: " + result.toString(); 
        } else {
            return "Error: " + error.toString(); 
        }
    }
}

Now the code for using bind in the body of function enthuse becomes more readable. Instead of writing:

return bind ( bind ( trim ( sentence ), v -> toUpperCase(v) ), v -> appendExclam(v) );

... we can avoid the nesting and write:

return trim ( sentence ).bind ( v -> toUpperCase(v) ).bind ( v -> appendExclam(v) );

So, can monads be useful in real-world OOP environments?

Yes, they can.

But the word "can" needs to be stressed, because it depends (as so often) on what we want to achieve. Let's say, for instance, that we have some good reasons to 'not use exceptions' for error handling.

Remember the error-handling code we had to write in chapter Errors, But No Exceptions:

static ResultOrError enthuse ( String sentence ) {

    ResultOrError trimmed = trim ( sentence );
    if ( trimmed.isResult() ) {
        ResultOrError upperCased = toUpperCase ( trimmed.getResult() );
        if ( upperCased.isResult() ) {
            return appendExclam ( upperCased.getResult() );
        } else {
            return upperCased;
        }
    } else {
        return trimmed;
    }
}

Using a monad removes the boilerplate:

static ResultOrError enthuse ( String sentence ) {
    return trim ( sentence ).bind ( v -> toUpperCase(v) ).bind ( v -> appendExclam(v) );
}

Nice!

Summary

The key to understanding monads is to understand bind (also called chain, andThen, etc.). Function bind is used to compose two monadic functions. A monadic function is a function that takes a value of type T and returns an object that contains the value (a -> m a). Monadic functions cannot be directly composed because the output type of the first function called is not compatible to the input type of the second function. bind solves this problem.

Function bind is useful on its own. But it's just one part of a monad.

In Java-like world, a monad is a class (type) M with:

a type parameter T tat defines the type of the value stored in the monad (e.g. M<T>)
a constructor that takes a value of type T and returns a monad M<T> containing the value
- Java-like languages: M<T> create ( T value )
- Haskell: return :: a -> m a
a bind function used to compose two monadic functions
- Java-like languages: M<T2> bind ( M<T1> monad, Function<T1, M<T2>> function )
- Haskell: (>>=) :: m a -> (a -> m b) -> m b

A monad must respect three monad laws. These laws ensure that the monad behaves well in all situations.

Monads are primarily used in functional programming languages, because these languages rely on function composition. But they can also be useful in the context of other paradigms, such as object-oriented programming languages that support generic types and higher order functions.

Final Words

As hinted in it's title, this article is an introduction to monads. It doesn't cover the full spectrum of monads, it doesn't show other useful examples of monads (Maybe monad, IO monad, state monad, etc) and it completely ignores 'category theory', the mathematical background for monads. For those who want to know more, an abundance of information is already available on the net.

Hopefully this article helps to get the gist of monads, see their beauty, and understand how they can improve code and simplify life.

"HAPPY MONADING!"

Note: The original version of this article was written in PML (Practical Markup Language). You can look at the PML code on Gitlab. The source code examples used in this article are stored on Gitlab.

Null-Safety vs Maybe/Option - A Thorough Comparison (Part 2/2)

Christian Neumanns — Fri, 18 Oct 2019 13:28:09 +0000

In part 1 of this article we saw how the null pointer error can be eliminated with null-safety or with the Maybe/Option type.

In this part we'll have a closer look at code snippets that illustrate frequent use cases of handling the 'absence of a value'.

Useful Null-Handling Features

Besides null-safety, a language should also provide specific support for common null handling operations. Let's have a look at some examples.

Note: The additional support for null-handling presented in the following chapters is typically found only in null-safe languages. However, other languages can also provide these features, even if they are not null-safe.

Searching the First Non-Null Value

Suppose we want to look up a discount for a customer. First we try to retrieve the value from a web-service. If the value is not available (i.e. the result is null), we try to retrieve it from a database, then from a local cache. If the value is still null we use a default value of 0.0.

Now we want to write a function that provides the discount for a given customer. To keep the example simple, we ignore error-handling. Moreover, we don't use asynchronous functions to make the lookup process faster.

Java

First attempt:

static Double customerDiscount ( String customerID ) {

    Double result = discountFromNet ( customerID );
    if ( result != null ) {
        return result;
    } else {
        result = discountFromDB ( customerID );
        if ( result != null ) {
            return result;
        } else {
            result = discountFromCache ( customerID );
            if ( result != null ) {
                return result;
            } else {
                return 0.0; // default value
            }
        }
    }
}

What an ugly monstrosity! Let's quickly rewrite it:

static Double customerDiscount ( String customerID ) {

    Double result = discountFromNet ( customerID );
    if ( result != null ) return result;

    result = discountFromDB ( customerID );
    if ( result != null ) return result;

    result = discountFromCache ( customerID );
    if ( result != null ) return result;

    return 0.0; // default value
}

Note: There's nothing wrong with using several return statement, as in the code above (although some people might disagree).

The complete Java source code for a test application is available here.

Haskell

Let's start again with the straightforward, but ugly version:

customerDiscount :: String -> Float
customerDiscount customerID =
    case (discountFromNet customerID) of
    Just d -> d
    Nothing -> case (discountFromDB customerID) of
               Just d -> d
               Nothing -> case (discountFromCache customerID) of
                          Just d -> d
                          Nothing -> 0.0

There are different ways to write better code. Here is one way:

customerDiscount :: String -> Float
customerDiscount customerID =
    let discountMaybe = discountFromNet customerID
                        <|> discountFromDB customerID
                        <|> discountFromCache customerID
    in fromMaybe 0.0 discountMaybe

The complete Haskell source code for a test application, including alternative ways to write the above function, is available here.

More information (and even more alternatives) can be found in the Stackoverflow question Using the Maybe Monad in reverse.

PPL

Again, first the ugly version, written in PPL:

function customer_discount ( customer_id string ) -> float_64
    if discount_from_net ( customer_id ) as net_result is not null then
        return net_result
    else
        if discount_from_DB ( customer_id ) as DB_result is not null then
            return DB_result
        else
            if discount_from_cache ( customer_id ) as cache_result is not null then
                return cache_result
            else
                return 0.0
            .
        .
    .
.

The code becomes a one-liner and more readable with the practical if_null: operator designed for this common use case:

function customer_discount ( customer_id string ) -> float_64 = \
    discount_from_net ( customer_id ) \
    if_null: discount_from_DB ( customer_id ) \
    if_null: discount_from_cache ( customer_id ) \
    if_null: 0.0

The if_null: operator works like this: It evaluates the expression on the left. If the result is non-null, it returns that result. Else it returns the expression on the right.

In our example we use a chain of if_null: operators to find the first non-null value. If the three functions called in the expression return null, we return the default value 0.0.

The complete PPL source code for a test application is available here.

Getting a Value in a Path With Nulls

Sometimes we need to do the opposite of what we did in the previous chapter. Instead of stopping at the first non-null value, we continue until we've found the last non-null value.

For example, suppose a customer record type with two attributes:

name: a non-null string
address: a nullable address

Record type address is defined as follows:

city: a nullable string
country: a non-null string

Now we want to create a function that takes a customer as input, and returns the number of characters in the customer's city. If the customer's address attribute is null, or if the address's city attribute is null then the function should return 0.

Java

These are the record types written in idiomatic Java:

static class Customer {

    private final String name;
    private final Address address;

    public Customer ( String name, Address address) {
        this.name = name;
        this.address = address;
    }

    public String getName() { return name; }
    public Address getAddress() { return address; }
}

static class Address {

    private final String city;
    private final String country;

    public Address ( String city, String country) {
        this.city = city;
        this.country = country;
    }

    public String getCity() { return city; }
    public String getCountry() { return country; }
}

Note: We don't use setters because we want our types to be immutable.

As seen already, all types are nullable in Java. We cannot explicitly specify if null is allowed for class fields.

Function (method) customerCitySize can be implemented as follows:

static Integer customerCitySize ( Customer customer ) {

    Address address = customer.getAddress();
    if ( address == null ) return 0;

    String city = address.getCity();
    if ( city == null ) return 0;

    return city.length();
}

Alternatively we could have used nested if statements, but the above version is more readable and avoids the complexity of nested statements.

We can write a simplistic test:

public static void main ( String[] args ) {

    // city is non-null
    Address address = new Address ( "Orlando", "USA" );
    Customer customer = new Customer ( "Foo", address );
    System.out.println ( customerCitySize ( customer ) );

    // city is null
    address = new Address ( null, "USA" );
    customer = new Customer ( "Foo", address );
    System.out.println ( customerCitySize ( customer ) );

    // address is null
    customer = new Customer ( "Foo", null );
    System.out.println ( customerCitySize ( customer ) );
}

Output:

7
0
0

The whole Java source code is available here.

Haskell

Defining the record types is easy:

data Customer = Customer {
    name :: String,
    address :: Maybe Address
}

data Address = Address { 
    city :: Maybe String,
    country :: String 
}

There are several ways to write function customerCitySize in Haskell. Here is, I think, the most readable one for people more familiar with imperative programming. It uses the do notation:

import Data.Maybe (fromMaybe)

customerCitySize :: Customer -> Int
customerCitySize customer =
    let sizeMaybe = do
        address <- address customer        -- type Address
        city <- city address               -- type String
        return $ length city               -- type Maybe Int
    in fromMaybe 0 sizeMaybe

Here is a version that doesn't use the do notation:

customerCitySize :: Customer -> Int
customerCitySize customer =
    let addressMaybe = address customer    -- type Maybe Address
        cityMaybe = addressMaybe >>= city  -- type Maybe String
        sizeMaybe = length <$> cityMaybe   -- type Maybe Int
    in fromMaybe 0 sizeMaybe

If we are careful with operator precedence, we can shorten the code:

customerCitySize :: Customer -> Int
customerCitySize customer =
    fromMaybe 0 $ length <$> (address customer >>= city)

Instead of using fromMaybe we can use maybe to provide the default value:

customerCitySize :: Customer -> Int
customerCitySize customer =
    maybe 0 length $ address customer >>= city

Yes, this code is concise. But there is a lot going on behind the scenes. A looooot!. To really understand the above code one has to understand Haskell. And yes, we use a monad, indicated by the bind operator >>= in the code. For more information please refer to Haskell's documentation.

We can write a quick test:

main :: IO ()
main = do

    -- city is defined
    let address1 = Address {city = Just "Orlando", country = "USA"}
    let customer1 = Customer {name = "Foo", address = Just address1}
    putStrLn $ show $ customerCitySize customer1

    -- city is not defined
    let address2 = Address {city = Nothing, country = "USA"}
    let customer2 = Customer {name = "Foo", address = Just address2}
    putStrLn $ show $ customerCitySize customer2

    -- address is not defined
    let customer3 = Customer {name = "Foo", address = Nothing}
    putStrLn $ show $ customerCitySize customer3

Again, the output is:

7
0
0

The whole Haskell source code is available here. There are also two examples of customerCitySize implementations that compile without errors, but produce wrong results.

PPL

First, the record types:

record type customer
    attributes
        name string
        address address or null
    .
.

record type address
    attributes
        city string or null
        country string
    .
.

Function customerCitySize is written like this:

function customer_city_size ( customer ) -> zero_pos_32 =
    customer.address.null?.city.null?.size if_null: 0

Note the embedded null? checks. The evaluation of customer.address.null?.city.null?.size stops as soon as a null is detected in the chain. In that case, the whole expression evaluates to null.

The if_null: operator is used to return the default value 0 if the expression on the left evaluates to null.

Instead of .null?. we can also simply write ?.. Hence the function can be shortened to:

function customer_city_size ( customer ) -> zero_pos_32 =
    customer.address?.city?.size if_null: 0

Simple test code looks like this:

function start

    // city is non-null
    const address1 = address.create ( city = "Orlando", country = "USA" )
    const customer1 = customer.create ( name = "Foo", address = address1 )
    write_line ( customer_city_size ( customer1 ).to_string )

    // city is null
    const address2 = address.create ( city = null, country = "USA" )
    const customer2 = customer.create ( name = "Foo", address = address2 )
    write_line ( customer_city_size ( customer2 ).to_string )

    // address is null
    const customer3 = customer.create ( name = "Foo", address = null )
    write_line ( customer_city_size ( customer3 ).to_string )
.

Output:

7
0
0

The whole PPL source code is available here.

Comparison

Here is a copy of the three implementations:

Java

static Integer customerCitySize ( Customer customer ) {

    Address address = customer.getAddress();
    if ( address == null ) return 0;

    String city = address.getCity();
    if ( city == null ) return 0;

    return city.length();
}

Haskell

customerCitySize :: Customer -> Int
customerCitySize customer =
    maybe 0 length $ address customer >>= city

PPL

function customer_city_size ( customer ) -> zero_pos_32 =
    customer.address?.city?.size if_null: 0

Comparisons

Now that we know how the null pointer error is eliminated, let us look at some differences between using the Maybe monad in Haskell and null-safety in PPL.

Note: The following discussion is based on the Haskell and PPL examples shown in the previous chapters. Hence, some of the following observations are not valid in other languages that work in a similar way. For example, F#'s Option type is very similar to Haskell's Maybe type, but these two languages are far from being the same. Reader comments about other languages are of course very welcome.

Source Code

Here is a summary of the differences we saw in the source code examples.

Declaring the type of a nullable reference

Haskell: Maybe string (other languages use Option or Optional)

PPL: string or null (other languages use string?)

As seen already, the difference between Haskell and PPL is not just syntax. Both use different concepts.

Haskell uses the Maybe type with a generic type parameter. Form the Haskell doc.: "A value of type Maybe a either contains a value of type a (represented as Just a), or it is empty (represented as Nothing). The Maybe type is also a monad."

On the other hand, PPL uses union types to state that a value is either a specific type, or null.

A non-null value used for a nullable type

Haskell: Just "qwe" (other languages: Some "qwe")

PPL: "qwe"

This difference is important!

In Haskell "qwe" is not type compatible to Just "qwe". Suppose the following function signature:

foo :: Maybe String -> String

This function can be called as follows:

foo $ Just "qwe"

But a compiler error arises if we try to call it like this:

foo "qwe"

There are a few consequences to be aware of.

First, if a type changes from Maybe T to T, then all occurrences of Just expression must be changed to expression. The inverse is true too. A change from type T to Maybe T requires all occurrences of expression to be refactored to Just expression.

This is not the case in PPL. An expression of type string is type-compatible to an expression of string or null (but the inverse is not true). For example, the function ...

foo ( s string or null ) -> string

... can be called like this:

foo ( "qwe" )

If the function is later refactored to ...

foo ( s string ) -> string

... then it can still be called with:

foo ( "qwe" )

Secondly, in Haskell some functions with the same name might exist for input type Maybe T, as well as for input T. But the semantics are different. For example, length "qwe" returns 3 in Haskell, while length $ Just "qwe" returns 1. It is important to be aware of this, because there is no compile-time error if function length is used for an expression whose type changes from Maybe T to T or vice-versa.

Thirdly, one has to be aware of the possibility of nested Maybes in Haskell. For example, suppose again we declare:

data Customer = Customer {
    name :: String,
    address :: Maybe Address
}

data Address = Address { 
    city :: Maybe String,
    country :: String 
}

What is the return type of the following function?

customerCity customer = city <$> address customer

Is it Maybe string. No, it's Maybe ( Maybe string ) - a nested Maybe. Ignoring this can lead to subtle bugs. For an interesting discussion see the Stackoverflow question Simplifying nested Maybe pattern matching.

'No value' symbol

Haskell: Nothing (other languages: None)

PPL: null (other languages: nil, void, ...)

Checking for null

Haskell (one way to do it):

intToString :: Maybe Integer -> Maybe String
intToString i = case i of
    Just 1  -> Just "one"
    Nothing -> Nothing
    _       -> Just "not one"

Note: Omitting the Nothing case does not produce a compiler error. Instead, the function returns Just "not one" if it is called with Nothing as input.

PPL (new version):

function int_to_string ( i pos_32 or null ) -> string or null = \
    case value of i
        when null: null
        when 1   : "one"
        otherwise: "not one"

Note: Omitting the when null case results in the following compiler error:

Clause 'when null' is required because the case expression might be null at run-time.

Providing a default non-null value

Haskell: fromMaybe 0 size (requires Data.Maybe; F#: defaultArg 0 size)

PPL: size if_null: 0 (other languages: size ?: 0, ( ?: is sometimes called 'Elvis operator')

Getting the first non-null value in a chain, or else a default value

Haskell:

customerDiscount :: String -> Float
customerDiscount customerID =
    let discountMaybe = discountFromNet customerID
                        <|> discountFromDB customerID
                        <|> discountFromCache customerID
    in fromMaybe 0.0 discountMaybe

PPL:

function customer_discount ( customer_id string ) -> float_64 = \
    discount_from_net ( customer_id ) \
    if_null: discount_from_DB ( customer_id ) \
    if_null: discount_from_cache ( customer_id ) \
    if_null: 0.0

Getting the last value in a chain, or else a default value

Haskell:

customerCitySize :: Customer -> Int
customerCitySize customer =
    maybe 0 length $ address customer >>= city

PPL:

function customer_city_size ( customer ) -> zero_pos_32 =

    customer.address?.city?.size if_null: 0

Implementation

Back in 1965, Tony Hoare introduced null in ALGOL "simply because it was so easy to implement", as he said.

In Java, and probably most other programming languages, null is implemented by simply using the value 0 for a reference. That is to say, if we write something like name = "Bob", then the memory address used for variable name contains the starting address of the memory block that stores the string value "Bob". On the other hand, when name = null is executed, then the content of the memory address used for variable name is set to 0 (i.e. all bits set to zero). Easy and efficient, indeed!

A more thorough explanation is available in chapter Run-time Implementation of my article A quick and thorough guide to 'null'.

So, implementing null is easy. However, adding null-safety to a language is a totally different story. Implementing compile-time-null-safety in a practical way is far from being easy. Adding good support to simplify null-handling as far as possible is a challenge. Adding null-safety and good support for null-handling makes life more difficult for language creators, but much easier for language users (i.e. software developers). This doesn't come as a surprise, though. It's just a frequently observed fact of life:

It is easy to make it difficult to use.
It is difficult to make it easy to use.

On the other hand, a type like Maybe can simply be added to the language's standard library, without the need for special support in the language.

In he case of Haskell, Maybe is a monad in the standard prelude, and Haskell's standard functional programming features are used to handle Maybe values.

Space and Time

Let's starts with null.

There are just two kinds of basic operations needed at run-time:

Assign null to a reference (e.g. name = null): this is typically done by just writing 0 to a memory cell.
Check if a reference points to null (e.g. if name is null): this is very quickly done by just comparing the content of a memory cell with 0.

The conclusion is obvious: null operations are extremely space- and time-efficient.

On the other hand, using a wrapper type is probably less efficient, unless the compiler uses very clever optimizations.

As a general observation, it is probably fair to say that, for a given language, using a wrapper type cannot be made faster than using 0 for a null reference.

In practice, however, the performance difference might not be an issue in many kinds of applications.

A Note On The "Billion Dollar Mistake"

Yes, Tony Hoare stated that null has "probably caused a billion dollars of pain and damage in the last forty years".

However, a few seconds later he said the following, which is really important, but often ignored:

More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

-- Tony Hoare

The mistake was not the invention of null per se. The mistake was the lack of compile-time-null-safety and good support for null-handling in programming languages.

As seen in this article it is possible to eliminate the null pointer error in languages that use null. No "billion-dollar mistake" anymore!

Isn't it amazing that it took the software development industry over 40 years to recognize this and start creating null-safe languages?

Summary

Here is a summary of the key points:

Java (and most other popular programming languages)

All reference types are nullable.
null can be assigned to any reference (variable, input argument, function return value, etc.).
There is no protection against null pointer errors. They occur frequently and are the reason for the billion-dollar mistake.

Haskell (and some other programming languages using Maybe/Option)

null is not supported. Hence null pointer errors cannot occur.
The Maybe type (a monad with a type parameter) is used to manage the 'absence of a value'.
Pattern matching is used to test for Nothing.
Standard language features are used to handle Maybe values (e.g. the monad's bind operator >>=).

PPL (and some other null-safe programming languages)

By default all reference types are non-nullable and null cannot be assigned.
null is an ordinary type with the single value null. Union types are used to handle the 'absence of a value' (e.g. string or null).
The compiler ensures a null-check is done before executing an operation on a nullable type. Thus null pointer errors cannot occur.
The language provides specific support to simplify null-handling as far as possible. Null-handling code is concise, and easy to read and write.

Conclusion

The aim of this article was to compare null-safety in PPL with the Maybe type in Haskell. We did this by looking at a number of representative source code examples.

By comparing two languages, we must of course be careful not to generalize our observations to all other languages.

However, in the context of this article we saw that:

Null-safety, as well as the Maybe type eliminate the null pointer error.
Using the Maybe/Optional type is easier to implement in a language than null-safety. It simplifies life for language designers and implementers.
Providing good support for null-safety is a challenge for language creators. However, it simplifies life for developers.

Header image by dailyprinciples from Pixabay.

Null-Safety vs Maybe/Option - A Thorough Comparison (Part 1/2)

Christian Neumanns — Wed, 02 Oct 2019 12:15:53 +0000

Introduction

There are two effective approaches to eliminate the daunting null pointer error:

The Maybe/Option pattern - mostly used in functional programming languages.
Compile-time null-safety - used in some modern programming languages.

This article aims to answer the following questions:

How does it work? How do these two approaches eliminate the null pointer error?
How are they used in practice?
How do they differ?

Notes:

Readers not familiar with the concept of null might want to read first: A quick and thorough guide to 'null'.
For an introduction to Maybe / Option I recommend: F#: The Option type. You can also search the net for "haskell maybe" or "f# option".

Why Should We Care?

"I call it my billion-dollar mistake. It was the invention of the null reference in 1965. ... This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. ..."

-- Tony Hoare

In the context of Java, Professor John Sargeant from the Manchester school of computer science puts it like this:

"Of the things which can go wrong at runtime in Java programs, null pointer exceptions are by far the most common."

-- John Sargeant

We can easily deduce:

"By eliminating the infamous null pointer error, we eliminate one of the most frequent reasons for software failures."

That's a big deal!

We should care about it.

Three Approaches

Besides showing the reason for the null pointer error, this article also aims to demonstrate how the null pointer error can be eliminated.

We will therefore compare three different approaches:

The language uses null, but doesn't provide null-safety.

In these languages null pointer errors occur frequently.

Most popular languages fall into this category. For example: C, C++, Java, Javascript, PHP, Python, Ruby, Visual Basic.
The language doesn't support null, but uses Maybe (also called Option or Optional) to represent the 'absence of a value'.

As null is not supported, there are no null pointer errors.

This approach is mostly used in some functional programming languages. But it can as well be used in non-functional languages.

At the time of writing, the most prominent languages using this approach are probably Haskell, F#, and Swift.
The language uses null and provides compile-time-null-safety.

Null pointer errors cannot occur.

Some modern languages support this approach.

Source Code Examples

In this chapter we'll look at some source code examples of common use cases involving 'the absence of a value'. We will compare the code written in the three following languages representing the three approaches mentioned in the previous chapter:

Java (supports null, but not null-safe)

Java is one of the industry's leading languages, and one of the most successful ones in the history of programming languages. But it isn't null-safe. Hence, it is well suited to demonstrate the problem of the null pointer error.
Haskell (Maybe type)

Haskell is the most famous one in the category of pure functional languages. It doesn't support null. Instead it uses the Maybe monad to represent the 'absence of a value'.

Note: I am by no means a Haskell expert. If you see any mistake or need for improvement in the following examples, then please leave a comment so that the article can be updated.
PPL (supports null and is null-safe)

The Practical Programming Language (PPL) supports null and has been designed with full support for compile-time-null-safety from the ground up. However, be warned! PPL is just a work in progress, not ready yet to write mission-critical enterprise applications. I use it in this article because (full disclosure!) I am the creator of PPL, and I want to initiate some interest for it. I hope you don't mind - after reading this article.

All source code examples are available on Github. The Github source code files contain alternative solutions for some examples, not shown in this article.

Null-Safety

How does null-safety work in practice? Let's see.

Null Not Allowed

We start with an example of code where null is not allowed.

Say we want to write a very simple function that takes a positive integer and returns a string. Neither the input nor the output can be null. If the input value is 1, we return "one". If it is not 1, we return "not one". How does the code look like in the three languages? And, more importantly, how safe is it?

Java

This is the function written in Java:

static String intToString ( Integer i ) {
    if ( i == 1 ) {
        return "one";
    } else {
        return "not one";
    }
}

We can use the ternary operator and shorten the code a bit:

static String intToString ( Integer i ) {
    return i == 1 ? "one" : "not one";
}

Note: I am using type Integer, which is a reference type. I am not using type int, which is a value type. The reason is that null works only with reference types.

To test the code, we can write a simple Java application like this:

public class NullNotAllowedTest {

    static String intToString ( Integer i ) {
        return i == 1 ? "one" : "not one";
    }

    public static void main ( String[] args ) {
        System.out.println ( intToString ( 1 ) );
        System.out.println ( intToString ( 2 ) );
    }
}

If you want to try out this code you can use an online Java Executor like this one. Just copy/paste the above code in the Source File tab, and click Execute. It looks like this:

If you have Java installed on your system, you can also proceed like this:

Save the above code in file NullNotAllowedTest.java.
Compile and run it by typing the following two commands in a terminal:
```
javac NullNotAllowedTest.java
java NullNotAllowedTest
```

The output written to the OS out device is:

one
not one

So far so good.

Haskell

In Haskell, there are a few ways to write the function. For example:

intToString :: Integer -> String
intToString i = case i of
    1 -> "one"
    _ -> "not one"

Note: The first line in the above code could be omitted, because Haskell supports type inference for function arguments. However, it's considered good style to include the type signature, because it makes the code more readable. Hence, we will always include the type signature in the upcoming Haskell examples.

The above code uses pattern matching, which is the idiomatic way to write code in Haskell.

We can write a simple Haskell application to test the code:

intToString :: Integer -> String
intToString i = case i of
    1 -> "one"
    _ -> "not one"

main :: IO ()
main = do
    putStrLn $ intToString 1
    putStrLn $ intToString 2

As for Java, you can use an online Haskell executor to try out the code. Here is a screenshot:

Alternatively, if Haskell is installed on your system, you can save the above code in file NothingNotAllowedTest.hs. Then you can compile and run it with these two commands:

ghc -o NothingNotAllowedTest NothingNotAllowedTest.hs
NothingNotAllowedTest.exe

The output is the same as in the Java version:

one
not one

PPL

In PPL the function can be written like this:

function int_to_string ( i pos_32 ) -> string
    if i =v 1 then
        return "one"
    else
        return "not one"
    .
.

Note: The comparison operator =v in the above code is suffixed with a v to make it clear we are comparing values. If we wanted to compare references, we would use operator =r.

We can shorten the code by using an if-then-else expression (instead of an if-then-else statement):

function int_to_string ( i pos_32 ) -> string = \
    if i =v 1 then "one" else "not one"

A simple PPL application to test the code looks like this:

function int_to_string ( i pos_32 ) -> string = \
    if i =v 1 then "one" else "not one"

function start
    write_line ( int_to_string ( 1 ) )
    write_line ( int_to_string ( 2 ) )
.

At the time of writing there is no online PPL executor available. To try out code you have to install PPL and then proceed like this:

Save the above code in file null_not_allowed_test.ppl
Compile and run the code in a terminal by typing:
```
ppl null_not_allowed_test.ppl
```

Again, the output is:

one
not one

Discussion

As we have seen (and expected), the three languages allow us to write 'code that works correctly'. Here is a reprint of the three versions, so that you can easily compare the three versions:

Java

static String intToString ( Integer i ) {
    return i == 1 ? "one" : "not one";
}

Haskell

intToString :: Integer -> String
intToString i = case i of
    1 -> "one"
    _ -> "not one"

PPL

function int_to_string ( i pos_32 ) -> string = \
    if i =v 1 then "one" else "not one"

A pivotal question remains unanswered:

"What happens in case of a bug in the source code?"

-- The Crucial Question

In the context of this article we want to know: What happens if the function is called with null as input? And what if the function returns null?

This question is easy to answer in the Haskell world. null doesn't exist in Haskell. Haskell uses the Maybe monad to represent the 'absence of a value'. We will soon see how this works. Hence, in Haskell it is not possible to call intToString with a null as input. And we can't write code that returns null.

PPL supports null, unlike Haskell. However, all types are non-null by default. This is a fundamental rule in all effective null-safe languages. A PPL function with the type signature pos_32 -> string states that the function cannot be called with null as input, and it cannot return null. This is enforced at compile-time, so we are on the safe side. Code like int_to_string ( null ) simply doesn't compile.

"By default all types are non-null in a null-safe language."

"By default it is illegal to assign null."

-- The 'non-null by default' rule

What about Java?

Java is not null-safe. Every type is nullable, and there is no way to specify a non-null type for a reference. This means that intToString can be called with null as input. Moreover, nothing prevents us from writing code that returns null from intToString.

So, what happens if we make a function call like intToString ( null )? The program compiles, but the disreputable NullPointerException is thrown at run-time:

Exception in thread "main" java.lang.NullPointerException
    at NullNotAllowedTest.intToString(NullNotAllowedTest.java:4)
    at NullNotAllowedTest.main(NullNotAllowedTest.java:10)

Why? The test i == 1 is equivalent to i.compareTo ( new Integer(1) ). But i is null in our case. And executing a method on a null object is impossible and generates a NullPointerException.

This is the well-known reason for the infamous billion-dollar mistake.

What if intToString accidentally returns null, as in the following code:

public class NullNotAllowedTest {

    static String intToString ( Integer i ) {
        return null;
    }

    public static void main ( String[] args ) {
        System.out.println ( intToString ( 1 ) );
    }
}

Again, no compiler error. But a runtime error occurs, right? Wrong, the output is:

null

Why?

The reason is that System.out.println has been programmed to write the string "null" if it is called with null as input. The method signature doesn't show this, but it is clearly stated in the Java API documentation: "If the argument is null then the string 'null' is printed.".

What if instead of printing the string returned by intToString, we want to print the string's size (i.e. the number of characters). Let's try it by replacing ...

System.out.println ( intToString ( 1 ) );

... with this:

System.out.println ( intToString ( 1 ).length() );

Now the program doesn't continue silently. A NullPointerException is thrown again, because the program tries to execute length() on a null object.

As we can see from this simple example, the result of misusing null is inconsistent.

In the real world, the final outcome of incorrect null handling ranges from totally harmless to totally harmful, and is often unpredictable. This is a general, and frustrating property of all programming languages that support null, but don't provide compile-time-null-safety. Imagine a big application with thousands of functions, most of them much more complex than our simple toy code. None of these functions are implicitly protected against misuses of null. It is understandable why null and the "billion dollar mistake" have become synonyms for many software developers.

We can of course try to improve the Java code and make it a bit more robust. For example, we could explicitly check for a null input in method intToString and throw an IllegalArgumentException. We could also add a NonNull annotation that can be used by some static code analyzers or super-sophisticated IDEs. But all these improvements require manual work, might depend on additional tools and libraries, and don't lead to a satisfactory and reliable solution. Therefore, we will not discuss them. We are not interested in mitigating the problem of the null pointer error, we want to eliminate it. Completely!

Null Allowed

Let's slightly change the specification of function int_to_string. We want it to accept null as input and return:

"one" if the input is 1
"not one" if the input is not 1 and not null
null if the input is null

How does this affect the code in the three languages?

Java

This is the new code written in Java:

static String intToString ( Integer i ) {
    if ( i == null ) {
        return null;
    } else {
        return i == 1 ? "one" : "not one";
    }
}

We could again use the ternary operator and write more succinct code:

static String intToString ( Integer i ) {
    return i == null ? null : i == 1 ? "one" : "not one";
}

Whether to chose the first or second version is a matter of debate. As a general rule, we should value readability more than terseness of code. So, let's stick with version 1.

The crucial point here is that the function's signature has not changed, although the function's specification is now different. Whether the function accepts and returns null or not, the signature is the same:

String intToString ( Integer i ) {

This doesn't come as a surprise. As we saw already in the previous example, Java (and other languages without null-safety) doesn't make a difference between nullable and non-nullable types. All types are always nullable. Hence by just looking at a function signature we don't know if the function accepts null as input, and we don't know if it might return null. The best we can do is to document nullability for each input/output argument. But there is no compile-time protection against misuses.

To check if it works, we can write a simplistic test application:

public class NullAllowedTest {

    static String intToString ( Integer i ) {
        if ( i == null ) {
            return null;
        } else {
            return i == 1 ? "one" : "not one";
        }
    }

    static void displayResult ( String s ) {
        String result = s == null ? "null" : s;
        System.out.println ( "Result: " + result );
    }

    public static void main ( String[] args ) {
        displayResult ( intToString ( 1 ) );
        displayResult ( intToString ( 2 ) );
        displayResult ( intToString ( null ) );
    }
}

Output:

Result: one
Result: not one
Result: null

Haskell

This is the code in Haskell:

intToString :: Maybe Integer -> Maybe String
intToString i = case i of
    Just 1  -> Just "one"
    Nothing -> Nothing
    _       -> Just "not one"

Key points:

Haskell doesn't support null. It uses the Maybe monad.

The Maybe type is defined as follows:
```
data Maybe a = Just a | Nothing
    deriving (Eq, Ord)
```
The Haskell doc states: "The Maybe type encapsulates an optional value. A value of type Maybe a either contains a value of type a (represented as Just a), or it is empty (represented as Nothing). The Maybe type is also a monad."

Note: More information can be found here and here. Or you can read about the Option type in F#.
The function signature clearly states that calling the function with no integer (i.e. the value Nothing in Haskell) is allowed, and the function might or might not return a string.
For string values the syntax Just "string" is used to denote a string, and Nothing is used to denote 'the absence of a value'. Analogously, the syntax Just 1 and Nothing is used for integers.
Haskell uses pattern matching to check for 'the absence of a value' (e.g. Nothing ->). The symbol _ is used to denote 'any other case'. Note that the _ case includes the Nothing case. Hence if we forget the explicit check for Nothing there will be no compiler error, and "not one" will be returned if the function is called with Nothing as input.

Here is a simple test application:

import Data.Maybe (fromMaybe)

intToString :: Maybe Integer -> Maybe String
intToString i = case i of
    Just 1  -> Just "one"
    Nothing -> Nothing
    _       -> Just "not one"

displayResult :: Maybe String -> IO()
displayResult s = 
    putStrLn $ "Result: " ++ fromMaybe "null" s

main :: IO ()
main = do
    displayResult $ intToString (Just 1)
    displayResult $ intToString (Just 2)
    displayResult $ intToString (Nothing)

Output:

Result: one
Result: not one
Result: null

Note the fromMaybe "null" s expression in the above code. In Haskell this is a way to provide a default value in case of Nothing. It's conceptually similar to the expression s == null ? "null" : s in Java.

PPL

In PPL the code looks like this:

function int_to_string ( i pos_32 or null ) -> string or null
    case value of i
        when null
            return null
        when 1
            return "one"
        otherwise
            return "not one"
    .
.

Note: A case expression will be available in a future version of PPL (besides the case statement shown above). Then the code can be written more concisely as follows:

function int_to_string ( i pos_32 or null ) -> string or null = \
    case value of i
        when null: null
        when 1   : "one"
        otherwise: "not one"

Key points:

In PPL null is a regular type (like string, pos_32, etc.) that has one possible value: null.

It appears as follows in the top of PPL's type hierarchy:
PPL supports union types (also called sum types, or choice types). For example, if a reference can be a string or a number, the type is string or number.

That's why we use the syntax pos_32 or null and string or null to denote nullable types. The type string or null simply means that the value can be any string or null.
The function clearly states that it accepts null as input, and that it might return null.
We use a case instruction to check the input and return an appropriate string. The compiler ensures that each case is covered in the when clauses. It is not possible to accidentally forget to check for null, because (in contrats to Haskell) the otherwise clause doesn't cover the null clause.

A simple test application looks like this:

function int_to_string ( i pos_32 or null ) -> string or null
    case value of i
        when null
            return null
        when 1
            return "one"
        otherwise
            return "not one"
    .
.

function display_result ( s string or null )
    write_line ( """Result: {{s if_null: "null"}}""" )
.

function start
    display_result ( int_to_string ( 1 ) )
    display_result ( int_to_string ( 2 ) )
    display_result ( int_to_string ( null ) )
.

Output:

Result: one
Result: not one
Result: null

Note the """Result: {{s if_null: "null"}}""" expression used in function display_result. We use string interpolation: an expression embedded between a {{ and }} pair. And we use the if_null: operator to provide a string that represents null. Writing s if_null: "null" is similar to s == null ? "null" : s in Java.

If we wanted to print nothing in case of null, we could code """Result: {{? s}}"""

Discussion

Again, the three languages allow us to write code that works correctly.

But there are some notable differences:

In Haskell and PPL, the functions clearly state that 'the absence of a value' is allowed (i.e. Nothing in Haskell, or null in PPL). In Java, there is no way to make a difference between nullable and non-nullable arguments (except via comments or annotations, of course).
In Haskell and PPL, the compiler ensures we don't forget to check for 'the absence of a value'. Executing an operation on a possibly Nothing or null value is not allowed. In Java we are left on our own.

Here is a comparison of the three versions of function int_to_string:

Java

static String intToString ( Integer i ) {
    if ( i == null ) {
        return null;
    } else {
        return i == 1 ? "one" : "not one";
    }
}

Haskell

intToString :: Maybe Integer -> Maybe String
intToString i = case i of
    Just 1 -> Just "one"
    Nothing -> Nothing
    _ -> Just "not one"

PPL

New version (not available yet):

function int_to_string ( i pos_32 or null ) -> string or null = \
    case value of i
        when null: null
        when 1   : "one"
        otherwise: "not one"

Current version:

function int_to_string ( i pos_32 or null ) -> string or null
    case value of i
        when null
            return null
        when 1
            return "one"
        otherwise
            return "not one"
    .
.

And here is the function used to display the result:

Java

static void displayResult ( String s ) {
    String result = s == null ? "null" : s;
    System.out.println ( "Result: " + result );
}

Haskell

import Data.Maybe (fromMaybe)

displayResult :: Maybe String -> IO()
displayResult s = 
    putStrLn $ "Result: " ++ fromMaybe "null" s

        function display_result ( s string or null )
            write_line ( """Result: {{s if_null: "null"}}""" )
        .

That's it for part 1. In part 2 (to be published soon) we'll have a look at some useful null-handling features used frequently in practice.

Header image by dailyprinciples from Pixabay.

We Need a New Document Markup Language - Here is Why

Christian Neumanns — Wed, 20 Mar 2019 11:55:56 +0000

Introduction: What's the Problem?

There are many document markup languages available already. Wikipedia lists over 70 variations in its List of document markup languages - among them HTML, Markdown, Docbook, Asciidoctor, reStructuredText, etc.

Why, then, does the title of this article suggest we need yet another one ???

What's the problem?

There are two fundamental problems with the existing document markup languages: Either they are not easy to use, or they are not well suited to write complex documents, such as technical articles, user manuals, or books. An example of "not easy to use, but suited for complex documents" would be Docbook. An example of "easy to use, but not suited for complex documents" would be Markdown.

Of course, the above categorization is simplistic. But it should serve as a good starting point to get the gist of this article which aims to delineate the kind of problems that occur in practice. You'll see many representative examples of markup code that illustrates what's wrong, complemented by links to more information.

You'll also discover a new markup language. Lots of examples will demonstrate how a new syntax can lead to a language that is "easy to use and suited for complex documents". A proof-of-concept implementation is already available. More on this later.

Preliminary Remarks

Please note:

This article is about document markup languages used to write text documents, such as books and articles published on the net. There are other markup languages used to describe specific data, such as mathematical formulas, images, and geographic information, but these are out of scope of this article. However, some ideas presented in this article might be applied to other kinds of markup languages as well.
This article focuses solely on the syntax of markup languages. We will not discuss other aspects that are also important in the choice of a suitable markup language, such as: support on your OS, ease of installation and dependencies, the tool chain available to create final documents, the quality of documentation, price, customer/user support, etc.
Readers of this article should have some basic experience with a markup language like HTML, Markdown, Asciidoctor, or similar.
Readers not aware of the many advantages of document markup languages might first want to read: Advantages of Document Markup Languages vs WYSIWYG Editors (Word Processors)

Inconveniences / Part 1

Let us first consider some well-known markup languages and show some inconveniences.

HTML

HTML is the language of the web. So, why not write everything in HTML? The reasons to discard this option are well known. Let's quickly recapitulate them:

HTML is cumbersome to write. Nobody wants to write XML code by hand, although editors with HTML/XML support might help.
Some frequent writing tasks require non-trivial HTML code.

Suppose we want to display a horizontally centered image with a simple black border and a link. The HTML code an unexperienced user would expect to write could look like this:
```
<img src="ball.png" align="center" border="yes" link="http://www.example.com/ball">
```
But the code he or she actually has to write is cumbersome and there are different ways to do it. Here is one way:
```
<div style="text-align: center">
    <a href="http://www.example.com/ball">
        <img src="ball.png" style="border:1px solid black;">
    </a>
</div>
```
HTML lacks "productivity features for writers", such as:
- Automatic generation of a table of contents, index, glossary, etc.
- Variables used to hold recurring values
- Splitting a document into different files
Other inconveniences will be shown later.

Markdown

Markdown is a very popular, lightweight markup languages. It is easy to learn and use, and well suited for short and simple texts, such as comments in forums, readme files, etc.

However, it suffers from the following problems that make it unsuitable for complex or big documents (e.g. technical articles, user manuals, and books):

The original Markdown defined by John Gruber lacks many features expected by writers, such as tables (only embedded HTML tables are supported), automatic generation of table of contents, syntax highlighting, file splitting, etc.
There is no unique, unambiguous specification for Markdown. Many flavors of Markdown exists, with different rules and different features supported. This leads to incompatibility issues when markup code is shared. CommonMarkdown is an attempt to solve this problem. However, the specification is huge and not completed yet (at the time of writing (February 2019) version 0.28, dated 2017-08-01, is the latest one).
Markdown has similar problems and limitations to those shown in chapter Inconveniences / Part 2. These flaws can quickly become an annoyance when you use Markdown for anything else than short, simple texts.

Here is a list of articles with more information about Markdown's shortcomings:

Docbook

Docbook is an XML-based markup language that uses semantic tags to describe documents.

It has probably the most complete set of features among all markup languages. It has been used by many authors, is pre-installed on some Linux distributions, and is supported by many organizations and publishers. Docbook has been successfully used to create, publish, and print lots of big documents of all kinds.

But it has the following drawbacks:

It uses XML and a verbose syntax.

Look at the following example, borrowed from Wikipedia:

<?xml version="1.0" encoding="UTF-8"?>
<book xml:id="simple_book" xmlns="http://docbook.org/ns/docbook" version="5.0">
    <title>Very simple book</title>
    <chapter xml:id="chapter_1">
        <title>Chapter 1</title>
        <para>Hello world!</para>
        <para>I hope that your day is proceeding <emphasis>splendidly</emphasis>!</para>
    </chapter>
    <chapter xml:id="chapter_2">
        <title>Chapter 2</title>
        <para>Hello again, world!</para>
    </chapter>
</book>

Would you enjoy writing and maintaining such code?

Compare the above code with the following one, written in a modern markup language like Asciidoctor:

= Very simple book

== Chapter 1

Hello world!

I hope that your day is proceeding _splendidly_!

== Chapter 2

Hello again, world!

Docbook is complex, and therefore hard to learn and use.
Output produced by Docbook, especially HTML, looks old-fashioned (see examples on its website). Of course, presentation can be customized, but this is not an easy task.

LaTeX

LaTeX is a high-quality typesetting system. It is widely used in academia to create scientific documents. It is considered to be the best option for writing PDF documents containing lots of mathematic formulas and equations.

I never used LaTeX myself, because I don't write scientific documents - just articles and books to be published on the web. Therefore, I don't want to comment on it too much. However, it is important to mention it because of its popularity in academia.

LaTeX's unique syntax seems verbose to me, and a bit complex. Here is an abbreviated example from Wikipedia:

\documentclass{article}
\usepackage{amsmath}
\title{\LaTeX}

\begin{document}
    \maketitle
    \LaTeX{} is a document preparation system ...

    % This is a comment
    \begin{align}
        E_0 &= mc^2 \\
        E &= \frac{mc^2}{\sqrt{1-\frac{v^2}{c^2}}}
    \end{align}  
\end{document}

The article Conversion from (La)TeX to HTML states that converting LaTeX math to HTML is "a challenge".

Some markup languages allow LaTeX snippets to be embedded in their markup code, which can be very useful if you need the power of LaTeX for maths. There are other options to display maths on the web, such as Mathjax or MathML (an ISO standard and part of HTML5).

Practical Markup Language (PML)

Before moving on to the most interesting part of this article, let me briefly introduce the new markup language I mentioned already in the introduction.

The language is called Practical Markup Language (PML).

"fitting the needs of a particular situation in a helpful way; helping to solve a problem or difficulty; effective or suitable"

-- definition of 'practical' in the Cambridge Dictionary

I started the PML project a few months ago because I couldn't find a markup language that was easy to use and well suited for big, complex documents.

In the next chapter we'll look at examples of markup code written in PML, compared to code written in other languages. So let's first mention two basic PML syntax rules needed to understand the upcoming examples:

A PML document is a tree of nodes (similar to an XML/XHTML document). Each node starts with a {, followed by a tag name. Each node ends with a }. A node can contain text or child nodes.

For example, here is a node containing text that will be rendered in italics:
```
{i bright}
```
This node starts with {i, and ends with }. i is the tag name. In this case i is an abbreviation for italic, which means that the node's content will be rendered in italics. The content of this node is the text bright. The above PML markup code will be rendered as: bright
Some nodes have attributes, used to specify additional properties of the node (besides its tag name).

For example, the title of a chapter is defined with attribute title, as follows:
```
{chapter title=A Nice Surprise
    Once upon a time ...
}
```

There is not much more to say about the basic concept of PML syntax. For more insight, and a description of features not used in this article, please consult the PML User Manual.

You can download and play around with a free implementation of PML. But please note:

IMPORTANT: PML is a work in progress. There are missing features, you might encounter bugs, and backwards compatibility is currently not guaranteed.

I use PML myself to write all my web documents, such as this article. For links to more real-life examples please visit the FAQ.

Inconveniences / Part 2

I this chapter we'll look at examples that reveal some problems encountered with markup languages. This is by no means an exhaustive enumeration of all troubles and corner cases. The aim is to just show a few examples that demonstrate the kind of inconveniences and limits encountered in the real world.

For each example the markup code will be shown in HTML, Asciidoctor, reStructuredText, and PML.

If you want to try out some code, you can use the following online testers (no need to install anything on your PC):

An online tester for PML is not yet available. You have to install PML on a Windows PC if you want to try it out.

Font Styles

Font styles (italic, bold, monospace, etc.) are often used in all kinds of documents, so good support is essential.

But as we will see, surprises and limits can emerge, as soon as we have to deal with non-trivial cases. Let's look at some examples to illustrate this.

Part of a Sentence in Italics

Suppose we want to write:

They called it Harmonic States, a good name.

This is a trivial case, and all languages support it.

HTML

They called it <i>Harmonic States</i>, a good name.

Asciidoctor

They called it _Harmonic States_, a good name.

reStructuredText

They called it *Harmonic States*, a good name.

PML

They called it {i Harmonic States}, a good name.

Part of a Word in Italics

We want to write:

She unwrapped the challenge first.

HTML

She <i>un</i>wrapped the challenge first.

Asciidoctor
```
She __un__wrapped the challenge first.
```
Note that we have to use two underscores. Using a single underscore (as in the first example), would result in:

She _un_wrapped the challenge first.
reStructuredText
```
She *un*\wrapped the challenge first.
```
Note that the letter w has to be escaped (preceded by a backslash) for reasons explained here. If the letter is not escaped then a warning is displayed and the result is:

She *un*wrapped the challenge first.
PML
```
She {i un}wrapped the challenge first.
```

Text in Bold And Italic

We want to write:

They were all totally flabbergasted.

HTML

They were all <b><i>totally flabbergasted</i></b>.

Asciidoctor

They were all *_totally flabbergasted_*.

reStructuredText

Combining bold and italic is not supported in reStructuredText, but there are some complicated workarounds.

PML

They were all {b {i totally flabbergasted}}.

Real-Life Example

Here is an example inspired by an Asciidoctor user who asked how to display:

_id optional.

Let's make the exercise a little bit more interesting by also displaying:

_id optional.

HTML

<b>_id</b> <i>optional</i>
<i>_id</i> <b>optional</b>

No surprise here. It just works as expected.

Asciidoctor

Intuitive attempt:
```
*_id* _optional_
__id_ *optional*
```
The first line doesn't work, it produces:

id _optional

However, the second line works, which is a bit counterintuitive.

If normal text includes a character that is also used for markup (in our case the _ preceding id), then the character must be escaped. This is a fundamental rule in pretty much all markup languages. For example in HTML a < must be escaped with <. Many languages (including Asciidoctor and PML) use a backslash prefix (e.g. \r) to escape. So let's rewrite the code:
```
*\_id* _optional_
_\_id_ *optional*
```
This doesn't work in Asciidoctor. It produces

_id _optional_
and

\_id optional

Here is a correct version, as suggested in an answer to the user's question:
```
*pass:[_]id* _optional_
_pass:[_]id_ *optional*
```
Another answer suggests this solution:
```
*_id* __optional__
___id__ *optional*
```
More edge case are documented in chapters Unconstrained formatting edge cases and Escaping unconstrained quotes of the Asciidoctor User Manual.
reStructuredText
```
**_id** *optional*
*_id* **optional**
```
There is no problem here, because the character _ is not used in reStructuredText to define markup.

However, suppose we wanted to write:

*id* *optional*.

Here is the code:
```
*\*id\** ***optional***
```
Note that the *s in id must be escaped, but the *s in optional don't need to be escaped.

PML

{b _id} {i optional}
{i _id} {b optional}

Nested Font Styles

Nested font styles of the same kind (e.g. <i>...<i>...</i>...</i>) occur rarely in text written by humans, but they could be more or less frequent in auto-generated markup code. If they are not supported then the tool that generates the markup code becomes more complicated to implement, because it must track the font styles that are active already, in order to avoid nesting them.

So, how is this supported in the different languages?

HTML
```
<i>This is <i>excellent</i>, isn't it?</i>
```
No problem, it produces

This is excellent, isn't it?
Asciidoctor
```
_This is _excellent_, isn't it?_
```
The above code is obviously ambiguous: Are the italics nested or do we want to italicize "This is " and ", isn't it?". When I tested it, the result was neither of it:

This is _excellent, isn’t it?_

As far as I now, Asciidoctor doesn't support nested font styles of the same kind.
reStructuredText

The reStructuredText specification states: "Inline markup cannot be nested." However, no error is displayed if it is nested, and the result is unspecified.
PML
```
{i This is {i excellent}, isn't it?}
```
Font styles of the same kind can be nested in PML. The above code results in:

This is excellent, isn't it?

Nested Chapters

Suppose we are writing an article titled "New Awesome Product" that contains four chapters. The structure looks as follows:

New Awesome Product
    Introduction
    More features
    Faster
    Less resources

Later on we decide to insert chapter "Advantages" as a parent of the three last chapters. The structure now becomes:

New Awesome Product
    Introduction
    Advantages
        More features
        Faster
        Less resources

What are the changes required in the markup code to pass from version 1 to version 2? Can you simply insert the code for a new chapter? Let's see.

HTML

Note: Code changes are displayed in bold.

As shown above, besides inserting the new chapter, we have to change the markup for the three child chapters: h2 must be changed to h3

Asciidoctor

Again, we have to change the markup for the three child chapters: == must be changed to ===

Note: The blank lines between the chapters are required, otherwise the document is not rendered correctly.

reStructuredText

The markup for the three child chapters must be changed: All occurrences of = must be changed to -

The non-trivial rules for reStructuredText's sections can be looked up here.

PML

In PML, there is no need to change the code of the three child chapters.

Bottom Line

In all languages, except PML, the markup code of all child chapters must be adapted if a parent chapter is inserted.

This is not a deal-breaker in case of small articles with few chapters. But image you are writing your next big article or book with lots of chapters and frequent changes. Now, the necessity to manually update child chapters can quickly turn into a daunting, boring, and error-prone task.

Note: Asciidoctor provides a leveloffset variable that can be used to change the level of chapters. This might be useful in some cases, but it also creates additional unneeded complexity, as can be seen here and here.

A more serious kind of problem can arise in the following situation: Imagine a set of different documents that share some common chapters. To avoid code duplication, the common chapters are stored in different files, and an insert file directive is used in the main documents. This works fine as long as the levels of all common chapters are the same in all documents. But troubles emerge if this is not the case.

It is also worth to mention that HTML, Asciidoctor and reStructuredText don't protect you against wrong chapter hierarchies. For example, you don't get a warning or error if a chapter of level 2 contains a direct child chapter of level 4.

In a language like PML, the above problems simply don't exist, because the level is not specified in the markup code. All chapters (of any level) are defined with the same, unique syntax. The chapters' tree structure (i.e. the level of each chapter) is automatically defined by the parser. And wrong hierarchies in the markup code, such as a missing } to close a chapter, are flagged by an error message.

Lists

In Asciidoctor the kind of problems we have seen with chapter hierarchies can also arise with list hierarchies (e.g. lists that contain lists). The reason is the same as for chapters: Asciidoctor lists use different markup code to explicitly specify the level of list items (* for level 1, ** for level 2, etc.). Moreover, there are a number of complications you have to be aware of when working with complex list content.

In reStructuredText, nested lists are created using indentation and blank lines. This works fine for simple nested lists, but creates other problems in more complex cases (not discussed here). Using whitespace (e.g. blank lines and indentation) to define structure in markup code is a bad idea, as we'll see later.

In HTML and PML, the above problems don't exist with lists because the syntax for parent- and child nodes is the same (not shown here).

Comments

Good support for comments is important, because they are used frequently, especially in collaborative environments. So, how well are they supported?

Single-Line Comment

A single-line comment is a line that contains only a comment (no markup). They are supported in all languages.

HTML

A HTML (or XML) comment starts with  at any subsequent position. Example:
```

```
Asciidoctor

A single-line comment starts with // at the beginning of a line:
```
// comment
```
reStructuredText

A single-line comment starts with .. at the beginning of a line and must be followed by an empty line
```
.. comment
```
PML

A comment starts with {- at any position, and ends with -} at any subsequent position.
```
{- comment -}
```

Trailing Comment

A trailing comment appears at the end of a line, after markup code.

HTML

The reason will be explained later <!-- TODO: add link -->

Asciidoctor

At the time of writing, trailing comments are not supported in Asciidoctor (see issue 991 on Github).
reStructuredText

Trailing comments are not supported in reStructuredText.

PML

The reason will be explained later {- TODO: add link -}

Inline Comment

An inline comment is preceded and followed by markup code.

HTML
```
This is  awesome.
```
Asciidoctor

Inline comments are not supported in Asciidoctor.
reStructuredText

Inline comments are not supported in reStructuredText.
PML
```
This is {- good -} awesome.
```

Multi-Line Comment

A multi comment starts at a given line, and ends at a subsequent line.

HTML

<!--
comment line 1
comment line 2
comment line 3
-->

Asciidoctor

A multi-line comment starts with //// on a line, and ends with with //// on a subsequent line:
```
////
comment line 1
comment line 2
comment line 3
////
```
reStructuredText

The rules for multi-line comments are a bit 'surprising'. User Cecil Curry puts it more bluntly in a Stackoverflow question: "It's non-trivial, non-obvious, and tragically fragile."

Here is an example:
```
..
  comment line 1
  comment line 2
  comment line 3
```
All lines after the .. must be indented. In practice, this means that unindented text must first be indented to include it in a multi-line comment. If the text is later uncommented then the indent must be removed. Quite inconvenient and fragile, indeed.

PML

{-
comment line 1
comment line 2
comment line 3
-}

Nested Comments

Nested comments are useful when we want to comment a block of text that contains already one or more comments.

Nested comments are not supported in HTML, Asciidoctor, and reStructuredText. However, there are some tricky workarounds in HTML, as explained here

PML supports nested comments to any level. Here is a simple example.

{-
These lines
will not {- nested comment -}
appear in the final document.
-}

Removed Comments

By definition, comments are not displayed to the readers. But it is also important that comments are removed in the final document, because otherwise readers might be able to see them. This rule is applied in Asciidoctor, reStructuredText, PML, and probably most other markup languages. But not in hand-coded HTML. This can lead to troubles. Imagine the following scenario:

Boss to Bob: "Please remove my private mobile number from the website".
Bob to Boss: "Ok".
Bob comments the HTML code containing the mobile number.
Boss checks the new version and is happy because his number is no more displayed.
A website visitor clicks on "Display Source Code" in the browser's context menu, and ... discovers the boss's private mobile number.

I had to learn the hard way that silly things like this do happen. And yes, I was the 'Bob'.

Conclusion

The following table summarizes the support for comments:

	Single-line	Trailing	Inline	Multi-line	Nested	Removed
HTML	✔	✔	✔	✔	❌	❌
Asciidoctor	✔	❌	❌	✔	❌	✔
reStructuredText	✔	❌	❌	✔	❌	✔
PML	✔	✔	✔	✔	✔	✔

Whitespace And Indentation

At first, using whitespace to define structure seams like a good idea. Look at the following example:

parent
    child 1
    child 2

The structure is very easy to read and write. No noisy special markup characters are needed.

It is therefore tempting for markup language designers to use whitespace as a simple way to define structure. Unfortunately, this works well only for simple structures, and has other inconveniences we'll see soon.

Therefore, a simple, but important rule must be applied in markup languages designed to work well with complex content:

"Whitespace doesn't change the structure or semantics of the document."

-- whitespace-insignificant-rule

What does this mean?

First, let us define whitespace: Whitespace is any set of one or more consecutive spaces, tabs, new lines, and other Unicode characters that represent space.

In our context, the above rule means that:

Within text, a set of several (i.e. more than one) whitespace characters is treated the same as a single space character.

For example, this code:
```
a beautiful
    flower
```
... is identical to this one:
```
a beautiful flower
```
Between structural elements, a set of whitespace characters is insignificant.

For example, this code:
```
<table>

    <tr>
```
... is identical to this one:
```
<table><tr>
```

A special case of whitespace is indentation (leading whitespace at the beginning of a line). The above rule implies that indentation is insignificant too. Indentation doesn't change the result of the final document.

Applying the whitespace-insignificant rule is important, because it leads to significant advantages:

There is no need to learn, apply and worry about complex whitespace rules (see examples below).

Violating the whitespace-insignificant rule in a markup specification adds unneeded complexity, and can lead to markup code that is ugly, error-prone, and difficult to maintain, especially in the case of nested lists.
Whitespace can freely be used by authors to format the markup code in a more understandable, presentable and attractive way (pretty printing). For example, lists (and lists of lists) can be indented to display their structure in a visually clear and maintainable way, without the risk of changing the underlying structure.
Text blocks can be copy/pasted without the need to adapt whitespace.
If shared text blocks (stored in different files) are imported into several documents with different structures, there is no risk of changing or breaking the structure.
There is no unexpected or obscure behavior if the whitespace is not visible for human readers. Some examples:
- a mixture of whitespace characters, such as spaces and tabs, especially when used to indent code
- whitespace at the end of a line
- whitespace in empty lines
- visually impaired (blind) people who can't read whitespace
Note: To alleviate the pain, some editors provide a display-whitespace mode.
Tools that generate markup code, as well as markup parsers are generally easier to create.
In some situations it is useful to reduce whitespace to a minimum (e.g. no new lines), in order to save storage space and improve performance.

If you want a few examples demonstrating the kind of technical problems that arise if whitespace is significant, you can read:

So, how is whitespace handled in the languages we are discussing in this article?

HTML

HTML applies the whitespace-insignificant rule.

For a thorough explanation, look at this excellent article written by Patrick Brosset: When does white space matter in HTML?.
Asciidoctor

In Asciidoctor, whitespace is significant in some cases.

This can lead to surprising behavior and problems with no easy or no satisfying solution. Some examples can be seen here and here.
reStructuredText

reStructuredText has whitespace rules that are 'a bit surprising'.

For example, writing *very* results in very (text in italics, as expected). However, * very* results in * very* (no italics!), because of the whitespace preceding "very". To understand why, the answer might be found in chapter Whitespace of the specification.
PML

Similar to HTML, PML applies the whitespace-insignificant rule.

There is one exception: For practical reasons, a blank line between two text blocks results in a paragraph break. This means that instead of writing:
```
{p text of paragraph 1}
{p text of paragraph 2}
```
... we can simply write:
```
text of paragraph 1

text of paragraph 2
```

Note

Sometimes, whitespace is significant in text. For example whitespace must be preserved in source code examples. Or, in verbatim text, several consecutive spaces or new lines must be preserved in the final document. All languages support this. However, in reStructuredText it's not always obvious how to it, as shown here.

Other Inconveniences

As seen already, some markup languages systematically use opening and closing tags. An example would be <i> and </i> in HTML. All XML-based languages, as well as PML belong to this class of languages.

Without digging into details, here are some drawbacks that can occur in languages that do not (or not always) use pairs of distinct opening/closing tags (e.g. Markdown, Asciidoctor, and reStructuredText):

Editor support

Creating good, reliable editor support is more difficult to develop. Examples of useful editor features are:
- syntax highlighting for markup code
- markup code completion
- visualizing pairs of block start/end marks (e.g. { and its corresponding })
- block collapsing/expanding
In the case of languages that use distinct opening/closing tags, the two last features work out-of-the-box in some editors. For example, PML uses { and } for node boundaries. This is also used in many programming languages (C, Java, Javascript, etc.) and therefore block features implemented for programming languages will also work for PML.
Document validation

Fewer syntax and structure errors can be detected automatically. This can lead to more time spent on debugging documents. Or, even worse, there might be silently ignored errors that end up in wrong output (Did I really fail to spot the missing warning block on page 267 of my 310 pages book?).
Parsers

It is more difficult to create parsers (i.e. programs that read markup code) that work well in all cases. If different parsers read the same markup code, there is an increased risk of getting different results for corner-cases.
Auto-generated markup code

Tools that generate markup code programmatically are more difficult to create. For example, if whitespace is significant, or font styles cannot be nested, then additional state must be updated and tracked, in order to respect these rules.

My Own Experience

When I started writing technical documents a few years ago, I used Docbook. It took me some time to learn it, but after that I never stumbled on anything I couldn't do. Docbook is powerful. However, I disliked typing verbose XML code. I tried some XML editors, but gave up. Finally I just wrote complete text blocks unformatted in Notepad++, and then adorned the text with the necessary markup code. It was frustrating and time-consuming. Moreover, I couldn't find a stylesheet that produced good-looking web documents, and I didn't have the patience, motivation, and experience to fiddle around with big, complex CSS files and adapt them.

Later on I discovered Asciidoctor. What a relief. Everything was so much simpler and the web documents were beautiful, out of the box. Asciidoctor's documentation is great, and I think the community is helpful and active. However, when I started to write more complex and bigger documents, I had to deal with problems similar to those described in the previous chapters. At one point, I had to develop a specific pre- and post-processor to solve a problem for which I couldn't find a solution in Asciidoctor/Gitbook.

An intriguing question emerged: "Why do these problems not exist in Docbook?".

To make a long story short, I concluded that we need a new markup syntax. The key points to success would be:

easy to learn: few, simple, consistent and predictable rules (no exceptions)
easy to write and read
well-structured documents with no ambiguities
powerful enough to create big, complex documents without the need for "special rules, tricks, or workarounds"

After a period of investigating, pondering, programming, testing and improving, the Practical Markup Language (PML) was born. Since then, I never looked back again. Today I write all my web documents in PML (including this article). Of course, when I started to create PML, it was to cover my own needs. So, I am probably biased. I tried my best to write an article based on facts, but I encourage you to leave a comment if you see anything wrong, unfair, or missing in this article. I appreciate constructive feedback of any kind, and I will update the article if needed.

Conclusion

As demonstrated in this article, a good number of problems encountered with existing document markup languages vanish with the PML syntax.

Now we should come together to improve PML and make it more powerful, so that it covers more use cases and more people can benefit from it.

Please help to spread the word. Or try out PML and send feedback, so that we know what needs to be refined. Your voice counts!

The vision is to create the best possible document markup language and all necessary tools, so that writers can focus on writing and enjoy creating beautiful documents in a minimum of time - without worrying about unneeded complexity.

Advantages of Document Markup Languages vs WYSIWYG Editors

Christian Neumanns — Thu, 07 Mar 2019 06:18:57 +0000

Introduction

Did you ever wonder what's the best tool to write an article, user manual, book, or any other kind of text document?

There are many options to choose from. Most people use a What-You-See-Is-What-You-Get (WYSIWYG) editor (also called a text processor), such as Google Docs, LibreOffice or Word. However, more and more people are writing their documents using another, less known option: a document markup language.

Why?

Should you, too, use a document markup language instead of a WYSIWYG editor? Let's see.

Note: This article does not compare or evaluate different writing solutions/products. It will not tell you why product X is better than product Y. The purpose of this article is to point out general advantages of document markup languages.

WYSIWYG Editors

Offline or online WYSIWYG editors are often the best solution for non-technical people who occasionally write short or medium-size documents. Some websites have their own WYSIWYG editor integrated in the website, which makes it very easy to write formatted text. WYSIWYG software is also the right choice for design-intensive publications where you want to have total control of the position, size, font, and other visual properties of the document's elements, and you want to immediately see and trim the end result while working on the document. Examples of such documents are flyers, advertisements, party invitations, posters, etc.

There are many word processors to choose from.

Some word processors offer advanced features for particular tasks, such as writing a novel.

However, as said already, this article focuses on markup languages, so let's move on and see why many people prefer them over WYSIWYG editors.

Document Markup Languages

Note: Readers familiar with markup languages can skip the following two chapters.

Basic Concept

A document markup language consists of a set of rules and symbols (special characters) used to annotate plain text. The annotated text can then be read by a markup processor to generate styled documents (e.g. HTML, PDF, ePub, etc.) or any other kind of data.

For example, in some markup languages an underline (_) is used to emphasize text and render it in italics. Writing:

A _good_ girl.

... results in:

A good girl.

Hence, markup code is just plain text intermixed with markup instructions.

A markup document consists of one or more text files that contain markup code.

There are many document markup languages to choose from.

Simple Example

Suppose you create a text file with the following content (written in Markdown syntax):

# Simple Markup Example

This is just a _simpe_ example.

Here is a list:

- orange
- banana
- apple

After the above text has been converted to HTML (by the markup processor), the result in the browser looks like this:

The style of the final document can be customized. This is often done by modifying a separate CSS files.

Advantages

Ubiquitous Advantages

All document markup languages work like this:

A markup document consists of plain text.
Content and presentation are defined in separate files.

The content file contains the text and markup instructions. The presentation file contains the stylesheet (e.g. a CSS file).

It turns out that these two simple concepts lead to an astonishing set of practical advantages, explained in the following chapters.

Distraction-Free Writing

When you write, you focus on content, not on presentation. You focus on what you want to say, instead of how it should be displayed or printed.

Moreover, you can customize your writing environment (editor) without worrying about the end result. For example, you can use a different font and a different number of characters displayed per line, without thinking about how this will affect the final document.

Thus, when you write, it's easier to be in the flow (in the zone), which Wikipedia describes as a "mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity".

This is a big deal!

Choice of Editor

You can use your preferred text editor or Integrated Development Environment (IDE) to write your document. You are not tied to a specific editor. There is no vendor lock-in.

Imagine a team of writers collaborating on the same document. Everybody just uses the text editor he/she likes the most for the task at hand. For example, Bob and Alice are working on a new user manual, but Bob uses Emacs on Linux, while Alice uses Notepad++ on Windows.

Some high-end text editors provide incredibly powerful features (some out-of-the-box, some via extensions) and are highly customizable, so that you can setup your ideal writing software. As a result, you have a more enjoyable writing experience and you are more productive than with a WYSIWYG editor.

Choice of Presentation

Because content and presentation are defined in separate files, you can change presentation by simply choosing another stylesheet (e.g. CSS file) from a predefined set, and adapt it if needed. If your document is read on different reading/printing devices, you can use different presentations for each device.

Sometimes the same stylesheet is used for many documents. Thus, presentation remains consistent over large sets of documents. Moreover, global presentation changes can often be done in a matter of seconds, because only one file needs to be changed.

Choice of Transformation

Depending on the language and tools you use, you can transform your markup code into final documents of different formats, such as HTML, PDF, ePub etc.

And if your tool can't do it, there is Pandoc, the swiss-army-knife for document conversions. At the time of writing, Pandoc can convert not less than 31 input formats into not less than 49 output formats. That's 31 x 49 = 1,519 transformations supported by one tool.

Choice of Text Tools

There are many tools and online services available to handle plain text files - some possibly pre-installed on your PC. You can use them to handle your markup documents, in whatever way you want.

Examples:

You can use a version control service such as Github, Gitlab, or Bitbucket to track changes and issues, collaborate on documents, synchronize documents on different devices, and use all other powerful features.
To get an idea of free tools for technical people, look at this List of Unix Text Processing Tools. Nowadays, you can also easily install these Linux tools on Windows.

Customized Tools

Reading and writing plain text files is very well supported in most programming languages. Therefore it is easier for programmers to develop customized tools to explore and manipulate documents.

For instance, pre-processors and post-processors can be created to add features and automate recurring tasks. A concrete example would be a tool that displays a sorted list of website links used in your document and checks for any broken links.

Moreover, it is easy to programmatically create documents. For instance, a product catalog or a reference manual could be created automatically based on structured data stored in a database.

Portability

As content and presentation is defined in plain text files, documents are portable among different operating systems (Windows, Unix/Linux, macOS, etc.). All operating systems have very good support for text files.

Language-Dependant Advantages

In this chapter we'll look at additional advantages found in some document markup languages.

File Splitting

Some markup languages allow you to split a document into different files.

For example, each chapter of a book (and maybe also each sub-chapter) can be stored in a different file and in a directory hierarchy of your choice.

This can be a game-changer when a team collaborates on mid-size or big documents, because it makes editing, reorganizing, and collaborating much more convenient.

Semantic Markup

Some document markup languages support only presentation tags. The better breed of them prefer semantic tags over presentation tags. This means that, when you use markup, you specify the meaning of a piece of text. You do not specify how the text will be displayed or printed. You define the What, not the How.

A first benefit is that this leads to much more flexibility in the rendering process.

Suppose your text contains several warning messages that need to stand out. If you use a markup language that supports only presentation tags, you could decide to aggressively display a centered text in red on yellow, like this:

This works well if the warnings are displayed on a color screen. But if the document is printed on a color-less printer, or displayed on a black-and-white e-ink device, the result is a mess.

On the other hand, in a markup language that provides semantic tags, you would simply adorn your warnings with a warning tag. The stylesheet used in the conversion process specifies how all warnings are displayed. Hence, you can globally change the presentation of all warnings for a given output device by simply changing one entry in the corresponding stylesheet. For example, in the stylesheet used for e-ink devices, you could specify to display the warnings in italics with a bigger font. Moreover, if you have other messages that have to stand out, like errors or tips, you can use different, specific tags and handle them separately, without any interference.

A second advantage is that semantic markup opens the door for searchable documentation databases. You can query your markup code and extract useful information. For example, you could create a tool to count the number of warnings contained in the document or extract and save the warnings in a separate file for further exploration.

Parameters

Advanced markup languages support parameters embedded in the markup code. You first define a parameter by assigning a value to a name (e.g. my_email=foo@example.com). Then, later in the document, you use the parameter name, instead of the value. If the value changes later, you just need to change it in one place, which is easy, fast, and less error-prone.

This is an application of the important Don't Repeat Yourself (DRY) principle. It improves maintainability, productivity, and reliability. It is useful for all kinds of recurring text and markup attribute values, especially if they are subject to change. For example: your email address, the price of your product, the name of your dog, or whatever.

Advanced Features

Here is a brief summary of additional powerful options:

Real-time preview

Sometimes it is convenient to see a preview of the final document (e.g. a HTML page) while typing the markup code. As soon as you edit the markup code, you can immediately see the effect, without the need to re-launch the markup processor. Some editors support this kind of immediate feedback out-of-the-box or by plugins. For example, you type the document in one window, and you see the real-time preview in an adjacent window.

You can think of this as a markup editor with WYSIWYG support.

Public API

A public Application Program Interface (API) allows programmers to programmatically execute, change, or extend the markup processor's operations.

At the bare minimum, an API enables other applications to convert documents. For example, a web server could read markup code stored in a file or entered by the user and convert it to HTML on-the-fly, by using the API. This could be used, for instance, to provide an online markup tester, so that people can try out snippets of markup code, without the need to install anything on their PC.

More advanced APIs can provide additional functionality, such as:

Change the rendering of some tags
Add more tags to the language
Add more output formats to the converter
Create a markup document programmatically, by retrieving data from different sources.
Hooks (also called extension points)

Hooks allow programmers to execute functions when specific events occur.

For example, once the Abstract Syntax Tree (AST) (i.e. tree structure) of the document has been created by the markup processor, an extension point can programmatically explore the AST to extract and report useful information, or even change it to implement the most extravagant requirements.

Templates

Templates allow you to customize or redefine the rendering of specific tags, by modifying text files containing the template code.

User-defined tags

You can use configuration files to extend the language and add your own tags to the markup language, and specify how each tag is rendered.

Processor Directives

Processor Directives are special instructions inserted in the markup code and interpreted by the markup processor.

Suppose somebody writes a test sheet for students. The sheet contains instructions that should only be visible for teachers. In that case, a directive could be used to display specific text blocks only if the document is printed for teachers.

Conclusion

Should you use a WYSIWYG editor or a markup language?

As so often, the answer depends on your use case.

However, as demonstrated in this article, in many cases a document markup language is the better choice, because you can benefit from numerous advantages. In a nutshell:

When you write, you can focus on writing, because you don't have to think about presentation, and you can use your preferred text editor with your customized setup.
Your writing environment is more flexible and powerful, because you have a lot of options to handle plain text files.
It is easier to automate and customize your writing process, which saves time and reduces errors.

Ultimately, a well-designed document markup language makes your writing experience more enjoyable and increases your productivity.

What's your own experience? Please share it by leaving a comment.

Note: For more insight, please read We Need a New Document Markup Language - Here is Why

DEV Community: Christian Neumanns

Simple Introduction to Monads - With Java Examples

Simple Introduction to Monads - With Java Examples

Introduction

A Simple Problem

A Simple Solution in Java

Only Functions!

Function Composition

Unix Pipes

Pipe Operator

Function Composition Operator

Errors, But No Exceptions

The 'bind' Function

A Monad, Finally!

Maximizing Reusability

An OO Bind

Summary

Final Words

Null-Safety vs Maybe/Option - A Thorough Comparison (Part 2/2)

Useful Null-Handling Features

Searching the First Non-Null Value

Java

Haskell

PPL

Getting a Value in a Path With Nulls

Java

Haskell

PPL

Comparison

Comparisons

Source Code

Declaring the type of a nullable reference

A non-null value used for a nullable type

'No value' symbol

Checking for null

Providing a default non-null value

Getting the first non-null value in a chain, or else a default value

Getting the last value in a chain, or else a default value

Implementation

Space and Time

A Note On The "Billion Dollar Mistake"

Summary

Conclusion

Null-Safety vs Maybe/Option - A Thorough Comparison (Part 1/2)

Introduction

Why Should We Care?

Three Approaches

Source Code Examples

Null-Safety

Null Not Allowed

Java

Haskell

PPL

Discussion

Null Allowed

Java

Haskell

PPL

Discussion

We Need a New Document Markup Language - Here is Why

Introduction: What's the Problem?

Preliminary Remarks

Inconveniences / Part 1

HTML

Markdown

Docbook

LaTeX

Popular for Big Documents

Practical Markup Language (PML)

Inconveniences / Part 2

Font Styles

Part of a Sentence in Italics

Part of a Word in Italics

Text in Bold And Italic

Real-Life Example

Nested Font Styles

Nested Chapters

HTML

Asciidoctor

reStructuredText