[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Miscellaneous loose ends

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
  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