4 ms·

Allowing foreign code doesn’t change the purity of the language. By default in Haskell, an FFI declaration must be in IO, e.g: -- int frob(int, char*)

Allowing foreign code doesn’t change the purity of the language. By default in Haskell, an FFI declaration must be in IO, e.g: -- int frob(int, char*) foreign import ccall "frob" frob :: Int -> CString -> IO Int If you know such a function to be pure, you can use unsafePerformIO to tell the type system: refrob :: Int -> CString -> Int refrob x y = unsafePerformIO (frob x y) If you lie to the type system and tell it that an impure function is pure, then all bets are off.

lexicalscope 11y ago
I guess that was my question - if they are making it use FFI as in Haskell, since it's Haskell-like not actual Haskell, or if it's something else that's specific to their JVM version.
- voxfrege 11y ago
  It is an FFI, though with different syntax, and much richer. Not only functions, but also foreign (in Frege its called "native") types. Which is indispensable IMHO when you interface a OO language where everything is classes and interfaces. The different syntax should not be a big issue, as Haskell code that uses FFI targeting C is per se not portable.
voxfrege 11y ago
> If you know such a function to be pure, you can use unsafePerformIO to tell the type system Better yet, if you know it to be pure, you can give it an appropriate type and just use it in pure code, like: pure native cos java.lang.Math.cos :: Double -> Double which should be roughly equivalent to: foreign import jvm "java.lang.Math.cos" cos :: Double -> Double except that no Haskell compiler that I know implements the "jvm" calling convention, for obvious reasons. In fact, all primitive operations, types and so on are defined this way in the Frege Prelude.
dustingetz 11y ago
Worth pointing out that this approach isn't particularly helpful when wrapping mutable Java objects, because Java land still has a reference and can/will mutate the object right underneath us. So we still need to write our Fredge code in ST.
- voxfrege 11y ago
  Yes, that is true. But it is also not as relevant as one might think. Consider how many Haskell programs actually use mutable C data, or export functions that take a foreign ptr to some mutable stuff. Why should this be generally different in Frege? Useful Java APIs will be wrapped and sanitized through Frege libraries, and that is it then. You can go directly to Java, just like you can directly go to C in Haskell, but it turns out one rarely actually does this.
  - dustingetz 11y ago
    > You can go directly to Java, just like you can directly go to C in Haskell, but it turns out one rarely actually does this. This might be the reason that haskell has not enjoyed nearly the adoption of Scala and Clojure.

lexicalscope 11y ago

I guess that was my question - if they are making it use FFI as in Haskell, since it's Haskell-like not actual Haskell, or if it's something else that's specific to their JVM version.

voxfrege 11y ago
It is an FFI, though with different syntax, and much richer. Not only functions, but also foreign (in Frege its called "native") types. Which is indispensable IMHO when you interface a OO language where everything is classes and interfaces. The different syntax should not be a big issue, as Haskell code that uses FFI targeting C is per se not portable.

voxfrege 11y ago

> If you know such a function to be pure, you can use unsafePerformIO to tell the type system Better yet, if you know it to be pure, you can give it an appropriate type and just use it in pure code, like: pure native cos java.lang.Math.cos :: Double -> Double which should be roughly equivalent to: foreign import jvm "java.lang.Math.cos" cos :: Double -> Double except that no Haskell compiler that I know implements the "jvm" calling convention, for obvious reasons. In fact, all primitive operations, types and so on are defined this way in the Frege Prelude.

dustingetz 11y ago

Worth pointing out that this approach isn't particularly helpful when wrapping mutable Java objects, because Java land still has a reference and can/will mutate the object right underneath us. So we still need to write our Fredge code in ST.

voxfrege 11y ago
Yes, that is true. But it is also not as relevant as one might think. Consider how many Haskell programs actually use mutable C data, or export functions that take a foreign ptr to some mutable stuff. Why should this be generally different in Frege? Useful Java APIs will be wrapped and sanitized through Frege libraries, and that is it then. You can go directly to Java, just like you can directly go to C in Haskell, but it turns out one rarely actually does this.
- dustingetz 11y ago
  > You can go directly to Java, just like you can directly go to C in Haskell, but it turns out one rarely actually does this. This might be the reason that haskell has not enjoyed nearly the adoption of Scala and Clojure.