Am Sa., 26. Nov. 2022 um 11:02 Uhr schrieb José Bollo <jo...@nonadev.net>: > > Le Thu, 3 Nov 2022 14:17:53 +0100, > Marc Nieper-Wißkirchen <marc.nie...@gmail.com> a écrit : > > [snip] > > > This works if your record types are only defined in the top level of a > > library, and your library is only loaded once. > > Page 28 r7rs states: > > Regardless of the number of times that a library is loaded, > each program or library that imports bindings from a li- > brary must do so from a single loading of that library, re- > gardless of the number of import declarations in which it > appears. > > From that I understand that for getting a well defined > non-generative record, library is to be used and that is enough, IMHO.
There was once a discussion about this a few years ago. If a program imports both library A and library B and A and B import C, the above makes it clear that both A and B each only observe one loading of C, but it is not clear that A and B observe the same loading. A reasonable implementation of R7RS should guarantee this IMHO. As soon as the extent of record values crosses program boundaries, the generative records of R7RS at the top level would no longer emulate non-generative ones. (We discussed possible extensions of Scheme where this would be possible.) For the small language without extensions, not having non-generative record types outside the top level may be an annoyance, but we can still live without them. Things become different when we take extensions of our language into account. Such an example could be as simple as a feature to unload and reload a library (say, through `eval'). > > > Conversely, you started a thread "Perpetuity of non-generative > > > record type definitions". Between the lines it indicates that being > > > non-generative might be a nightmare to implement. > > > > No, it's not a nightmare to implement them. > > Hum!? Well, let say it is more complicated. And for me it does not bring > a clear benefit. The critical point is that those programs not using non-generative record types don't have to pay any tax in the form of a slowdown or a higher memory footprint. Not restricting non-generative record types to the top level is, at least for me, reason enough to introduce this virtually zero-cost feature. In any case, this particular mailing list is probably not the perfect place to lobby for removing non-genericity. By that, I mean that SRFI 237 is about refining the R6RS record system so that it retains its expressiveness but taking the criticism of it into account. As non-generativity is a feature of the R6RS record system, even if I wanted, it would be against the spirit of this SRFI to remove it. Besides, this SRFI proposes an external representation for records; this, however, is only meaningful for non-generative ones.
