Am Sa., 8. Okt. 2022 um 00:02 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Fri, Oct 7, 2022 at 4:20 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> 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.