Declaring and generating fixed sized data type disjoint from all other types, called AGGREGATES.
General other record or object features may be build on top of these aggregates.
(define-datatype <datatype-name> <datatype-info> <designation> (<fieldname-spec> ...))
<datatype-name> is bound to a new datatype and <datatype-info> to a description of this datatype. <designation> describes the datatype. (<fieldname-spec> ...) is a list of field specification. A field specification is either:
It is an error to have duplicated fieldnames.
Field inheritance is optional and could be provided on top of this proposal with the following proposed syntax:
(define-inherited-datatype <datatype-name> <datatype-info> <parent-datatype-info> <designation> (<fieldname-spec> ...))
Returns type designation of type described by <datatype-info>.
Returns corresponding list of fields specification of type described by <datatype-info>.
If <datatype> is of datatype kind, then returns corresponding constructor, switch function (see below) and mutators. <datatype> ensures that the call to create-aggregate-functions is functional, the same aggregate functions are generated if applied to the same <datatype>.
create-aggregate-functions returns 3 functions as values:
make-<aggregate> is a function taking a fixed number of arguments as specified by the <datatype> and returning a new aggregate containing these arguments as aggregate components.
<aggregate>-switch is explained below.
<aggregate>-mutators is an association list from fields symbols to corresponding mutators for fields specified as mutators. A mutator function takes 2 arguments: (<mutator> <obj> <val>) sets corresponding field of <obj> with <val>, if <obj> is not of <aggregate> corresponding datatype kind then an error is signaled.
The data created by make-<aggregate> and selected by <aggregate>-switch are required to conform to <my-datatype> properties. With modules it is possible not to export the datatype value nor the generic aggregate functions but only functions defined on top of them. This way one could have finer control of aggregate usage. The idea is to allow flexibility by exposing only interface functions via modules exports and that it is impossible to rebuild aggregate functions if corresponding datatype (with unique designation) is not exported.
However data are aggregated in order to retrieve many part of it and not only one. Solution 2 requires to perform redundant check for each accessed field and moreover the error in general is fatal to the program execution. Solution 1 alone is unsatisfactory as if an unsafe access procedure is applied to not of the correct kind data then random and unwanted behaviors may appear.
Another solution is to group together data type checking with accessing in a case analysis function (per aggregate types) :
(<aggregate>-switch <aggregate-case> <else-case>) = (lambda (<obj>) ...)
Two cases are possible: if the data <obj> is of <aggregate> corresponding datatype kind then <aggregate-case> function is called with the components of the <obj> data, else <else-case> is called with <obj>.
The idea behind my-datatype-switch function is to open an environment with bindings for corresponding aggregate components.
A data is a variant if it is one kind of a list of aggregates.
For instance, one could view the following classic types as variant:
Convenience macro for variants may be provided as in [see 2]:(define-syntax variant-case (syntax-rules (else) ((variant-case <obj>) (error "variant-case: all case exhausted " <obj>)) ((variant-case <obj> (else <body> ...)) (begin <body> ...)) ((variant-case <obj> (<aggregate-switch> (<var> ...) <body> ...) rest ...) ((<aggregate-switch> (lambda (<var> ...) <body> ...) (lambda (<obj>) (variant-case <obj> rest ...))) <obj>))))
Examples ready to be used with test implementation are available at AggregatesMedernachExamples.
Disjointness issue raised and proposal:
 Jonathan A. Rees. "User-defined data types". Lisp Pointers. 'The Scheme of Things' (column). 1993
For variant-case to destructure records:
 Daniel P. Friedman, Mitchell Wand, and Christopher T. Haynes. Essentials of Programming Languages. MIT Press and McGraw-Hill, 1991.
RTD (datatype) functions:
 Jonathan A. Rees, Norman I. Adams IV and James R. Meehan. "The T manual". Yale University Computer Science Department. 1984.