> I really think we need a definition of functional programing language. I feel that many just see Haskell and other "pure" functional languages as the only functional programming language when I really don't see that is the point (Also Haskell isn't very pure looking at Monads)
I consider FP languages to be those that actively encourage an FP style. We live in a pragmatic world with limits, many times we need to work around those limits and working with totally pure code where side effects are modeled by means of monads is sometimes limiting. However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.
The set of features required is not that big. Of course, for static languages, it would be nice if the language had some form of type classes and higher-kinded types, because that goes well with parametric polymorphism, which blends well with FP. But actually, you can't name a certain feature, other than having first class functions maybe. But the community and the available libraries need to encourage a preponderantly FP style.
I can't say exactly what languages are like this, but I can say that Java does not and it never will.
Higher-kinded types aren't an absolute necessity, and, in fact, they force you to pick between modularity (abstract types) and type inference: https://news.ycombinator.com/item?id=12331926 . Not a very pleasant choice, a programmer normally wants both.
Yes, I already said they aren't a necessity, though many people like having higher-kinded types. But then ML/Ocaml folks seem to be doing fine without. I personally prefer having HKT because you can then neatly express well known type-classes for implementing functors, applicatives, monads and many others.
You can recover the power of higher-kinded types with higher-order functors (in the ML sense), without sacrificing the compatibility of abstract types and type inference in the core language.
On the other hand, Haskell's type inference algorithm is simply incompatible with abstract types.
I didn't fully understand your explanation last time. Can you give an example of the conflict between modularity and type inference with HKTs in Haskell?
I can say that surpisingly R (The fastest growing language with a TON of hate for its warts) is the closest I have seen for your description. Though it really is not a general purpose language.
The closest general purpose language I have been exposed to that fits your description is Racket. Based off of Scheme and has the ability to really make your own language from it, but also has pragmatic pieces to get things done.
Love your definition: However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.
I consider FP languages to be those that actively encourage an FP style. We live in a pragmatic world with limits, many times we need to work around those limits and working with totally pure code where side effects are modeled by means of monads is sometimes limiting. However, in FP languages the FP style should be considered the default and breaking out of that style should be done for optimization reasons.
The set of features required is not that big. Of course, for static languages, it would be nice if the language had some form of type classes and higher-kinded types, because that goes well with parametric polymorphism, which blends well with FP. But actually, you can't name a certain feature, other than having first class functions maybe. But the community and the available libraries need to encourage a preponderantly FP style.
I can't say exactly what languages are like this, but I can say that Java does not and it never will.