Review and Release Planning

Confidence Ratings

Each function is given confidence ratings, based on its design and implementation. Overall confidence is their average.

A baseline confidence of 8/10 means a function is good enough to be included in a release. Notes about other reasons to exclude functions may also be made. For example, a function may be good enough technically but its purpose doesn't justify inclusion. Inclusion also doesn't mean the function is design or code complete, just that it's good enough for comment, even if changes are pending based on existing discussion.

The goal here is to help prioritize work and do an initial release of some functionality for user feedback and testing.

See https://github.com/hiiamboris/red-formatting/discussions for design chat related to functions.

Function	Design	Code	Purpose	Overall	L10N req'd	Notes
as-ordinal					Yes†
format-bytes					Yes
form-logic	8/10	8/10	9/10	8/10	Yes
format-number-with-style
format-number-with-mask	7/10	6/10	9/10	8/10
format-number-via-masks
format-date-time	7/10	7/10	10/10	8/10
capitalize	3/10	3/10	3/10	3/10	Yes	Big topic. Complex rule space.
form-num-ex						Wrap basic-number-formatter if/when it exists?
format-string	5/10	5/10
form-num-with-group-seps
format-number-by-width

† as-ordinal requires localization, but the rules will be complex. This hurts its value.

Additional function ideas

Function	Design	Code	Purpose	Overall	L10N req'd	Notes
basic-number-formatter
format-binary
parse-format

Priority Task List

0. Stash format/master branch somewhere, start with a clean master branch and let it contain up to date code only
1. Fill locale data for enUS locale, and maybe special Red locale (for ourselves) that delegates most things to enUS but uses coders' conventions
2. Write general purpose number formatter https://github.com/hiiamboris/red-formatting/discussions/11
3. Write excessive tests for masked number & date formatters
4. Write masked number & date formatters code so tests are passing
5. Write the entry point https://github.com/hiiamboris/red-formatting/discussions/21 and a few tests for it
6. Add another language locale and adapt everything so it works for it too, write some tests, update design if necessary
7. Repeat 6 for a few most common locales, or for all available, and likely make it separate files for inclusion
8. Advertise on red/red channel and in blog
9. Add more formatting functions

Phase 1

set 'format function [
	value [number! date! time! logic!]		; 1*
	fmt   [word! string!] "Named or custom format"	; 2*
]

1. We can add logic! on pass 2, but while https://github.com/hiiamboris/red-formatting/discussions/12 notes L10N, is that critical here? We can add it later, and because of the interface, people can easily provide their own values in the meantime. We want L10N, but there may also be an English bias many places in Red.

2. If we include logic!, we need word! support for the format, and should also update mold-logic3* to take that as a param, rather than using refinements. We can leave out the short/med/long named formats for dates, but I think named standards formats 4*, e.g. ISO8601, are important to include.

3. If we have both form-logic and mold-logic, how do we select the mold version? And if we want to support mold/all as well, that's another branch. This being format, it may be best to leave mold-logic out, providing it as a standalone function.

4. This again raises the question of how to add named formats. If they are just in code, but if we put them in a system/catalog map, refactoring the func as a comment notes, it's just a mapping of name to mask.