Add ord/chr functions

[neil-da]

Requested by @raphael-speyer-da and @andrae-da so they can pack/unpack strings. Concretely, something like Text -> [Int] and [Int] -> Text, or on single Int, or something around that area.

[neil-da]

@bitonic - what's your thoughts on this request?

[bitonic]

@neil-da I'd be OK with it, I think Text -> [Int] makes the most sense.

[neil-da]

As a roadmap for adding new primitives: https://github.com/digital-asset/daml/pull/1346/files

[remyhaemmerle-da]

1 - (naive question) Why explode and implode are not good enough ?

2 - Do we really want non type safe conversion ? I mean, wouldn't it better to introduce a proper Unicode Char type ?

3- In case we go for Int, what do we do when given invalid code points in input ?

• throw an error ?
• use the replacement character \ufffd https://en.wikipedia.org/wiki/Specials_(Unicode_block) ?

Note we have to be sure no subrogate (codepoints ranging from 0xd800 to 0xdfff) ends up in our strings, otherwise we will have troubles with or java UTF16 encoding.

[ndmitchell]

Working with characters as code points is soemtimes useful. Implode/explode don't let you do that, and Char is only useful if you can work on it as an Int too, so you might as well use Int and if people want some tiny extra type safety do it in DAML as a newtype.

I would suggest error on invalid input, since it's a pretty low level function anyway so people should pay attention.

[remyhaemmerle-da]

Therefore we will have to new builtins:

• FROM_TEXT_CODEPOINTS: Text -> [Int64]
• TO_TEXT_CODEPOINTS: [Int64] -> Text

The later will crash if it finds an Int64 which is not between 0x0000 and 0xd7ff or between 0xe000 and 0x10ffff (bounds included).

[remyhaemmerle-da]

The two builtins are now available in DAML-LF dev version.
Language team can start to integrate to be accessible from the surface language.

This will be integrate in DAML-LF 1.6 together with enum type.

[bitonic]

I believe this is done now that #1536 is merged.