Am Di., 1. Nov. 2022 um 15:22 Uhr schrieb José Bollo <xxxxxx@nonadev.net>:
>
> Le Thu, 27 Oct 2022 10:00:17 +0200,
> Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit :
>
> Hi,
>
> More thoughts to share. Trying to be short.
>
> 1. OO langages mostly allow multiple constructors -with different
> signatures- (many of it -C++, Java- use unique name and overloading,
> shit on it -just may silly opinion-) Anyway it is used so it is of
> interest. Need example?
>
> (define-record-type <sbuf> (!sbuf! len vec) sbuf?
>    (len sbuf-length sbuf-set-length!)
>    (vec sbuf-buffer))
>
> (define (make-sbuf-with-capacity capacity)
>   (!sbuf! 0 (make-vector capacity #\null)))
>
> (define (make-sbuf-from-string string)
>   (!sbuf! (string-length string) (string->vector string)))
>
> My understanding is that protocol of r6rs doesn't give any facility for
> that case. It is intended for inheritance only but restrict its usage
> to a single signature (but okay we can use case-lambda, perhaps).

The procedural layer of R6RS allows you to define as many constructors
as you want; only the syntactic layer is limited (but not in
principle).

The newest draft of SRFI 237 now included "define-record-name", which
is a syntactic facility to define new constructors without defining
new record types.

> 2. define-record-type is not OO. The issues solved by protocol remain
> for methods that are not constructors and are not solved. So the need
> is for constructor only.

What do you mean by "are not solved"?

> I imagine a procedure that wraps children fields to provide a parent
> constructor. It could solve. Let use R6RS's abstract example (p18) with
> SRFI-136 formalism and with some functions foo, bar1 and bar2.
>
> (define-record-type <parent> !parent! parent?
>    (v1 v1) (v2 v2) (v3 v3))
>
> (define-record-type (<child> <parent>) !child! child?
>    (x1 x1) (x2 x2) (x3 x3) (x4 x4))
>
> (define (make-parent v1 v2 . build)
>    (let ((make (if (null? build) !parent! (car build))))
>       (make v1 v2 (foo v1 v2))))
>
> (define (make-child x1 x2 x3 v1)
>    (let ((x4 (bar1 x1 x2 x3 v1))
>          (v2 (bar2 x1 x2 x3 v1)))
>       (make-parent v1 v2 (lambda (v1 v2 v3)
>             (!child! v1 v2 v3 x1 x2 x3 x4)))))
>
> Works but it is not perfect. It has to be forged by the programmer and
> included in the design, it does not comes for free. What comes for free
> is the constructor !child!.
>
> Instead of (lambda (v1 v2 v3) (!child! v1 v2 v3 x1 x2 x3 x4)), a
> facility function could exist:
>  ((record-type-wrap-creator-for-parent <child>) x1 x2 x3 x4)
>
> It is very similar in the approach to protocol. Maybe more flexible.

If I understand your code correctly, it seems that the child record
has to know about the fields of the parent record type, which the R6RS
approach avoids - and allows decoupling implementations.

Anyway, please check `define-record-name' and see whether it solves
your use case.

> And, also, I'm very sorry but I am very happy with the generativity of
> define-record-type in R7RS. It is clear and regular with other parts of
> the language.

You don't have to be sorry. :) Where are you using generative
record-type definitions in practice?

Best wishes,

Marc