christripledot

Take a look at the patch below... If you feed [zl slice] a list with the word "list" in it, and the right output slice begins with "list", it is munched up and only the elements after "list" come out the right outlet...

bug-in-zl-kind-of

because "list" is not a valid element #1 for lists.

lists in fact do start with "list" even if you dont see it.

the same can happen to you with the symbols "bang" and "set" in many max objects.

because "list" is not a valid element #1 for lists. 

I thought that would be the case - I've noticed that behaviour with "bang" and "set".

But is there a workaround for the problem above? I don't need one, it's purely academic!

aside from that I don't think there's a workaround, it's simply a reserved word that behaves functionally in certain circumstances...

a workaround would be to use a placeholder; i.e. where you want to tranport "(list) list 2 3 4 5 bubu"

you can send "(list) l!st 2 3 4 5 bubu" and laterm after splitting elemte #1 off the list, replace the first

but because there are no max objects which would take a command called "(list) something something"

you should not need lists beginning with "list".

if you own abstractions require such lists, i would say they are misconfigured. :)

a workaround would be to use a placeholder; i.e.  where you want to tranport "(list) list 2 3 4 5 bubu"
you can send "(list) l!st 2 3 4 5 bubu" and laterm after splitting elemte #1 off the list, replace the first
symbol "l!st" with "list".

but because there are no max objects which would take a command called "(list) something something"
you should not need lists beginning with "list".

Bug in [zl]... kind of