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
