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

[Robert Goldman]

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 <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/c4ec6265/attachment.htm>