Re: First post and overview for supported SRFIs per (some) Scheme implementations Lassi Kortela 20 Apr 2019 15:08 UTC
> Honestly I'd first like to better understand the itch that packhack > wants to scratch. [...] > And whether it takes me 30 seconds or 3 minutes to find that first hint > will not make a difference if afterwards I anyway need to spend 30 > minutes to 3 hours for a detailed investigation. These are reasonable questions. Indeed there is not much immediate benefit from a global package list, if you have already chosen the Scheme implementation you want to use and just want to use it to solve a particular problem. It's more about 1) Giving a global picture of "all of Scheme" to people who are not yet using Scheme, or people who have not yet chosen what Scheme implementation to use for a project. It looks very good to new people if there is a central place where information about all Scheme projects is collected in a form that is easy to browse. 2) Encouraging portability of packages and collaboration between Scheme implementation / package authors. I am very interested in this, as are some other people (e.g. Göran would like Scheme libraries to be more portable). Currently it's taken for granted that different Scheme implementations have drastically different package collections, but some of us would very much like to change this (by making the existing packages portable to more implementations). This is a lot of work and has no immediate payoff, but I believe it will be one of the most important things to boost Scheme's future success in the 10-20 year time frame. 3) More immediately, a global package listing can help spot gaps in functionality that one didn't notice before. ("Hey, that other implementation has an XYZ package and we don't. Maybe we can port it to our implementation with a few changes.") For example in the Schemeweb project, when people using different implementations got together for a discussion, it became apparent that each implementation has packages the others were not aware of. A discussion then started on how to integrate the best stuff from the different packages into the others. I was very happy with that, and this is exactly the kind of work that I personally think will help Scheme win in the future. > But maybe my workflow as described above is just wrong - and experienced > Schemers know that e.g. relying on snowfort works. Your workflow is probably fine, but if you're focused on immediate goals, that benefits from a very different approach than long-term work :) A lot of this work (schemeweb / schemedoc / etc.) has a long-term focus so it looks kind of weird or pointless from a near-term point of view. > At my whole workplace > there is no other Schemer (that I'm aware of), so I just have no idea > how other people are using Scheme. I've also never met another Schemer at work. This seems to be the usual case for most users. We'd like to try changing that with the long-term work :) > To contribute also at least a bit of concrete information: snowfort > lists around 50 packages, theschemer more than 100. A simple mapping of > names between these package collections will not work, but some external > mapping is required (e.g. theschemer: tsort.scm -> snowfort: slib > topological sort). That's good info. I'll try to see if we can extract something useful from theschemer. They seem like a hard-working bunch. > I think that the > infrastructure for these package collections is just much weaker than it > is for the SRFIs, so more effort has to be spend to fill in the missing > pieces. It will indeed take some effort. I don't know if the infrastructure is actually weaker (I've had a very good experience with both Snow-Fort and Akku even though both are run by only one person), but the package repositories are many and the SRFIs are all in one place, so maybe that's why it looks better for SRFIs. Also SRFIs are better documented since they start from the documentation and are not accepted otherwise :)