RecordsConversion

Larceny v0.95 implements the ERR5RS APIs for records. Larceny also supports the R6RS APIs and Larceny's own legacy APIs, but both of these are deprecated for the reasons explained below.

The rest of this page was written before the R6RS was ratified, and before the R6RS and ERR5RS record systems had been fully implemented. This wiki page should be revised to acknowledge the new ERR5RS APIs for records.

---

Warning: The R5.97RS draft, which has been put up as a candidate for ratification, contains several false claims about the relative performance of the procedural and syntactic record layers. In Larceny, for most applications of records, the procedural layer will perform just as well as the syntactic layer.

We believe that will be true in most systems, not just Larceny. Most compiler writers will optimize both procedural and syntactic records, as we are planning to do in Larceny, or will not optimize either.

The R5.97RS claims are particularly unfortunate because they have been used to justify a design in which the procedural and syntactic layers do not interoperate very well. If the R5.97RS draft is ratified, becoming the R6RS standard, then Larceny will designate the R6RS syntactic layer as a deprecated misfeature of the standard, and will recommend that programmers use a more powerful syntactic layer that interoperates with the procedural layer.

This more powerful syntactic layer will probably be the default for Larceny's R6RS-compatible mode, since the only incompatibility between it and the R5.97RS specification is that the R5.97RS requires implementations to raise an exception at macro expansion time if a procedural record definition attempts to inherit from a record type defined by the syntactic layer, or if a syntactic record definition attempts to inherit from a record type defined by the procedural layer. In Larceny's R6RS-compatible mode, those situations will do the right thing without raising an exception or requiring the programmer to resort to R5.97RS-mandated contortions.

---

The procedural and inspection layers of the R5.97RS are implemented in Larceny v0.94 (Doomsday Device), except for inheritance. (The data structures that are already in place should suffice to implement inheritance, but Will gave up on trying to comprehend the intended semantics of inheritance as it was described in the R5.93RS draft. The R5.97RS draft appears to be more comprehensible.)

Since the R5.97RS syntactic layer is controversial (and, in Will's opinion, should not be ratified), Larceny's own code should use only the procedural layer until the R6RS is approved. The easiest way to enforce this policy is to delay implementation of the syntactic layers until the R6RS is approved, but we may want to use some reference implementations that use one of the syntactic layers.

---

There are several apparent conflicts between Larceny's current record system and the proposed R6RS record system:

(record-constructor rtd)                    ; Larceny
(record-constructor constructor-descriptor) ; draft R6RS

(record-accessor rtd field-name)            ; Larceny
(record-accessor rtd k)                     ; draft R6RS

(record-type-field-names rtd)               ; Larceny: returns a list
(record-type-field-names rtd)               ; R6RS: returns a vector

(record-type-descriptor record)             ; Larceny procedure
(record-type-descriptor )      ; R6RS macro

The first three conflicts have been resolved via overloading, and the last can apparently be resolved by binding the to something like a record type descriptor. (Will thought the next-to-last conflict was insoluble, but it wasn't; the record-type-field-names procedure now returns a list for old-style rtds, and a vector for R6RS rtds. Old-style rtds will be impossible to create in R6RS-conforming mode, so we can use the overloaded procedures even in R6RS-conforming mode.)

In case we decide to make an incompatible change to record-type-field-names: It is used in lib/Base/record.sch, lib/MzScheme/record.sch, lib/MzScheme/struct.sch, lib/MzScheme/simple-macros/simple-macros.sch, and lib/Standard/record.sch. It appears that struct.sch is the only real use, and it would be trivial to change that file to accept a vector instead of a list.