[Feature] Char + String Static Circuit Methods

[gluax]

🚀 Feature

We should have a Circuit for each char and string containing methods we want to have for these types.
Depends on #929.
Depends on #975.
Depends on #976.

Motivation

To allow users to have methods that perform on these types.
This offers a convivence so that users do not have to implement these from scratch.

Implementation

AST

• A way to Inject a Circuit into the AST.
• A way to easily define these methods.
  • I imagine a macro where we write Leo code, and it converts this to the proper AST Nodes. This way, we can have a separate file for each static Circuit type we wish to introduce.

Char Methods

• is_alphabetic - Returns true if the char has the Alphabetic property.
• is_ascii - Returns true if the char is in the ASCII range.
• is_ascii_alphabetic - Returns true if the char is in the ASCII Alphabetic range.
• is_lowercase - Returns true if the char has the Lowercase property.
• is_numeric - Returns true if the char has one of the general categories for numbers.
• is_uppercase - Returns true if the char has the Uppercase property.
• is_whitespace - Returns true if the char has the White_Space property.
• to_digit - Converts the char to the given radix format.
• from_digit - Inverse of to_digit.
• to_uppercase - Converts lowercase to uppercase, leaving others unchanged.
• to_lowercase - Converts uppercase to lowercase, leaving others unchanged.

String Methods

• u8 to [char; 2] hexstring, .., u128 to [char; 32] hexstring.
• Field element to [char; 64] hexstring. (Application can test leading zeros and slice them out if it needs to return, say, a 40-hex-digit string.)
• Apply to_uppercase (see above) to every character.
• Apply to_lowercase (see above) to every character.

Tests

• Compiler test each method introduced.

[gluax]

Realizing an issue here. We cannot implement a static circuit with methods on [char; N]. Meaning we cannot have string methods. This is due to the fact we cannot pass around N size arrays. Leo has to know the size of the array, which is not possible as a user may define any size of string. Thoughts on this issue @acoglio @Protryon?

[acoglio]

Very good point. For now we can just implement the ones with known sizes, such as u8 to [char; 2] hexstring. Turning each character to uppercase or lowercase can be implemented as a loop by the user for now.

[acoglio]

Supporting types parameterized on (constant) values is a feature that's been discussed, and that will help support constant-value-generic functions on arrays in general, but it's a separate feature.

[gluax]

Question, would we rather these circuits live in core.char.function? Similar to how the blake2s hash function is done?

[acoglio]

Sure, that could be another way to go. I don't have strong personal preferences one way or the other. It will be also easy to "move" from one approach to the other in the future if desired: add the new functions, deprecate the old ones, then remove them.

Unless somebody has strong preferences, perhaps we should go with what's easiest. Do you think it's easier to go the core.char-functions route, or define Char and String circuit types with the static methods?

[gluax]

Blocked by #975.

[collinc97]

char and string are currently not supported in Leo v1.6.2.