> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de> > Date: Sunday, August 16, 2020 1:39 PM > > 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. And unlike mainline LISP, plists are very much not so in Scheme. > 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. OK. And this is a strong argument to have make-foreign-status and raise-foreign-error continue taking alists as arguments as in Draft #3), not changing them to plists. I'm OK with either, the rest of you can hash this out. > PS How is this TI chip called? I'd like to take a look at its specs. MSP430 FR5994: https://www.ti.com/product/MSP430FR5994 Search on Launchpad for the development board and the MSP430 ecosystem. The free/open/free to use software ecosystem is pretty good, GCC and their own compiler, "Code Composer Studio" Eclipse based IDE that knows their CPUs's quirks and ... ah ha, does its best to keep hardware engineers doing software out of trouble, shall we say, forum with TI people who answer questions, etc. TI really wants to make it easy to use their chips, just avoid their RTOS from everything I've read. - Harold
