Miscellaneous loose ends
Andre van Tonder
(22 Sep 2005 15:20 UTC)
|
Re: Miscellaneous loose ends
Michael Sperber
(06 Oct 2005 17:31 UTC)
|
Re: Miscellaneous loose ends Andre van Tonder (06 Oct 2005 18:50 UTC)
|
Pains from duplicate field names [Miscellaneous loose ends]
Michael Sperber
(07 Oct 2005 06:15 UTC)
|
Re: Pains from duplicate field names [Miscellaneous loose ends]
Andre van Tonder
(07 Oct 2005 13:03 UTC)
|
Re: Pains from duplicate field names [Miscellaneous loose ends]
Andre van Tonder
(07 Oct 2005 13:36 UTC)
|
Re: Miscellaneous loose ends Andre van Tonder 06 Oct 2005 18:49 UTC
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