Haskell vs Scala – Object-Oriented Counterpart to Haskell and Coq

dhaskellscala

I have detailed information on the latest developments in functional programming.

I think haskell is quite an advanced and high level programming language. With coq and agda this gets even more complex and advanced.

With "advanced" and "high level" I mean many distinct features, that can only be found in the respective languages.

Like for haskell

everything is pure and lazy per default
support for advanced concepts like GADTs, Monads, Functors, etc.

For coq / agda

a dependent type system

And both haskell and coq are used in academics, a good sign that they are 'state-of-the art'.

However I have no clue what comparable developments in object oriented programming are.

What are some of the latest developments in object oriented programming?

What would be a state-of-the-art OOP language counterpart to haskell / coq?

(I even search for advanced programming language on google, but I found mostly haskell related information. The only language I could think of is D 2.0. Scala is for me mainly a java compatible version of haskell.)

Best Answer

Subtyping (i.e., any static object-oriented type system) is so much more complex than any "flat" type system typical for the functional languages. It is nearly impossible to formalise it properly. For this reason, no surprise that we have not heard yet about, say, dependent object-oriented type systems.

Probably, a single early example of such an attempt would be this paper.

Related Solutions

The logic behind the use of different arrows (-> <-) in Haskell

I've also always found it kind of odd that regular functions are defined with = but lambdas with ->. Why not use the arrow for both? Or the equals for both?

The equality symbol makes sense for named function definitions because it states that applying the named function to its arguments is equivalent to evaluating the right hand side of the equation. Defining lambdas that way makes no sense notationally: x = x + 1 implies x is equal to its successor, which can't be true.

The left arrow gets used in do notation as something similar to variable binding, in list comprehensions for the same (I'm assuming they are the same, as list comprehensions look like condensed do blocks), and in pattern guards, which have the form (p <- e).

All of those constructs bind a new variable. Using = here would not make much sense either, because a statement such as x = x + 1 implies that x refers to the same thing on both sides. A variable binding introduces a new x that's distinct from any x that may occur in the right hand side.

One alternative would've been to just use -> and place the variable on the right, but I believe placing it on the left is objectively more readable in cultures that read left to right. You scan text by moving your eyes along the left margin and thus placing all the variables on the left makes them easier to find. And although having two different symbols for variable bindings may not seem consistent, there's consistency in the position of the variable that gets bound; it's always on the left.

So that just leaves the question of why <- as opposed to some other symbol like :=. I don't know, but I can guess. Look at what desugared monadic code looks like:

[1, 2, 3] >>= \xs -> map (*2) xs

Considering that >>= with its arguments swapped is called =<<, it probably seemed natural to use a left-facing arrow.

What Does the => Symbol Do in Haskell?

The => is just there as a delimiter between context and type when you write a type signature. They aren't even saved after compilation. You can see it here: http://www.haskell.org/onlinereport/syntax-iso.html

Related Topic