Re: Making SRFI go faster Lassi Kortela 26 Apr 2021 06:45 UTC
> I'm concerned that this dramatically underrates the importance of > having some kind of specification for a library (or any software). > A project that emerges through gung-ho programming alone is likely > to be incomprehensible to other programmers who may want to > contribute (and probably to the author, a few months later). > > Maybe this is my own preference showing (I always try to work out a > spec and a formal semantics first), but I think that even an informal > and protean specification is beter than no specification at all. To > paraphrase Conal Elliott, I'd like these libraries to be precise about > 'what', not just 'how'. I too often start solving a problem by writing a draft spec, and find that it clarifies thinking a lot. But there are situations where it doesn't make sense. Sometimes it's better to just get something out the door. This tends to be the case when the problem is either really well understood (i.e. the spec is obvious), or really poorly understood (i.e. no use writing a spec about guesses and stabs in the dark). In terms of deliverables, if stable releases were to be cut from Scheme Live at intervals, those releases should be defined by a spec document, and ship with the code at that point in time as a sample implementation of the spec. (I.e. just like SRFI in this respect, but probably without the rationale sections, unless someone is keen to write them.) The question then is how to arrive at this document. It will be just a file in version control, so in principle nothing stops people from editing that file whenever they like. If you like to go spec first, you could edit the doc first until you're happy with it, and then write the code. Someone who prefers to implement first could do that. IMHO the right approach would be informally discovering a process that works for the participants. If only one person works on HTML parsing for example, and that person likes implementing first, then they should work on those parts that way. Otherwise we'd have no HTML parsing library, which IMO is a bigger loss. If we have a parsing library that sucks but gets the job done, can always fix it later, keeping in mind that the process if tolerant of mistakes. > Related to comprehensibility is the issue of the monorepo. What's > the advantage of this approach? I second John's point about the > difficulty of cleanly extracting subtrees; this is especially a > problem if any (sub)library were to become a SRFI. Committing and > testing a monorepo seem likely to become very time-expensive, as well. > Why not multiple repos, perhaps with Git submodules? The main point of a monorepo is that changing module boundaries becomes easy. Another point is to get people invested in the whole, avoiding a situation where everyone picks their favorite parts and doesn't run the rest. This approach ensures that a cohesive whole eventually emerges, not only a self-assembly kit of good parts. For testing the whole collection, CI is a big help. When programming locally, the test runner should let people run only parts of the full test suite. Not sure what you mean by committing being slow; git isn't slow with the kinds of repo sizes we'd be likely to hit. Echoing many people's experience with git submodules, I'd have to say "now you have two problems". > In summary, I'd like a Scheme Live library collection to be clear, > well-defined, and easy to work with. A large monorepo of unspecified > in-progress libraries sounds like the opposite. That would be everyone's goal, but we may disagree on how to get there. We may only disagree in degree, not in kind.