https://xkcd.com/1312/

Can typeclasses solve the expression problem?

Typeclasses in Haskell roughly correspond to interfaces in object-oriented languages and can be used to solve the Expression Problem. More specifically, since Haskell takes parametric polymorphism quite seriously, typeclasses are more akin to generic interfaces, but also allow ad-hoc polymorphism.

Let's first define an Expr typeclass with const and add as functions. These functions represent types or variants in the Expression Problem.

class Expr t where
  const :: Double -> t
  add :: t -> t -> t
Continue reading →

Can object algebras solve the expression problem?

Another way to solve the expression problem in C# and other object-oriented languages is by using object algebras[1]. Object algebras define a parameterised interface, and a factory that implements that interface.

First, let's define the interface of the Eval operation.

public interface IEval
{
    double Eval();
}
Continue reading →

Can extension methods solve the expression problem?

Let's explore how extension methods in C# can solve the expression problem. For an introduction to the expression problem, refer to my first post in this series. Extension methods allow operations to be defined over a type without modifying the type's original definition.

First, we define IExpr as a marker interface and implement it in the Const and Add types. The implementations of Const and Add here are identical to those in the previous post.

public interface IExpr { }

public class Const : IExpr
{
    public double Value { get; }

    public Const(double value) =>
        Value = value;
}

public class Add : IExpr
{
    public IExpr Left { get; }
    public IExpr Right { get; }

    public Add(IExpr left, IExpr right) =>
        (Left, Right) = (left, right);
}
Continue reading →

Can partial classes solve the expression problem?

Programmers are always defining types and operations to use these types. It's the essence of developing features in working software. The expression problem[1] asks how easy it is to define types and operations in a given programming language or paradigm, and is stated as follows:

"The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)."

Continue reading →