Re: [PATCH 0/3] Clarify built-in library/SRFI feature behaviour

[felix . winkelmann]

> Hi folks,
>
> After thinking about #1788 a little bit more I've came up with a few
> small "code clarity" patches. They don't change the existing solution at
> all, they're just to simplify the code after looking at it with fresh
> eyes. Partly, I realised the naming of that "required-libraries" wasn't
> great, but I also liked that I'd originally been able to simplify
> `##sys#process-require` so it only returned a single value, and wanted
> to see if we could preserve that. I think the result is nice and tidy,
> see if you agree.
>
> Looking into this also made me realise that all of the short-circuiting
> we do when handling require forms for built-in libraries wasn't actually
> necessary, since we can avoid hitting that code path altogether by
> simply not adding libraries for those, which is patch number two.
>
> And then, once I was already down that rabbit hole, I went through all
> of the SRFI-related feature identifiers to make sure they were
> registered in the right files, and that the documentation was up to
> date. That's patch number three, have a look and let me know what you
> think.

As far as I can tell builtin-features has simply been dropped. How do you
avoid having 'srfi-9 as a requirement?

I also don't fully understand why you try so hard to void the multiple value
return of ##sys#process-require. It's not particularly elegant, I admit, but
it looks like the obvious solution here to centralize the decision of what
to do with a requirement ID.


felix