Wasm backend: discussion on Datetime support

[pkel]

The current WIP wasm backend does not support Datetime. This thread is for discussing how we could provide Datetime for the new backend.

Implementing a datetime library from scratch in Wasm, Ergo or Assemblyscript is hard. If we want a reliable Datetime until end of summer, we'll have to find a short cut. The following option come to mind:

1. Let the javascript engine provide a Datetime library.

Pro:

• We could use moment.js as we do on the javascript backend.

Con:

• Not portable to non-js platforms (especially the Wasm spec interpreter).

2. Find a datetime implementation in Assemblyscript, or translate a Typescript implementation to Assemblyscript.

Pro:

• Does not add dependencies.
• Does not increase complexity of the engine.
• Everything but the datetime implementation is in place.

Con:

• I could not find a datetime implementation for Assemblyscript. We probably would have to adapt a Typescript one ourselves.

3. Use another compile-to-Wasm language that has Datetime support (maybe in form of a library), generate a suitable wasm module and call it from the Assemblyscript runtime or the Wasm contract module.

Pro:

• Portable from the runtime perspective.
• We could choose a mature Datetime implementation.

Con:

• Engine has to dynamically link 3 modules instead of 2.
• We add another language to the build process.
• Calling into the datetime lib is probably not trivial (we cannot easily return structs/tuples/strings.)
• Different language has different memory layout and management. More cognitive load / complexity.

[pkel]

Regarding option 3, a possible candidate is Rust's chrono: https://github.com/chronotope/chrono

On a first glance, a chono datetime looks roughly like this:

type datetime = datetime' * timezone
and datetime' = time * date
and date = i32
and time = { seconds: u32; fracs: u32 }
and timezone = i32 (* not sure about this last one *)

If you want a wasm function that returns such a datetime, you would have to allocate some memory (128bit), write the result there, and return a pointer. We currently use the memory management of Assemblyscript. Rust uses something that reflects LLVM conventions (I do not know any details). Making these to environments work together will require some effort.

But, from reading the Ergo documentation is seems that Ergo Datetimes do not have a time zone and fractions of a second. If this interpretation is correct, we might get away with a 64bit representation, e.g.

type ergo_datetime = { seconds: u32; day: i32 }

We could write some wrapper code in Rust, that lifts functions on chrono's datetime to functions on ergo_datetime. Fractions of a second and timezone would be set to a constant. Another wrapper would encode ergo_datetime into a i64 by concatenating seconds and day. We could provide a wasm module interface that does only use wasm primitive types:

of_date_and_time: i32 -> u32 -> i64
to_date: i64 -> i32
to_time: i64 -> u32
...

Communication between the datetime wasm module and the caller (contract or assemblyscript) would be based solely on function call. No memory allocation or copying of structs needed.

We would still have a problem with date_of_string, date_to_string and similar stuff.