This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
On Thu, 6 Oct 2005, Michael Sperber wrote:
Andre van Tonder <andre@xxxxxxxxxxxxxxxxxxx> 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