But (the following point applying beyond the scope of Frege, and not intended to say anything negative about Frege) it is disappointing that there isn't better interop between JVM and non-JVM languages, so that people are so frequently forced to choose and to duplicate effort between the two worlds. For example, Frege being similar to Haskell, but using Java APIs - it is disappointing that there can't be a cleaner join between the worlds.
> but using Java APIs - it is disappointing that there can't be a cleaner join between the worlds.
Maybe it can. But does it make sense? For example, you'd need a library that emulates the C stdlib functionality that is used in Haskell.
There are more subtle points. For example, in Haskell, you can throw an exception in another thread. You can't do that with JVM threads. I am not sure what it would take to make a JVM runtime system that supports this.
But observe that the more runtime code you have that keeps up the illusion of running a Haskell-RTS, POSIX, C stdlib world, the less you will be able to interact with the rest of the JVM. For, your Strings are not Strings, but lists of characters, your Boolean is a sum type, your Filedescriptors are some abstractions nobody else understands, your threads are not JVM threads, but something that can be interrupted form other such somethings, ... and so on and on.
But (the following point applying beyond the scope of Frege, and not intended to say anything negative about Frege) it is disappointing that there isn't better interop between JVM and non-JVM languages, so that people are so frequently forced to choose and to duplicate effort between the two worlds. For example, Frege being similar to Haskell, but using Java APIs - it is disappointing that there can't be a cleaner join between the worlds.