f8 representation Alex Shinn (17 Feb 2021 10:24 UTC)
Re: f8 representation Bradley Lucier (17 Feb 2021 18:55 UTC)
Re: f8 representation John Cowan (17 Feb 2021 21:33 UTC)
Re: f8 representation Alex Shinn (18 Feb 2021 12:21 UTC)
Re: f8 representation John Cowan (18 Feb 2021 15:29 UTC)
Re: f8 representation Alex Shinn (19 Feb 2021 01:15 UTC)
Re: f8 representation Lucier, Bradley J (19 Feb 2021 01:29 UTC)
Re: f8 representation Alex Shinn (21 Feb 2021 01:16 UTC)

Re: f8 representation Lucier, Bradley J 19 Feb 2021 01:29 UTC

> On Feb 18, 2021, at 8:14 PM, Alex Shinn <xxxxxx@gmail.com> wrote:
>
>   Better to have a separate storage class
> for each variant.

I agree.  That’s sort of what I meant when I spoke of “bespoke” f8 storage classes.

> And whether using parameters or separate variants, f8-storage-class still needs
> a default specification.  I think you want to make it implementation
> defined, but
> then I wonder if it is of any use.  Regardless, as an implementor I
> would like to
> have agreement with other implementors on a sensible default.

The SRFI 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.

I think that allows the default implementation to be #f.

I’m not recommending this, just that it is allowed if there is no reasonable default.

Brad