bug#68509: 30.0.50; pcase-dolist matches backquote pattern incorrectly

[Ihor Radchenko]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> +For example, the above pattern will result in...
>>
>> This is confusing. In particular, "for example" implies that other
>> situations are possible. It is unclear how the reader will know when
>> "variables bound to arbitrary values" happen, when variables are bound
>> to nil, and when an error is signaled.
>
> This part of the doc is generic, so it can't guarantee anything: the
> behavior depends on the actual pattern and the way that pattern is defined.
> In order to intuit what will happen, the reader needs to guess which
> primitives are used to extract the info from value (e.g. `car/cdr/nth`
> for cons cells, `aref` for arrays, ...).

I do not think that "guess" is what we should ever put into docs.
Because implementation details may change and any kind of guess may then
go wrong.

>> I would re-structure the paragraph, explicitly listing the possible
>> outcomes when the PATTERN does not match VALUE and stating that any
>> other non-matching PATTERN will lead to undefined outcome.
>
> Could you try to do that?
> [ I've found back-and-forth modifications of docs give better results
>   than single-sided writing.  ]

I could, but I am not sure which non-matching outcomes we should
document and which we want to leave undefined.

I still don't have a clear picture about the differences between normal
pcase and destructuring pcase. Especially for non-trivial patterns.
For example,

(pcase-let (((and `(,a ,b ,c) (guard (eq a 'foo))) '(bar a)))
  (list a b c)) ; =>'(bar a nil)

is extremely confusing.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>