[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Constructor rationale questions

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 

* 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

  (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 .....))
           (register-constructor #'name #'SRFI-57-constructor)
              (define-record-type name secret-underlying-constructor 
              (define SRFI-57-constructor
  Due to hygiene, |secret-underlying-constructor| is really invisible.