Fields in selectors should match constructor arguments

[neshtea]

When defining a record-type, the macro should validate the field-names in selectors vector according to constructor arguments.

Example

(define-record-type Schlingel
  (make-schlingel name) schlingel?
  [ein-feld-das-im-konstruktor-nicht-vorkommt schlingel-name])

(def marcus (make-schlingel "Marcus"))
(schlingel-name marcus)  ; => nil

[smoes]

This case should only fail because name is not mentioned in the fields vector, as described in #27

It should not fail, if a field accessor is defined for a field, that is not mentioned in the constructor as in

(define-record-type Foo
   (make-foo) foo?
   [bar foo-bar])

This is perfectly valid and bar defaults to nil.

From SRFI9, which is used as a guide-line:

is bound to a procedure that takes as many arguments as there are s in the ( ...) subform and returns a new record. Fields whose tags are listed with have the corresponding argument as their initial value. The initial values of all other fields are unspecified.

https://srfi.schemers.org/srfi-9/srfi-9.html

[neshtea]

Besides the specification, is there any value in this? I can only imagine cases in which this behaviour is quite nasty (i. e. a typo goes unnoticed).

I understand now why it is implemented like this -- perhaps we could at least add a warning for fields that are not mentioned in the constructor?

[cresh]

+1 for deviating from SRFI9 on that behavior.

[smoes]

While I don't have a strong opinion in either direction, I would argue that there is no risk of nasty behavior, especially not typos (with #27 fixed). All constructor arguments have to be fields (that is, accessors are associated, correspondingly), additional fields default to nil. Compile time arity warnings at constructor calls should take care of the rest.

On the other Hand, constructor functions can be private since a few versions, as far as I remember. That said, there is no need to define a special constructor that defaults fields to nil. We can just make the constructor private and define a custom one within a function of the same module.

[cresh]

The example above is a exaggeration of the actual problem of the subtle typo we actually saw:

(define-record-type Schlingel
  (make-schlingel name) schlingel?
  [nam schlingel-name])

(def marcus (make-schlingel "Marcus"))
(schlingel-name marcus)  ; => nil

In a record with many fields such a typo is hard to spot and usually the programmer assumes the source of the nil value to be caused by some broken argument of a constructor call, which may lead to costly debugging of completly different parts of the logic. This would be totally avoidable.

[smoes]

The provided example should actually fail, a fix was implemented in #27. Constructor parameters not associated to fields are indeed considered a bug according to SRFI-9.

We are currently discussing the presence of additional fields, that are not associated to parameters of the constructor, as in:

(define-record-type Schlingel
  (make-schlingel name) schlingel?
  [name schlingel-name
   color schlingel-color])

(def marcus (make-schlingel "Marcus"))
(schlingel-name marcus)  ; => "Marcus"
(schlingel-color marcus)  ; => nil

This example is valid code, even after #27.