Re: multiple read-time conditionals, puzzlement
Robert Goldman <[email protected]> Mon, 13 Mar 2023 16:25:39 -0500
| Newsgroups | gmane.lisp.openmcl.devel |
|---|---|
| Message-ID | <[email protected]> |
I had a correspondence about this a long time ago, but alas I cannot find it (no great keyword choices). Probably the best source I can point you at is this discussion in Franz's Allegro documentation: https://franz.com/support/documentation/10.1/doc/implementation.htm#nested-conditionals-3 Unfortunately, even this discussion does not have pointers to the specification. On 13 Mar 2023, at 16:06, Tim McNerney wrote: > Would someone mind quoting “chapter and verse”? > > Somehow, even those of us with decades of Common Lisp experience, all > trying to follow the drama of the X3J13 committee, a bunch of us > “missed the memo” about this convenient, allegedly legal, but > “buyer beware” syntax. > > Yes, I absolutely hate > #+foo :keyword #+foo argument too. > > --Tim > >> On Mar 13, 2023, at 14:00, Robert Goldman <[email protected]> >> wrote: >> >> >> On 13 Mar 2023, at 12:42, Ron Garret wrote: >> >> Oh, forgot to add... >> >> On Mar 13, 2023, at 10:20 AM, Arthur Cater <[email protected]> >> wrote: >> >> It never previously occurred to me that read time conditionals could >> be nested. >> >> Just because you can do something doesn't mean you should. >> >> rg >> >> I was surprised myself to see >> >> #+foo #+foo >> used to make two s-expressions (in)visible in the presence (absence) >> of the :foo feature. But it's clearly dictated by the spec, and is >> often handy when, for example one might want to have something >> conditionally in a property list >> >> (list :prop1 12 >> #+foo #+foo >> :foo 'bar) >> In my opinion, that's clearer than >> >> (list :prop1 12 >> #+foo :foo #+foo 'bar) >> which obscures reading this as a property list and obscures the fact >> that the two elements of the list are going to be swapped in or out >> based on a single feature. >> >> (append (list :prop 12) #+foo (list :foo 'bar) ) >> is not an alternative particularly pleasing to me, but YMMV. It's >> certainly very busy.