Email list hosting service & mailing list manager

Constructor rationale questions Andre van Tonder (19 Sep 2005 16:28 UTC)
Re: Constructor rationale questions Michael Sperber (20 Sep 2005 10:39 UTC)
Re: Constructor rationale questions Andre van Tonder (20 Sep 2005 15:57 UTC)
Re: Constructor rationale questions Michael Sperber (20 Sep 2005 16:22 UTC)
Re: Constructor rationale questions Andre van Tonder (20 Sep 2005 16:46 UTC)

Constructor rationale questions Andre van Tonder 19 Sep 2005 16:28 UTC

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