Hey, thank you for the question! I only started working on version 0.2 a few days ago but I can already share what I am planning with the project. This should hopefully answer your question about third-party support and general customizability.
I only included the essential customization options in version 0.1 because I was hoping to find a better solution to customize the numbers and units. Introducing a parameter for every possible option is obviously the easiest solution, but I don’t think this scales very well. And there will always be someone who wants some obscure formatting option that might need another parameter. If you have ever looked at the option tables in the siuntix manual, you will know what I am talking about.
My plan for version 0.2 is therefore to drop the individual parameters and use functions instead. There will be two categories, “transform” and “format”. Functions in the former category will allow you to change some aspect of the number or unit, e.g. convert the uncertainties to the “absolute” format or round the value. Functions in the latter category will then actually turn the dictionaries into content. The base functions num() and unit() will only have the named positional parameters transform and format and the positional parameter body.
#let num(transform: auto, format: auto, body) = { ... }
#let unit(transform: auto, format: auto, body) = { ... }
If you want to run multiple transformation, you can pass a list of functions that will be executed one after the other. The same works for the formatting if the functions only format parts of the number (or unit).
Let’s say you would like to round your values to three decimal digits and you want to use absolute uncertainties. And for the exponent you would like use sym.dot instead of sym.times as the separator between the base (10) and the value (and uncertainties). The configuration to achieve this would look like this:
#configure(
num-transform: (
round.with(n: 3),
absolute-uncertainties,
),
num-format: (
format-exponent.with(separator: sym.dot),
format-num,
)
)
If you want to change your number or unit in a way that is not (yet) supported by a function in the package, you can then just write your own function(s). The function signature and (schema of) the return value will be the only restrictions.
Regarding your request of using the formatting (and transformation) without the validation and interpretation I want to allow dictionaries as the body for num(), unit() and qty(). The internal functions interpret-num() and interpret-unit() are then just skipped based on the input type. I am not sure yet how restrictive the input format for the dictionaries should be. I think it would be nice if you could just write
num((value: decimal("0.9")))
instead of
num((value: (body: decimal("0.9"), layers: ()), uncertainties: (), exponent: none))
in case you don’t want to use uncertainties, an exponent, or any of the styling options. On the other hand it might be simpler to just support a single format for third-party access to avoid any confusion. I would definitely be interested in hearing your opinion on that!
The last important change will be to use the decimal type instead of strings for any values that are actually a number. This was unfortunately not available when I started working on the project and I didn’t want to worry about it before the initial release since it is only used internally.
I am looking forward to your comments (if you have any) and I hope that I was able to convince you that fancy-units will be the right choice for your chemical units. 