Re: R7RS scope & yearly editions & language interop Lassi Kortela 11 Sep 2020 15:20 UTC
>>> [...] The unfortunate thing with Scheme is the dearth of actively >>> developed applications. Apps are needed to put library designs to >>> the test. >> >> This is actually a very, *very* bad sign about the state of the Scheme >> world. One I'm planning on addressing at least a bit, but Real Life >> is hitting me very hard for the foreseeable future. > > We have probably more implementations of Scheme than applications > written in Scheme. :) But even with so many implementations, the > competition with other languages is hard because there is usually more > money to maintain high-quality implementations of those languages. > (Another reason why it was very costly to the RNRS process to, well, > alienate Chez and Racket.) All true. A not-insignificant fraction of good programmers are elegance junkies; it perplexes me a bit that more of them are not finding Scheme. When I came to Scheme, I was elated to find that garden-variety Scheme code is as elegant as the programming pearls in most other languages. Elegant code just comes out by default with no special effort. Whatever the reason, I think we should find allies in similar languages. My pet project is to look for ways to bridge Lisp and ML family languages, which have very high cohesion by their nature. It would be wonderful to design a library once and have it work in multiple languages in this family with only a little adjustment. We all solve similar problems anyway. To start with, Scheme and Common Lisp deal with almost the same concepts. A library interface rarely needs to be concerned with the parts where they diverge (basically, continuations and CLOS). A significant part of library design is simply naming things. There's no fundamental reason why different languages couldn't use the same names for equivalent operators. `make-list` or `repeat` makes no difference, but since we have different names in different languages, it makes it costly to switch between them, meaning users of language A are less likely to try out language B even though there is good conceptual cohesion. > Now, this program cannot work because we have to versions of the > record type coming from the two disjoint loadings of the library > (fantastic bar). Good point. The core data types and control flow of Scheme would have to be protected from changes in yearly editions. `define-record-type` should define compatible types, `cons` should make compatible pairs (Racket broke this by separating immutable conses from mutable ones), strings should be compatible, etc.