Am Sa., 8. Okt. 2022 um 00:02 Uhr schrieb John Cowan <[email protected]>:
> On Fri, Oct 7, 2022 at 4:20 AM Marc Nieper-Wißkirchen <[email protected]> > wrote: > >> (define (foo-x foo) (if (%foo? foo) (%foo-x foo) (%foo-x (%bar-foo foo)))) > > > To be fair, this is pretty likely to be inlined, which eliminates most of the > cost, especially if the type checks can also be removed. Inlining cannot eliminate the cost of the extra indirection that is necessary when the types/fields are composed by hand and not using the inheritance mechanism. It's the difference between struct foo { /* ... */ }; struct bar { struct foo *x; /* ... */ }; and struct foo { /* ... */ }; struct bar { struct foo x; /* ... */ }; >> (instead of exporting the record name "sq" to be used in record-type >> definitions of child types, the "sq" package would have to define and >> export a syntax like "define-sq-type" that encapsulates everything >> related to defining child types). > > > The object bound to the name of the record-type can contain whatever > information is necessary to inherit from the record-type, surely. This > appears to be how Chicken's srfi-99 egg works. Of course. But if you do this generally, you won't end up with a model simpler than the one of SRFI 76/R6RS. > However, another advantage of protocols is that the fields not directly > initialized by the constructor can be computed in the constructor rather than > in a separate factory procedure. > >> See above why this would still make the SRFI 9-style syntax >> considerably inferior to the R6R-style syntax. > > > Another possibility is that the R7RS-small syntax be extended to allow > "protocol proc", where proc is the *name* of a protocol procedure rather than > an arbitrary expression evaluating to a protocol procedure. This could make the syntax more readable. On the other hand, it can make it less comfortable to use because one always would have to invent a name when a protocol is needed. (But one could introduce a naming convention.) It should be as easy as possible to add a protocol because, as I said, argument checking should always be done (to maintain invariants and to make debugging much easier). > >I think this is a good suggestion. Those who want implicit names (for >> >> whatever reasons) can always use the R6RS-style form of the syntax. >> And those like Daphne who "hate" implicit names get a domain where >> explicit names are guaranteed. > > > Just so. (I don't like implicit names either, for the same reason that I > don't like anaphoric `if`: names should not appear out of nowhere without > having been declared. I use implicit names in well-known contexts, but there has to be some benefit.
