This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
I have a few questions regarding the stated rationale for custom constructors/ field initialization. I suspect the reasons for the rationale are not entirely justified, and I think that, in addition to the problem with pattern matching mentioned already, a case can be made for removing this feature: From document: ============== "If the custom field initialization were omitted, it would still be possible to perform custom initialization by writing a separate constructor procedure, which would wrap a record type's actual constructor. However, this creates the need for an extra procedure name which is not part of the record type's definition." * This does not seem compelling, since I have to wrap the constructor anyway in many quite elementary cases due to the limitations on custom field initialization: (define-type real-rational (num denom) (fields num denom)) (define (make-rational x y) (let ((common (gcd x y))) (make-real-rational (/ x common) (/ y common)))) * Why does the same rationale not apply to accessors? For example, why is it important to make an underlying hash table constructor private but not, for argument's sake, an account-balance-set! mutator, or to have to wrap an accessor but not a constructor? Since constructing and accessing are dual, it seems inelegant to treat them differently. * Most Scheme module systems provide a more elegant, orthogonal and uniform alternative for hiding private constructors and accessors/mutators. From document: ============== "... this creates the need for an extra procedure name which is not part of the record type's definition. This means that extensions which deal with the record type's definition (such extensions to support keyword arguments, etc.) don't have access to the record type's actual constructor." * This does not seem correct. As a counterexample, SRFI-57 is exactly such an extension of SRFI-9. It hides the underlying SRFI-9 constructor as follows (schematically): (define-syntax define-SRFI-57-type (lambda (form) (syntax-case form () ((_ name SRFI-57-constructor .....)) (begin (register-constructor #'name #'SRFI-57-constructor) #' (begin (define-record-type name secret-underlying-constructor ........) (define SRFI-57-constructor ........secret-underlying-constructor............) ...... )))) Due to hygiene, |secret-underlying-constructor| is really invisible. Cheers Andre