You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
icu_collator is fully TR #10 compliant and being in Rust can enable a fast, safe and developer friendly experience. I see the following advantages:
Fast, being NIF and Rust based
Can take advantage of Rustler precompiled to easy installation across different machine types
Fully compliant meaning it supports runtime options to influence ordering which is helpful in several UI situations (and others).
@foxbenjaminfox has kindly offered to work on the Rust bindings while I work on the overall library, Elixir api and documentation.
Elixir Public API
The basic Elixir API (not the NIF API) I envisage as:
Cldr.Collation.sort(list_of_binaries, options) where options is a keyword list. This should only required one NIF round-trip but would require instantiating a new collator on each call. Options can include :locale (the default is Cldr.default_locale/0). Other options would be Elixir expressions of the icu_collator type CollatorOptions.
Cldr.Collation.compare(string, string, options) where is options is a keyword list.
Cldr.Collation.collator(language_tag) which returns a collator (Rust-based resource) that can be reused and may (possibly) we stored in a Cldr.LanguageTag.t/0 struct. Options can include :locale (the default is Cldr.default_locale/0). Other options would be Elixir expressions of the icu_collator type CollatorOptions.
NIF API
This API needs to be as simple as possible and be driven by the needs of icu_collator and Rustler. Hopefully the interface can directly use the binaries in the Rust code without copying but the memory models are different and this may not be possible. Sorting by adjusting pointers would be more efficient than memory copies.
At minimum the NIF API should expect to accept:
List of Elixir binaries being strings to be ordered.
Elixir binaries to be compared
An options list (in a format best determined by the most efficient way to pass options to the Rustler NIF)
A language tag as a binary (probably using Cldr.LanguageTag's :canonical_locale_name field)
It should be able to return:
A list of binaries
Comparison indicators (ie greater than, less than, ....)
Status codes as appropriate
The text was updated successfully, but these errors were encountered:
icu_collator is fully TR #10 compliant and being in Rust can enable a fast, safe and developer friendly experience. I see the following advantages:
@foxbenjaminfox has kindly offered to work on the Rust bindings while I work on the overall library, Elixir api and documentation.
Elixir Public API
The basic Elixir API (not the NIF API) I envisage as:
Cldr.Collation.sort(list_of_binaries, options)
where options is a keyword list. This should only required one NIF round-trip but would require instantiating a new collator on each call. Options can include:locale
(the default isCldr.default_locale/0
). Other options would be Elixir expressions of theicu_collator
typeCollatorOptions
.Cldr.Collation.compare(string, string, options)
where is options is a keyword list.Cldr.Collation.collator(language_tag)
which returns a collator (Rust-based resource) that can be reused and may (possibly) we stored in aCldr.LanguageTag.t/0
struct. Options can include:locale
(the default isCldr.default_locale/0
). Other options would be Elixir expressions of theicu_collator
typeCollatorOptions
.NIF API
This API needs to be as simple as possible and be driven by the needs of
icu_collator
and Rustler. Hopefully the interface can directly use the binaries in the Rust code without copying but the memory models are different and this may not be possible. Sorting by adjusting pointers would be more efficient than memory copies.At minimum the NIF API should expect to accept:
Cldr.LanguageTag
's:canonical_locale_name
field)It should be able to return:
The text was updated successfully, but these errors were encountered: