On 3/31/23 11:31 AM, John Cowan wrote:
>
> My current view is that all we need to do is to remove the reference to
> f8-storage-class, which will have the effect of making the sample
> implementation correct, given that it now supports f16-storage-class.

Strictly speaking the sample implementation is correct, because the
document says:

Implementations with an appropriate homogeneous vector type should
define the associated global variable using make-storage-class.
Otherwise, they shall define the associated global variable to #f.

> However, you haven't yet discussed the merits (if any) of my idea to
> have a `make-f8-storage-class` procedure that accepts two converters and
> returns a new storage class layered on u8-storage-class .  It could be
> generalized to a constructor that accepts a storage class argument as
> well as the converters, perhaps to be called `make-storage-subclass`.
> This is only a convenience function, and if you don't like it I'll drop it.

I like the idea, generally, but I think it's too late to add it to this
SRFI.  I took that approach when implementing f16-storage-class.

Brad