Le Tue, 1 Nov 2022 15:33:44 +0100,
Marc Nieper-Wißkirchen <xxxxxx@gmail.com> a écrit :

Hello,

> 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 mean "calling precursor method in a redefined method in inheriter
class", as offered by some OO languages. Maybe still not clear. If in a
class B inheriting A we redefine the method foo but to implement it, we
need to invoke the origin method foo of A.

It is really not a scheme paradigm but it is near in its mechanism to
the problem we are debating.

> > 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.

Yep and that is why I proposed the function with that very long name:
record-type-wrap-creator-for-parent. That function, given the type name
automatically returns the correct lambda.

Its signature is

  RECORD-TYPE
       --> proper fields of the childs
              --> parent fields of parent
                      --> created record instance

It could also be that signature

  RECORD-TYPE and proper fields of the childs
       --> parent fields of parent
              --> created record instance

But a generic function could do the job:

 (lambda (child-constructor)
     (lambda child-args
         (lambda parent-args
              (apply child-constructor
                     (concat parent-args child-args)))))

Or something similar. Having a specialized function could help to check
the count of arguments.

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

I'm not sure to understand it clearly. It looks like a syntactic sugar,
not like a real behaviour.

> > 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?

Well, in my usage, it doesn't care if it is generative or not. Both are
achieving the same behaviour.

I believe that turning generative type to non generative type can be
achieved using a correct decomposition in libraries. But I may be wrong,
I have no experience in providing any libraries of interest.

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.

Best regards
José

> Best wishes,
>
> Marc