John, I hope you’d be satisfied to turn things in this direction for a while?
Agreed. I see no conflict at all. I'm confused by the suggestion that
there might be one! This is exactly what I mean when I say this isn't
a zero-sum game. I'm assuming that everyone here knows what that is,
but just in case anyone here *doesn't* know, the link below is for
them.
--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/B2537400-980F-427B-B54E-BFE7A3DD8C20%40nonceword.org.
Thus, I think that instead of flat-out refusing a breaking change, the
correct first step would be to see how much actual code would be
broken by this change, and how difficult it would be to migrate the
broken code. If the answer is very little code would break and it
would be trivial to migrate, then it's a very different situation than
if a lot of code were to be broken and migrating were hard.
Flatt suggests that very little code would break and I feel inclined
to believe that.
No doubt it is subjective. The real question is how the community in
general feels, rather than any one of us individually.
I don't think you do understand correctly. What we have here is an
example of code that is accepted by a mark-antimark implementation,
but fails to compile under a set-of-scopes implementation. Definitely
not silent.
Regarding access to the total body of Scheme code, that is a given.
Nevertheless, the accessible body of open-source code can still be
analysed as a representative sample of the total body of Scheme code.
It would be interesting to know whether SRFI 148's source code, which
squeezes every bit out of what R[67]RS syntax-rules are capable of,
still works when run under the different hygiene model.
What's the story with unit tests? Do most srfi's come with unit tests? Are they extensive or superficial? In my experience, unit tests are a great way to detect breakages caused by seemingly-minor changes.
On 2022-03-12 9:38 a.m., Arthur A. Gleckler wrote:
Unit tests were not always required for SRFIs, but they are required now, with few exceptions.
That's excellent news, as it implies that it might be reasonable to construct (by accretion) a test suite for Large, and for Medium, if that goes ahead. (If Medium happens, then presumably its test suite would be a subset of Large's, so no effort would be wasted.) This in no way need delay the Large and Medium efforts, as the test suite need not necessarily be released at the same time as the corresponding Reports. It also suggests that the unit test framework could be included in Medium, thus encouraging users of the language to adopt this framework. (SRFI 64 could be used, and thus added to an upcoming Large docket.) Furthermore, studying the test suite can help in understanding a given specification.
I recall that Aubrey Jaffer had a test suite for R4RS or maybe
R5RS. Most of his test cases were in fact taken right from the
examples in the corresponding report. That strikes me as an
excellent way to go.
I am well aware of all the objections to unit tests. I spent years managing the teaching of software engineering to software developers in a large multinational company, I heard all the objections. Yes, you can never find all the necessary tests. Yes, some of your tests themselves may be wrong. In any case, a given implementation will still require some extra tests, e.g., for the GC.
But we don't need to let the perfect be the enemy of the good. The implementer gets no benefit (in particular, no certification) apart from a pleasant feeling as their implementation passes the test suite, so the only onus on the authors of the test suite is to do the best job they can. They can't be sued if an implementation that passes the test suite goes on to do fail in a horrible way in production. The fact that there may (almost certainly will) still be bugs lurking around after passing the suite shouldn't stop people from using the suite to catch lower-hanging fruit. And nothing (other than the work required) stops there from being a second, more comprehensive version with even more special fruit-catching goodness.
-- vincent
There are not so many Scheme implementations that can compete with
top-notch implementations of other programming languages, so if R7RS
Large is to become successful as a practical and competitive
programming language, I firmly believe that we have to get these
implementations on board.
(*) A semantic change happened between R5RS and R67RS with respect to
the semantics of the letrec form. The new version fixed the efficiency
problems with the old version