<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Briefly, the problem with</div><div class="gmail_default" style="font-family:monospace,monospace">append(Xs, Ys) when is_list(Ys) -></div><div class="gmail_default" style="font-family:monospace,monospace">    combine(Xs, Ys).</div><div class="gmail_default" style="font-family:monospace,monospace">is that is_list/1 ***ISN'T A TYPE CHECK FOR LISTS***.</div><div class="gmail_default" style="font-family:monospace,monospace">It is misnamed.</div><div class="gmail_default" style="font-family:monospace,monospace">is_list([_|_]) -> true;</div><div class="gmail_default" style="font-family:monospace,monospace">is_list([])    -> true;</div><div class="gmail_default" style="font-family:monospace,monospace">is_list(_)     -> false.</div><div class="gmail_default" style="font-family:monospace,monospace">Try is_list([a|b]).</div><div class="gmail_default" style="font-family:monospace,monospace">The result is true, despite [a|b] not being a list.</div><div class="gmail_default" style="font-family:monospace,monospace">Unsurprisingly, (LISTP '()) and (LISTP '(1 . 2)) are</div><div class="gmail_default" style="font-family:monospace,monospace">true in Common Lisp.   There is an interesting</div><div class="gmail_default" style="font-family:monospace,monospace">difference between Common Lisp and Scheme:</div><div class="gmail_default" style="font-family:monospace,monospace">(list? '(1 . 2)) is false in Scheme.  But the</div><div class="gmail_default" style="font-family:monospace,monospace">Scheme function takes O(|list|) time.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Oddly enough, since Erlang is strict and functional,</div><div class="gmail_default" style="font-family:monospace,monospace">it *would* be possible for Erlang to tag pairs whose</div><div class="gmail_default" style="font-family:monospace,monospace">tail is a proper list differently from pairs whose</div><div class="gmail_default" style="font-family:monospace,monospace">tail is *not* a proper list, with small constant</div><div class="gmail_default" style="font-family:monospace,monospace">overhead.  *That* is what it would take to have an</div><div class="gmail_default" style="font-family:monospace,monospace">affordable is_really_a_well_formed_list/1.</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 Tue, 17 Sep 2019 at 01:54, 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/16 11:49, Richard O'Keefe wrote:<br>
> The fact that L is a well-formed list is verified N times,<br>
> for a total cost O(N * |L|).  But with the current definition,<br>
> the cost is O(N), independent of |L|.<br>
<br>
Hm... just to beat a dead horse...I suppose we could get away with a <br>
single check:<br>
<br>
   -export([append/2]).<br>
<br>
   append(Xs, Ys) when is_list(Ys) -> combine(Xs,Ys).<br>
<br>
   combine([X | Xs], Ys) -> [X | combine(Xs, Ys)];<br>
   combine([],       Ys) -> Ys.<br>
<br>
> I will say that I've been using languages in the Lisp family for<br>
> a little over 40 years, and this has been the very *least* of my<br>
> problems.<br>
<br>
The whole issue boils down to the above. I can see some trivial merit in <br>
doing a type check over Ys at the outset (since we'll crash on bad Xs in <br>
the actual procedure) but this business of moving to the last element to <br>
check whether the list is properly formed is both insane and almost <br>
certainly a legacy code killer, as there are a handful of systems out <br>
there that depend on being able to manipulate improper lists for <br>
whatever reason.<br>
<br>
I didn't follow this thread closely, but I'm surprised I didn't see <br>
doing a single type check on entry as a possibility. What issues would <br>
make this a bad idea?<br>
<br>
-Craig<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>