4 ms·

Object Algebras are a nice solution to the expression problem for OO languages: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas

Object Algebras are a nice solution to the expression problem for OO languages: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf (LtU discussion: http://lambda-the-ultimate.org/node/4572 http://lambda-the-ultimate.org/node/4572 ) Operations are implemented in a class with a method for each data type. Data is created via factories. Adding data types is done by adding new factory methods, possibly by extending another factory. Adding new operations is done by adding operation methods, possibly by extending existing operation classes. The paper is quite accessible and the patterns are simple and familiar. The paper goes into type safety and composing algebras.

naasking 10y ago
Unfortunately, no OO languages save Scala implement the higher kinded types needed to truly exploit object algebras.
- pron 10y ago
  I don't know what you mean by "fully exploit", and maybe there are other, nicer, solutions, but object algebras were specifically designed for Java/C# type systems. The entire idea is predicated on that: This paper presents a new solution to the expression problem that works in OO languages with simple generics (including Java or C#). A key novelty of this solution is that advanced typing features, including F-bounded quantification, wildcards and variance annotations, are not needed.
  - platz 10y ago
    it can be easily implemented in mainstream languages like Java and C#." https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
  - naasking 10y ago
    > I don't know what you mean by "fully exploit", If the return type of one of your overloads is itself a generic type, you can't represent that in the type of the method. Consider the IntBoolFactory from the paper, and then add two operations for lambda abstraction and function application: public Exp lambda(Exp=>Exp body); public Exp apply(Exp lambda, Exp arg); Where Exp=>Exp represents a Java lambda taking an Exp and returnin an Exp. Notice how the type of the lambda and its argument must now be dynamically type checked to ensure that 'arg' has the same type as the parameter for the lambda. With higher kinded types, you could write something like this instead: public <T0, T1> Exp lambda(Exp<T0>=>Exp<T1> body); public <T0, T1> Exp<T1> apply(Exp<T0,T1> lambda, Exp<T0> arg); And now everything is statically type checked by the Java compiler. Without higher kinded types, you gain extensibility in every direction using object algebras, but you lose some type checking.
    - naasking 10y ago
      That actually should read: public <T0, T1> Exp<T0, T1> lambda(Exp<T0>=>Exp<T1> body) But you get the idea.

naasking 10y ago

Unfortunately, no OO languages save Scala implement the higher kinded types needed to truly exploit object algebras.

pron 10y ago
I don't know what you mean by "fully exploit", and maybe there are other, nicer, solutions, but object algebras were specifically designed for Java/C# type systems. The entire idea is predicated on that: This paper presents a new solution to the expression problem that works in OO languages with simple generics (including Java or C#). A key novelty of this solution is that advanced typing features, including F-bounded quantification, wildcards and variance annotations, are not needed.
- platz 10y ago
  it can be easily implemented in mainstream languages like Java and C#." https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
- naasking 10y ago
  > I don't know what you mean by "fully exploit", If the return type of one of your overloads is itself a generic type, you can't represent that in the type of the method. Consider the IntBoolFactory from the paper, and then add two operations for lambda abstraction and function application: public Exp lambda(Exp=>Exp body); public Exp apply(Exp lambda, Exp arg); Where Exp=>Exp represents a Java lambda taking an Exp and returnin an Exp. Notice how the type of the lambda and its argument must now be dynamically type checked to ensure that 'arg' has the same type as the parameter for the lambda. With higher kinded types, you could write something like this instead: public <T0, T1> Exp lambda(Exp<T0>=>Exp<T1> body); public <T0, T1> Exp<T1> apply(Exp<T0,T1> lambda, Exp<T0> arg); And now everything is statically type checked by the Java compiler. Without higher kinded types, you gain extensibility in every direction using object algebras, but you lose some type checking.
  - naasking 10y ago
    That actually should read: public <T0, T1> Exp<T0, T1> lambda(Exp<T0>=>Exp<T1> body) But you get the idea.