<div dir="ltr"><div dir="ltr">Den tors 21 jan. 2021 kl 23:55 skrev Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree that ^ can make some code more <br>
obvious, but I definitely don't want this to be enforced everywhere. <br>
Socket messages, monitors and other message refs, tests and other <br>
similar places would not gain in readability in my opinion. The places <br>
where readability increases are those where matching is not expected, <br>
like most of your examples seem to be. Though in some of those cases a <br>
comment would be much better.<br></blockquote><div><br></div><div>I do agree that this is the main weakness of the suggestion. In many normal cases, the ^-annotation can look superfluous. But it does provide uniformity, over the whole codebase. You know you can trust it, everywhere, and even in a short function it can quickly guide your eyes to see that there's some important matching going on. So I think it can be worth it. But if there's anywhere I have doubts, it's this point - if it's worth having it everywhere, compared to just falling back to guards instead.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You say ^ indicates that the match is intentional, and in a perfect <br>
world perhaps that's true, but in the real world you'll also end up with <br>
misplaced ^ that should not be matches at all, as some of your examples <br>
show.</blockquote><div><br></div><div>Well, those examples had misplaced matches precisely because there was no warning and no requirement for the programmer to state exactly what they meant. If there had been a warning and a requirement to do something (annotation or guard) to silence that warning, the mistake wouldn't have made it there in the first place. That's no differenft from when e.g. the warning for unused variables became default - among the harmless unused variables, it also revealed some existing mistakes in the code;  and nowadays you don't get new mistakes like that because the compiler keeps reminding you. For already-used variables: if you indended it and ^X doesn't exist, you get an error, and if you didn't intend for X to be bound before but it was, you get a warning.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As a result, the ^ alone does not convey much information. You don't <br>
know why the dets:check_file_header/2 function is called twice, a </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
comment would work out much better. (A comment explaining why one call <br>
is protected in a try..catch and one isn't would be great as well.) <br>
Maybe parse_term/3 really does have to return the same "D" value, but ^ <br>
only tells you it's expecting the same value, it doesn't tell you why. <br>
And so on.<br></blockquote><div><br></div><div>Yes, but what I'm saying is that if the author, who presumably did understand why they did something, had been told about these matches by the compiler at the time they wrote the code, they would have been likely to either change the code because it wasn't what they meant, or they would have marked the match as intentional (even if they don't add any further comments), and then we could probably trust that the code works the way it was intended at the time. But as the code stands now, we can only either guess, or try to find them and ask if they can tell whether this is intentional.</div><div><br></div><div>    /Richard</div><div><br></div></div></div>