On Thu, 6 Oct 2005, Michael Sperber wrote:

> Andre van Tonder <xxxxxx@later.het.brown.edu> writes:
>
>> - Why do the field /name/s in the procedural layer /not/ need to be
>>   distinct?
>>   I could see this feature causing lots of pain.
>
> What kinda pain?

- Keyed data structures are usually easier and less error-prone to program with
   if the keys are unique.

- It seems to preclude implementations based on hash-tables,
   since keys are not unique.

- It has higher conceptual overhead since records cannot be thought of
   as simple dictionaries (or perhaps chained dictionaries in the case of
   inheritance).

- Instead, the current design makes positional indexing an irreducible
   part of what it means to be a record, which somewhat complicates the
   usually simple theoretical model of records as labeled products.

- It is easy to forget, when manipulating type descriptors,
   that field labels are not unique.  Since they usually will be,
   the potential is there for obscure bugs that may take a long
   time to discover.

- Generic programming is more difficult.
   Writing e.g. a generic record-copy or polymorphic record update
   cannot be done by straightforward iteration over field labels, since
   RECORD-ACCESSOR will only return the first field accessor for a given label.
   Instead, with the current interface one has to determine the length of the
   field label multiset and then do an index-based iteration.

- Extensions such as pattern matching and constructors by label are
   problematic in principle and more subtle to implement, since there are fields
   that are inaccessible by label.

- Operations on label sets (union, intersection, difference, sorting) such as
   those I used in SRFI-57 become more subtle if label sets are not actually
   sets.

Cheers
Andre