On Mon, 29 Jun 2020 at 10:42, Claude Pache <claude.pa...@gmail.com> wrote:
> > At this point, I don’t feel strongly, because currently, when I see > “unexpected '''' (T_CONSTANT_ENCAPSED_STRING)”, > my automatism is not looking for a string with specific quote style (which > is not evident by looking at four consecutive quotes), but for a missing or > misplaced punctuation mark, because, by experience, it is most of the time > the root cause of an error message containing that specific token name. > Yes, there's a bunch of cases where what the parser sees and expects isn't really that helpful, and what's parsed as a zero-length string may not actually look that way in the source. There's probably diminishing returns trying to handle that at the message level, rather than extending the parser itself as has been done for mis-matched brackets. > Another way to give the programmer the appropriate information, is > replacing “quoted string” with “single-quoted string” and “double-quoted > string”. > That would actually make a lot of sense. I'll have a look if it can be done without changing the actual parser definitions (which recognise both forms as the same token type). > And while I am thinking about it: a case that tends to cause divergent > squint is: unexpected '"', which you changed into: unexpected token """. In > that specific case, it would be nice if it the common name of the offending > token was spelt out, something like: unexpected double quotation mark. > That would be a reasonable special-case; theoretically, the same would apply for a lone single-quote, although I think the parser happens never to see that as a separate token. Thanks for the feedback, -- Rowan Tommins [IMSoP]
