[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Miscellaneous loose ends
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
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
- 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