[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