Enso Date shall be converted to java.time.LocalDate when passed to Java

[JaroslavTulach]

Pull Request Description

This PR provides a unit test, an integration test and code changes to guarantee automatic conversion of java.time.LocalDate to Enso Date atom and back.

Originally (after the first few commits) the following test failed:

sbt:runtime> testOnly *DateTest*
 - should compare dates in java *** FAILED ***
[info]     org.enso.interpreter.test.InterpreterException: class com.oracle.truffle.polyglot.PolyglotMap cannot be cast to class java.time.chrono.ChronoLocalDate (com.oracle.truffle.polyglot.PolyglotMap is in module org.graalvm.truffle of loader 'app'; java.time.chrono.ChronoLocalDate is in module java.base of loader 'bootstrap')
[info]     at java.base/java.time.LocalDate.compareTo(LocalDate.java:139)
[info]     at <enso>.argument<1>(<interactive_source>:3)
[info]     at <enso>.<eval>(Unknown)
[info]     at <enso>.Debug.eval(Unknown)
[info]     at <enso>.Test.main(Test:6)
[info]     at org.graalvm.sdk/org.graalvm.polyglot.Value.execute(Value.java:841)

then this PR seeks to provide a fix. The PR has been enhanced with another test that sends java.time.LocalDate back to Enso and fails with:

 - should check java date has enso methods *** FAILED ***
[info]     org.enso.interpreter.test.InterpreterException: Method `year` of java.time.LocalDate could not be found.
[info]     at <enso>.Test.main(Test:7)
[info]     at org.graalvm.sdk/org.graalvm.polyglot.Value.execute(Value.java:841)

Now all the unit as well as integration tests pass OK.

Important Notes

Checklist

Please include the following checklist in your PR:

• [ x ] The documentation has been updated if necessary.
• [ x ] All code conforms to the Scala, Java, and Rust style guides.
• All code has been tested:
  • [ x ] Unit tests have been written where possible.

[CLAassistant]

All committers have signed the CLA.

[jdunkerley]

Think this would convert any Atom where first field is a LocalDate, which feels wider.

The original problem, I was meaning was coercing Standard.Base.Data.Time.Date to java.time.LocalDate and vice versa when we cross over the polyglot boundary.

I don't believe this fix would do anything when coming back with a LocalDate to Enso.

[kustosz]

We need to put more thought into API design here.

[jdunkerley]

I agree with @kustosz suggestion.

I think we probably need to make Date/DateTime/Time part of the built in space, but it would be also helpful to control how an Enso Atom is converted across the boundary. This clearly needs some API design.

[JaroslavTulach]

I don't believe this fix would do anything when coming back with a LocalDate to Enso.

Right, it didn't do anything. Thanks for pointing that out, James. Since d4a8e31 it is tested.

I think we probably need to make Date/DateTime/Time part of the built in space,

As soon as the engine encounters a foreign object that represents a date, it needs to wrap it/convert it/mimic it by Enso Date. That means either that the Engine knows about the Date atom or its shape or ...

helpful to control how an Enso Atom is converted across the boundary. This clearly needs some API design.

...there is an API between the Engine and the Date library that allows it to enhance foreign object that claim to be isDate().

I guess I try to hack something first and then we can think of proper API to do it nicer.

[JaroslavTulach]

I guess we are ready for another round of review. Thanks in advance for your comments.

[kustosz]

Very nice. Some nitpicks / discussion points inline. Also please make sure it doesn't make things slower.

[JaroslavTulach]

Squashing the commits into:

• the test 413179e
• the fix eee9bf2
• additional doc/import polishing commits

[hubertp]

lgtm

[kustosz]

Looks good, there's just one stylistic choice I disagree with and it seems like code formatting is off in general. Approving, as fixing these shouldn't require another review from me :)