bug#37659: Mattias Engdegård <mattiase <at> acm.org>

[Mattias Engdegård]

12 okt. 2019 kl. 01.07 skrev Paul Eggert <eggert@cs.ucla.edu>:
> 
> 1. Instead of the symbol 'unordered-or' (which is remarkably hard to read), I 
> suggest using the ASCII letter 'V'. This ASCIIfies the Unicode symbol U+2228 
> LOGICAL OR (∨). If you prefer, you could make the Unicode symbol an alias for 
> 'V', or use lower-case ASCII 'v', or whatever. The point is that 
> '(unordered-or A B)' is too hard to read with all those 'or's in there.

Definitely agree on the imperfections of 'unordered-or', and while I'd be the 
first to welcome more use of Unicode symbols, I'm not sure V (or v, or ∨) are 
very descriptive --- even if an alert reader intuits the rebus of 'V' (perhaps 
via \vee in TeX), there is no hint of the difference from 'or' or '|'.

Other suggestions:

'or*' --- follows the Lisp tradition of appending a star to get a variant and 
informs the reader that it's like 'or' but with a twist. The downside is that 
it might suggest a Kleene closure somehow.

'either', 'one-of', 'choose', 'pick-one', 'alternative', 'alt' --- very 
readable although the relationship to 'or' isn't quite clear. Perhaps they 
suggest a looser sense of ordering?

'unseq-or' --- a bit more readable and phonetically sharper than 
'unordered-or', but it suggest a relation to 'seq'.

'nonstrict-or' --- abuses the familiar programming notion of strictness?

'or-ooo' --- will mostly make sense to the comp-arch crowd.

> Is there a reason this uses (cons (list "[^z-a]") t) rather than '(("[^z-a]") 
> . t) ? I realize neighboring code does something similar, but it's not clear 
> to me why it's important to construct new objects here instead of using 
> literals.

Yes, there is a comment right above explaining that the returned value may be 
mutated (at least one use of mapcan). I tried doing it the other way, but 
neither was clearly better than the other (in performance or style), so I've 
let it stand for now. Nothing I feel strongly about either way.