[erlang-questions] behavior of lists:append/1

[mko]

Hi, Richard,

Thanks for explaining the fascinating tradition behind append/1 in Lisp and Prolog. 

I totally agree with you on the simplicity and performance aspect of append/1 and append/2. I doesn’t make sense at all to add the O(n) check for “proper list”.

I remember when I was following a beginner tutorial on Prolog, I’ve found the append/1 confused me same as Karlo.  I think most people including me is confused append/1 with something like flat (not lists:flatten/1) or chain in other languages like the the new addition: flat method of Array in Javascript:

>[[1, 2], 3].flat()
 [1, 2, 3]

>[[1, [2]], 3].flat()
[1, [2], 3]

>[1].flat()
[1]

>[].flat()
[]

it only “flat” once instead “flat” all the way like erlang lists:flatten/1 does

I think it fit to into people’s mindset about “flat once” of an ordered collection and return the same type.

simple implementation in erlang would be:

flat([]) -> [];
flat([[]|T]) -> flat(T);
flat([[H1|T1]|T]) -> [H1|flat([T1|T])];
flat([H|T]) -> [H|flat(T)].

>flat([[1,2],3]).
[1,2,3]

>flat([[1, [2]], 3]).
[1,[2],3]

>flat([1]).
[1]

>flat([]).
[].

The only thing inconsistent is that as you pointed out several times there's no easy way to check the list is a “proper list” without walking to the end of the list, 

> flat([1|2]).
** exception error: no function clause matching lists2:flat(2) 

but I think it’s ok to skip the “proper list” checking and let dialyzer or programmer handle it as you suggested, and so maybe it’s good to add flat/1 to the lists module and make it a clear separation  of append/1 and  flat/1 which maybe a concept a lot of programmer already familiar with .

mko

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190919/e3ae2cb4/attachment.htm>