Am So., 16. Aug. 2020 um 19:52 Uhr schrieb <xxxxxx@ancell-ent.com>: > > > From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de> > > Date: Sunday, August 16, 2020 12:39 PM > > > > Am So., 16. Aug. 2020 um 19:25 Uhr schrieb <xxxxxx@ancell-ent.com>: > > > >> Urk, still sort of too early in the morning; let's try again: > >> > >> To answer your previous question, when you look at raw alists that > >> have lists as values, they aren't '((key1 . (value1 value2))), > >> the dotted pair just becomes a list, '((key1 value1 value2)). > >> ^ no paren or dot here. > > > > Ah, you mean that it has alternative printed representation. > > But why is that bad? > > Because I generally expect the output to look like the input, e.g. > '(key1 (value1 value2)) => (key1 (value1 value2)) for plists. > > I'm embarrassed to say I spent several minutes puzzling over this before > remembering my beginning lessons about LISP lists. Which were almost > exactly 41 years ago, and lain fallow for ~35 years, but.... > > So following the safe rule that if I can be confused, so can another random > user ^_^, especially an inexperienced one of the sort we want to attract to > R7RS-large for "real world programming".... That would be a general argument against alists. But even if we follow this argument, it probably comes 30 years too late because alists are already pervasive. I strongly recommend not to move from alists to plists in this SRFI, mainly for the following two reasons: (1) The overwhelming majority of SRFIs and APIs use alists in comparable situations. For Scheme as a whole, it makes much more sense to stick to the established convention instead of changing this style in a single SRFI. (2) The existing (higher-order) procedures naturally work on alists but not on plists. This is less due to an impoverished set of procedures for plists but more due to the fact that alists are logically and computationally simpler. Marc PS How is this TI chip called? I'd like to take a look at its specs.
