Scala和Frege（编程范式）之间的主要区别是什么？

Question

Scala and Frege are both typed functional languages that target JVM.

Frege is closer to Haskell, Scala has a more independent history.

But if we don't look at syntactic differences, what are the differences in the allowed programming techniques, styles, concepts between the two?

Answer 1

IMHO both are really good languages but with respect to paradigms, Scala does OO better than Frege but Frege does functional better than Scala. With respect to differences, it comes down to mostly Haskell vs Scala since Frege is (or almost, see differences between Haskell and Frege here ) Haskell for the JVM.

1. Frege's type inference is global so we don't have to annotate types as often as we do in Scala (local inference).

2. In Frege, modules are just namespaces for types and functions whereas Scala has better module system. http://2013.flatmap.no/spiewak.html

3. In Frege, functions are curried by default so there is no need for additional constructs for partial function application. Same goes for partial type constructor application.

4. In Frege, there is no def vs val and everything is function. Hence functions are more first-class than Scala.

5. Frege has no sub-typing but the type system figures out the sub typing on native calls. For example, you can pass an ArrayList to a function which requires a Java List .

   Since there is no subtyping, in Frege we cannot extend a Java class or implement an interface as of now (might be supported in future) so we need to have a Java class which would extend/implement but the method implementations would be passed from Frege as functions.

6. From Scala, it is easy to call Java but in Frege, a Java class/method must be declared (Just the type and purity annotations) before use. For example, to use Java's LinkedList ,

    data LinkedList a = native java.util.LinkedList where native add :: Mutable s (LinkedList a) -> a -> ST s Bool native get :: Mutable s (LinkedList a) -> Int -> ST s (Maybe a) throws IndexOutOfBoundsException native new :: () -> STMutable s (LinkedList a) 

   Here since the functions mutate the object, they must be in ST monad. Also note that here Frege also handles null returned from the get method since it is annotated with Maybe type. The only way null can get through to your Frege program is through native interface since Frege doesn't have a notion of null.

   Another example: pure native floor Math.floor :: Double -> Double

   which states that the function is pure and hence the signature directly reflects the original Java signature without IO or ST .

7. Frege has no variables as in Scala's var and the side effects are more explicit through types. (Just no null , no var and explicit side effects make Frege more interesting, atleast for me. In a sense, Frege, just as Haskell, is a "fine imperative programming language", for the JVM!)

8. Being a Haskell dialect, Frege is more natural towards Functors, Applicatives, Monads and other functional "patterns" and has those in it's standard library whereas in Scala, you might need Scalaz.

9. Frege is lazy by default but strictness can be enabled where necessary through ! whereas Scala is strict by default but has lazy keyword for lazy evaluation.

Nevertheless, being JVM languages, one language can benefit from other. I once ported an Akka example to Frege . In the end, it comes down to strictness, purity, functional, OO and type inference and how much they matter to you.

Answer 2

Apart from syntactical issues, the biggest difference is in the type system and the execution model.

As @senia already pointed out, scala is strict and not pure, which does not mean that you can't write pure functions (you can do that in C, too), just that the compiler won't enforce it.

Frege, OTOH is lazy and pure, which means that all impure effects are forced to live in the ST or IO monad. The type system is essential that of Haskell 2010, with type classes and additional higher rank function types. Type inference works program wide, the only exception are functions with higher rank types, where at least the polymorphic argument must be annotated. Here is an example:

both f xs ys = (f xs, f ys)

For this function, the compiler infers the type:

both :: (α->β) -> α -> α -> (β, β)

Note that both xs and ys get the same type, because of the application of f . But now lets say we want use a polymorphic list function that we can use with differently typed xs and ys. For example, we want to write:

both reverse [1,2,3] ['a' .. 'z']

As it stands, this application would be in error, because the two lists have different element types and hence different types. So the compiler would refuse the character list.

Fortunately, we can tell the compiler more precisly what we want with a type annotation:

both :: (forall e.[e] -> [e]) -> [a] -> [b] -> ([a], [b])

This tells the following: we will pass to both a function that does some list transformation but doesn't care about the list element type. Then we pass 2 lists with possibly different element types. And we get a tuple with our transformed lists back. Note that the code of both needs not to be changed.

Another way to achieve the same would be to write:

both (f :: forall e.[e]->[e]) xs ys = (f xs, f ys)

and the type checker infers the rest, namely that xs and ys must be lists, but can have different element types.

Scalas type system fully (to my knowledge) supports OO. While Frege supports it only partially with regard to types imported for Java, but does not support definition of own OO-like types.

Hence, both languages support functional programming in a JVM environment, although in completly different niches. A third niche is the dynamically typed one, where Clojure is king in the JVM world.

Answer 3

Maybe it's off topic, but Scala can be used to develop Android applications (*), but Frege hasn't been successfully used for that, yet.(**) IIRC, it's because interop with existing Java libraries is much easier in Scala than in Frege, among other issues.

(*) Caveat emptor. I've only done small, example programs myself.

(**) Frege/Java mixes have been used for Android applications, but Frege-only applications are still not available, AFAIK.