What are the arguments both for and against both name equivalence and structural equivalence?

Question

In language design circles there used to be a long-running debate over whether languages should use structural equivalence or name equivalence. Languages like ALGOL or ML or Modula-3 used structural equivalence while ... well, pretty much most programming languages employ named equivalence (including Modula-2).

What are the typical arguments in favour of structural equivalence? What are the typical arguments in opposition to it? What are the typical arguments in favour of name equivalence? What are the typical arguments in opposition to it?

Answer 1

I think the advantage of structural type systems is that they encourage you to create fine-grained interfaces oriented towards what the user of the interface needs, rather than what the implementer provides.

In a nominative type system you need a common dependency on the interface. In a structural type system that requirement is eliminated: you can build a loosely coupled system without needing to create that common library where you put all the interfaces. Each client can independently declare the interface it expects from a collaborator.

The disadvantage of structural type systems is that they match up classes to interfaces which may not really implement the correct contract. For example, if you have this interface:

public interface IBananaProvider
{
   /// Returns a banana, never null.
   Banana GetBanana();
}

then the following class will implicitly be considered to implement IBananaProvider in a structural type system. However, the class violates the post condition that the returned banana is never null:

public class SomeBananaProvider
{
    // returns a banana or null if we're all out
    public Banana GetBanana()
    {
        if (bananas.Count > 0)
        {
            return bananas.RemoveLast();
        }
        else
        {
            return null;
        }
    }
} 

This could be fixed if the contract was somehow specified formally and considered part of the type structure. I think things are moving in that direction, e.g. System.Diagnostics.Contracts in .NET 4.0.

Answer 2

One good argument in favour of strict name equivalence (as available in Ada for example) is that it makes it possible for the compiler to reject code that accidentally mixes different units, like for example centimeters and inches, or celsius and fahrenheit.

In a language with strict name equivalence you could have two types

type celsius based on float; type fahrenheit based on float;

var c : celsius; var f : fahrenheit;

c := f; /* compile time error: incompatible types */

While, in a language with lose name equivalence and in one with structural equivalence ...

type celsius is float; type fahrenheit is float;

c := f; /* no error and no warning here */

... you would end up with a miscalculation that will lead to unpredictable behaviour, depending on the type of application and system this could lead to serious financial loss or even death. Such a logical bug is also very difficult to track down without strict name equivalence in place.