<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">"Not checking for whether something is a properly formed list (the whole <br>
objection some have is that append/2 should be able to accept an <br>
improper list as the second argument) but merely checking whether the <br>
second argument is a list of any form at all."</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">But what the heck is the point of *that*?</div><div class="gmail_default" style="font-family:monospace,monospace">Why is it important for  [a] ++ c to fail</div><div class="gmail_default" style="font-family:monospace,monospace">but OK for [a] ++ [b|c] to succeed?</div><div class="gmail_default" style="font-family:monospace,monospace">I'm sorry, but that makes no sense to me at all.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Sep 2019 at 18:58, zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019/09/19 10:33, Richard O'Keefe wrote:<br>
> I'm sorry, but what O(1) runtime check are we talking about here?<br>
> I don't know of any O(1) way to test "is this a proper list" in<br>
> Erlang.<br>
<br>
Not checking for whether something is a properly formed list (the whole <br>
objection some have is that append/2 should be able to accept an <br>
improper list as the second argument) but merely checking whether the <br>
second argument is a list of any form at all.<br>
<br>
A single is_list/1 check guarding the leading clause can do that.<br>
<br>
The discussion has gone through:<br>
<br>
A1: "The typespec says both arguments must be lists"<br>
B1: "Use Dialyzer"<br>
<br>
A2: "The check should be dynamic at runtime"<br>
B2: "Checking for *proper* lists is too much overhead"<br>
<br>
A3: "We should accept improper lists as a second argument"<br>
B3: "Then is_list/2 could check the 2nd arg on entry only"<br>
<br>
A4: "Some people use append/2 to *construct* improper lists"<br>
B4: "Then why do we even have a typespec at all?"<br>
<br>
My position is that B2 and A3 are valid, and B3 is a reasonable <br>
compromise that shouldn't break legacy code. I think A4 is unreasonably <br>
inconsistent, though, and would wonder why we're even going to have a <br>
typespec.<br>
<br>
-Craig<br>
</blockquote></div>