Email list hosting service & mailing list manager

New draft (#2) of SRFI 214: Flexvectors Arthur A. Gleckler (14 Jan 2021 06:03 UTC)
Re: New draft (#2) of SRFI 214: Flexvectors siiky (14 Jan 2021 11:51 UTC)
Re: New draft (#2) of SRFI 214: Flexvectors Adam Nelson (05 Feb 2021 05:37 UTC)
Re: New draft (#2) of SRFI 214: Flexvectors siiky (08 Feb 2021 00:55 UTC)
Re: New draft (#2) of SRFI 214: Flexvectors Arthur A. Gleckler (08 Feb 2021 01:10 UTC)
Re: New draft (#2) of SRFI 214: Flexvectors siiky (08 Feb 2021 22:35 UTC)

Re: New draft (#2) of SRFI 214: Flexvectors siiky 08 Feb 2021 00:54 UTC

Hi Adam,

> If you want to submit a pull request, you can submit one through the
> usual GitHub process: fork the repo, make changes on your own copy, then
> create a PR to merge the changes in.

Thanks for letting me know! :)

> With that said, although I appreciate the enthusiasm to help, I'm not
> concerned about extra assertions in the sample code. Double assertions
> shouldn't be a problem at all, because (ideally) 'assume' should be a
> no-op in production code.[1] Not that many Schemes actually do this...

Yes, ideally... In CHICKEN, for example, SRFI-145's `assume` expands to
`assert`, and I'm not sure if it can optimise them away. Since this is
the sample implementation, why not smooth out some rougher edges?

> The missing assertions are probably an oversight, not a big deal, but if
> you want to make a PR for it then you can.

I think this is more important than the above, because arguments aren't
checked when they should be. Sure, there's not much difference between
the program failing because of an assert or because of a function being
called with the wrong type later on, but then -- why use `assume` at
all, if it's not used consistently and in all the right places? Why
check this case, and not that one also?

Like I said in my previous email, I would be happy to contribute instead
of just "complaining", but I'm not sure I'll be able to this week,
before 02/13. Let's see... These are really minor points, though, so the
SRFI process should continue either way.

Regards,
André Sá