Calling native Java constructors from Frege

Question

Do you know where I can find documentation about Frege's Java bindings? Coming from Haskell, I find that the most interesting aspect of Frege. The documentation that I found unfortunately does not go into detail very much.

Here is my test example. Basically, I want to translate the following Java code:

BigDecimal x = BigDecimal.valueOf(7);
BogDecimal y = new BigDecimal("5.13");
System.out.println(x.add(y));

Here is my current Frege code:

module Main where

data JBigDecimal s = pure native java.math.BigDecimal
  where
  pure native jAdd add :: JBigDecimal RealWorld -> JBigDecimal RealWorld -> JBigDecimal RealWorld
  pure native jShow toString :: JBigDecimal RealWorld -> String

pure native jBigDecimalI java.math.BigDecimal.valueOf :: Int -> JBigDecimal RealWorld

-- ERROR: Here, I don't know what I should write.
-- I want to bind to the BigDecimal(String) constructor.
-- I tried several versions but none of them was successful, e.g.:
pure native jBigDecimalS java.math.BigDecimal.BigDecimal :: String -> JBigDecimal RealWorld

main :: [String] -> IO ()
main args = let x = jBigDecimalI 7
                y = jBigDecimalS "5.13"
                z = JBigDecimal.jAdd x y
            in printStrLn $ (JBigDecimal.jShow z)
-- (BTW, why `printStrLn` and not `putStrLn` as it is called in Haskell?)

Just for completeness, the error message is:

calling: javac -cp fregec-3.21.jar:. -d . -encoding UTF-8 ./Main.java 
./Main.java:258: error: cannot find symbol
        return java.math.BigDecimal.BigDecimal(
                               ^
  symbol:   method BigDecimal(String)
  location: class BigDecimal
1 error
E frege-repl/example.fr:15: java compiler errors are most likely caused by
    erronous native definitions

Answer 1

I found it. The constructor is called new:

pure native jBigDecimalS new :: String -> JBigDecimal RealWorld

Answer 2

BTW, you don't need the RealWorld everywhere. You have a pure native data type, and you apply pure native functions only.

In addition, it turned out that the phantom type convention you use here will not play well when we sometimes support Java Generics. Then we'll have something like

data List a = native java.util.LinkedList

where we want the a with kind * map to the generic type parameter. This will not mix well wit state thread indicating phantom types, though.

Therefore (comming soon!) we'll have a type to tag mutable values, it is like

abstract data Mutable s a = Mutable a

so one can never actually construct/deconstruct a Mutable. This should work so that only native functions can create values of type Mutable s a (in the IO or ST monad), and it will then be possible to make a safe copy with freeze where one gets a supposedly immutable a back. But this one can then not be passed to impure functions that demand a Mutable s a.

But again, as you work with immutable data, just BigDecimal is enough (and this is not going to change).