Thank you, I didn't know Chibi supported minifloats, and I don't know
much about floating-point formats outside of the IEEE 754 standard.

 > I see f16 mentioned in the spec, but not f8 (i.e. minifloats
<https://en.wikipedia.org/wiki/Minifloat>.) Is that intended?

The 16-bit floating point format "binary16" was standardized in IEEE
754-2008. There is no IEEE 754 8 bit floating point format, so I did not
specify it. The naming scheme "binary⟨n⟩" is reserved for future IEEE
formats, so there may be a "binary8" format in the future.

 > So yeah, I’m not particularly pushing this, as the choice of
particular f8 might be unpopular. But there’s a need for standardization
here, as there’s at least one implementation that already supports f<16.

This SRFI was designed to be accommodating of different choices for
different formats.

For example, if one wanted to support E5M2, one could provide the library

(srfi 276 minifloat-1.5.2)

This is explicitly allowed in the SRFI. The operations exported from the
library are not specified: it might not make sense for a minifloat to
implement the gamma function or some of the other special functions.

Similarly one could provide (srfi 276 minifloat-1.4.3), (srfi 276
minifloat-1.4.3-2), (srfi 276 minifloat-1.2.1)

One can also support different formats for the defined sizes. One could
provide (srfi 276 posit32) for 32-bit posits, (srfi 276 arm16) for ARM's
derivative 16bit FP format, or (srfi 276 double-double) for a 128-bit
format using two binary64 numbers.

I have avoided specifying non-IEEE formats because I don't know enough
to fix a naming convention. (E5M2 or minifloat-1.5.2 or something else?)
If there is consensus around a specific set of minifloat operations,
then those could be added to a follow-up SRFI.

-- Peter McGoron