Email list hosting service & mailing list manager

Re: First post and overview for supported SRFIs per (some) Scheme implementations Peter Bex (12 Apr 2019 09:59 UTC)

Re: First post and overview for supported SRFIs per (some) Scheme implementations Peter Bex 12 Apr 2019 09:59 UTC
On Fri, Apr 12, 2019 at 12:49:28PM +0300, Lassi Kortela wrote:
> > > a standardized S-expression file that each implementation could put in its
> > > source release to tell things like what SRFIs are supported
> >
> > I think this is not very useful.  In CHICKEN, for example, a large number
> > of SRFIs are implemented as eggs (add-on libraries), often by third party
> > uthors (ie, people not working on the core system).
>
> That's a good point. I didn't realize that. So the implemented SRFIs would
> be a union of the implementation's official release and package manager(s).
> (Also it's conceivable that an implementation would only support a SRFI on a
> particular OS or with optional build flags.)
>
> I scraped together a list of all the packages in Akku, Chicken 4 and 5,
> Gauche, Guile and Snow-Fort here: <http://lassi.io/temp/packhack.html>. This
> could be turned into S-expressions.

For CHICKEN, we already have an s-expression based list of eggs, it's
what our own infrastructure uses:
http://bugs.call-cc.org/browser/project/release/4/egg-locations and
http://bugs.call-cc.org/browser/project/release/5/egg-locations

They can be checked out via SVN also, see
https://code.call-cc.org/#eggs-repository

> I don't know if there would be a reliable way to include information about
> implemented SRFIs in there. Maybe there could be a standardized package
> metadata file. It ought to be designed by people who have a lot more
> experience with Scheme than I do.

I think that's a bit of overkill, TBH.  And different implementations
will use different formats anyway (unless there will be a single package
manager to rule them all).

Cheers,
Peter