[Openmcl-devel] multiple read-time conditionals, puzzlement

Tim McNerney mc at media.mit.edu
Mon Mar 13 14:06:33 PDT 2023


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 <rpgoldman at sift.info> 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 <arthur.cater at ucd.ie> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20230313/230a71f0/attachment.htm>


More information about the Openmcl-devel mailing list