Як ви кодуєте алгебраїчні типи даних мовою C # - або Java?

Існують деякі проблеми, які легко вирішуються алгебраїчними типами даних, наприклад, тип списку може бути дуже коротко виражений як:

data ConsList a = Empty | ConsCell a (ConsList a)

consmap f Empty          = Empty
consmap f (ConsCell a b) = ConsCell (f a) (consmap f b)

l = ConsCell 1 (ConsCell 2 (ConsCell 3 Empty))
consmap (+1) l

Цей конкретний приклад є в Haskell, але він би був подібний в інших мовах із вбудованою підтримкою алгебраїчних типів даних.

Виявляється, є очевидне відображення підтипу в стилі OO: тип даних стає абстрактним базовим класом, а кожен конструктор даних стає конкретним підкласом. Ось приклад у Scala:

sealed abstract class ConsList[+T] {
  def map[U](f: T => U): ConsList[U]
}

object Empty extends ConsList[Nothing] {
  override def map[U](f: Nothing => U) = this
}

final class ConsCell[T](first: T, rest: ConsList[T]) extends ConsList[T] {
  override def map[U](f: T => U) = new ConsCell(f(first), rest.map(f))
}

val l = (new ConsCell(1, new ConsCell(2, new ConsCell(3, Empty)))
l.map(1+)

Єдине, що потрібно поза наївним підкласом - це спосіб закріплення класів, тобто спосіб унеможливити додавання підкласів до ієрархії.

Як би ви підійшли до цієї проблеми такою мовою, як C # або Java? Два камені спотикання, які я виявив, намагаючись використовувати алгебраїчні типи даних у C #, були:

• Я не міг розібратися, як називається нижній тип у C # (тобто я не міг розібратися, що вкласти class Empty : ConsList< ??? >)
• Я не міг знайти спосіб закріплення, ConsList щоб ніякі підкласи не могли бути додані до ієрархії

Який був би найбільш ідіоматичний спосіб впровадження алгебраїчних типів даних у C # та / або Java? Або, якщо це неможливо, що було б ідіоматичною заміною?

Існує простий, але важкий спосіб запечатати класи на Java. Ви ставите приватний конструктор в базовий клас, після чого робите підкласи внутрішніх класів цього.

public abstract class List<A> {

   // private constructor is uncallable by any sublclasses except inner classes
   private List() {
   }

   public static final class Nil<A> extends List<A> {
   }

   public static final class Cons<A> extends List<A> {
      public final A head;
      public final List<A> tail;

      public Cons(A head, List<A> tail) {
         this.head = head;
         this.tail = tail;
      }
   }
}

Візьміть за схемою відвідувача для відправки.

Мій проект jADT: Java Algebraic DataTypes генерує для вас усі ці шаблони https://github.com/JamesIry/jADT

Ви можете досягти цього, використовуючи шаблон відвідувача , який доповнить відповідність шаблону. Наприклад

data List a = Nil | Cons { value :: a, sublist :: List a }

можна записати на Java як

interface List<T> {
    public <R> R accept(Visitor<T,R> visitor);

    public static interface Visitor<T,R> {
        public R visitNil();
        public R visitCons(T value, List<T> sublist);
    }
}

final class Nil<T> implements List<T> {
    public Nil() { }

    public <R> R accept(Visitor<T,R> visitor) {
        return visitor.visitNil();
    }
}
final class Cons<T> implements List<T> {
    public final T value;
    public final List<T> sublist;

    public Cons(T value, List<T> sublist) {
        this.value = value;
        this.sublist = sublist;
    }

    public <R> R accept(Visitor<T,R> visitor) {
        return visitor.visitCons(value, sublist);
    }
}

Герметизація досягається Visitorкласом. Кожен з його методів оголошує, як деконструювати один із підкласів. Ви можете додати більше підкласів, але це доведеться реалізовувати acceptта викликати один із visit...методів, тож він повинен або поводитись так, Consабо подобається Nil.

Якщо ви зловживаєте параметрами з назвою C # (введені в C # 4.0), ви можете створювати алгебраїчні типи даних, які легко узгоджуються:

Either<string, string> e = MonthName(2);

// Match with no return value.
e.Match
(
    Left: err => { Console.WriteLine("Could not convert month: {0}", err); },
    Right: name => { Console.WriteLine("The month is {0}", name); }
);

// Match with a return value.
string monthName =
    e.Match
    (
        Left: err => null,
        Right: name => name
    );
Console.WriteLine("monthName: {0}", monthName);

Ось реалізація Eitherкласу:

public abstract class Either<L, R>
{
    // Subclass implementation calls the appropriate continuation.
    public abstract T Match<T>(Func<L, T> Left, Func<R, T> Right);

    // Convenience wrapper for when the caller doesn't want to return a value
    // from the match expression.
    public void Match(Action<L> Left, Action<R> Right)
    {
        this.Match<int>(
            Left: x => { Left(x); return 0; },
            Right: x => { Right(x); return 0; }
        );
    }
}

public class Left<L, R> : Either<L, R>
{
    L Value {get; set;}

    public Left(L Value)
    {
        this.Value = Value;
    }

    public override T Match<T>(Func<L, T> Left, Func<R, T> Right)
    {
        return Left(Value);
    }
}

public class Right<L, R> : Either<L, R>
{
    R Value { get; set; }

    public Right(R Value)
    {
        this.Value = Value;
    }

    public override T Match<T>(Func<L, T> Left, Func<R, T> Right)
    {
        return Right(Value);
    }
}

У C # такого Emptyтипу ви не можете мати , тому що внаслідок модифікації базові типи відрізняються для різних типів членів. Ви можете лише мати Empty<T>; не так корисно.

У Java у вас може виникнути Empty : ConsListчерез стирання типу, але я не впевнений, чи не перевірила б типова перевірка.

Однак, оскільки обидві мови є null, ви можете вважати, що всі їх посилання є "Що б не було". Таким чином, ви просто використовуватимете null"Порожню", щоб не вказувати, що вона отримує.

Єдине, що потрібно поза наївним підкласом - це спосіб закріплення класів, тобто спосіб унеможливити додавання підкласів до ієрархії.

На Java ви не можете. Але ви можете оголосити базовий клас приватним пакетом, що означає, що всі прямі підкласи повинні належати тому ж пакету, що і базовий клас. Якщо потім оголосити підкласи як остаточні, вони більше не можуть бути підкласами.

Я не знаю, чи це вирішить вашу справжню проблему, хоча ...

Тип даних ConsList<A>може бути представлений як інтерфейс. Інтерфейс відкриває єдиний deconstructметод, який дозволяє "деконструювати" значення цього типу - тобто обробляти кожен з можливих конструкторів. Виклики deconstructметоду аналогічні case ofформі в Haskell або ML.

interface ConsList<A> {
  <R> R deconstruct(
    Function<Unit, R> emptyCase,
    Function<Pair<A,ConsList<A>>, R> consCase
  );
}

deconstructМетод приймає функцію «зворотного виклику» для кожного конструктора в ADT. У нашому випадку вона займає функцію для випадку порожнього списку та іншу функцію для випадку "проти комірки".

Кожна функція зворотного виклику приймає в якості аргументів значення, які приймає конструктор. Таким чином, випадок "порожній список" не бере аргументів, але випадок "проти комірки" має два аргументи: голова та хвіст списку.

Ми можемо кодувати ці "кілька аргументів" за допомогою Tupleкласів або використовуючи currying. У цьому прикладі я вирішив використовувати простий Pairклас.

Інтерфейс реалізується один раз для кожного конструктора. По-перше, у нас є реалізація для "порожнього списку". deconstructРеалізація просто викликає emptyCaseфункцію зворотного виклику.

class ConsListEmpty<A> implements ConsList<A> {
  public ConsListEmpty() {}

  public <R> R deconstruct(
    Function<Unit, R> emptyCase,
    Function<Pair<A,ConsList<A>>, R> consCase
  ) {
    return emptyCase.apply(new Unit());
  }
}

Потім аналогічно реалізуємо випадок "проти комірки". Цього разу клас має властивості: голова та хвіст не порожнього списку. У deconstructреалізації ці властивості передаються consCaseфункції зворотного виклику.

class ConsListConsCell<A> implements ConsList<A> {
  private A head;
  private ConsList<A> tail;

  public ConsListCons(A head, ConsList<A> tail) {
    this.head = head;
    this.tail = tail;
  }

  public <R> R deconstruct(
    Function<Unit, R> emptyCase,
    Function<Pair<A,ConsList<A>>, R> consCase
  ) {
    return consCase.apply(new Pair<A,ConsList<A>>(this.head, this.tail));
  }
}

Ось приклад використання цього кодування ADT: ми можемо записати reduceфункцію, яка є звичайним складанням списків.

<T> T reduce(Function<Pair<T,A>,T> reducer, T initial, ConsList<T> l) {
  return l.deconstruct(
    ((unit) -> initial),
    ((t) -> reduce(reducer, reducer.apply(initial, t.v1), t.v2))
  );
}

Це аналогічно цій реалізації в Haskell:

reduce reducer initial l = case l of
  Empty -> initial
  Cons t_v1 t_v2  -> reduce reducer (reducer initial t_v1) t_v2

Єдине, що потрібно поза наївним підкласом - це спосіб закріплення класів, тобто спосіб унеможливити додавання підкласів до ієрархії.

Як би ви підійшли до цієї проблеми такою мовою, як C # або Java?

Це не дуже хороший спосіб зробити це, але якщо ви готові жити з огидним хаком, ви можете додати деяку явну перевірку типу до конструктора абстрактного базового класу. У Java це було б щось на кшталт

protected ConsList() {
    Class<?> clazz = getClass();
    if (clazz != Empty.class && clazz != ConsCell.class) throw new Exception();
}

У C # це складніше через перероблені дженерики - найпростішим підходом може бути перетворення типу в рядок і mangle.

Зауважте, що в Java навіть цей механізм теоретично можна обійти тим, хто дійсно хоче через модель серіалізації або sun.misc.Unsafe.