Now have a look at pack without the symbol boxes ,

When pressing the second and third toggle , the console says : expected symbol but got "x" or "-" ( there is no symbol box involved ) .
When pressing the first toggle , the "- "or "x" is send and received , does the pack see this as a symbol ? ( if so how can we examine this )
Furthermore , why doesn't it see the second and third as a symbol ?
This is were it's so cumbersome to actually see what's going on under the hood ..

Now I change the first argument of pack to integer , so pack = i s s , then the console says : Pack_symbol wrong type
From this I can conclude that the first message is indeed interpreted as a symbol (and rejected because it expected an integer ) , so why do the next and third inlet need an explicit symbol box , and why doesn't PAK need any at all ?

Just when I got the hang of lists and it's selectors , I bump into new issues

But what if the first inlet is not a list it unpacks, like in my examples ?

the cold inlets are generic and expect symbols, not 'anything's. That's why you have to convert them to symbols with [symbol].

However, the 'hot' (leftmost) inlet does accept 'anything's, and converts them to symbols

@ oid , interesting
How did you find out that pack works like that ,( not that I doubt your expertise at all ) ?

Max has this wonderfull object in the pack family called join ( not zl - join ) it accepts everything no matter the selector .
You just give it the nr of input arguments and the hot inlet port ( all if needed )
Really wish pd has someting like that

static void pack_anything(t_pack *x, t_symbol *s, int ac, t_atom *av)
{
    t_atom *av2 = (t_atom *)alloca((ac + 1) * sizeof(t_atom));
    int i;
    for (i = 0; i < ac; i++)
        av2[i + 1] = av[i];
    SETSYMBOL(av2, s);
    obj_list(&x->x_obj, 0, ac + 1, av2);
}

you have to get into a few functions, but basically the argument 's' is the 'selector' (in this case '-' or 'X'), 'ac' is the count of items in the list (after the selector) and *av is the pointer to the atoms that make it up.

first, it allocates a new list of atoms of length of the input elements (elements after the selector, in this case 0) + 1 = 1

then it shifts all the input elements up by 1, and inserts the selector as a symbol in the first element
Then obj_list will distribute all the elements of that list to the inlets of pack, from right to left which will set the atoms that pack is storing for those inlets
when obj_list lastly reaches/distributes to the leftmost it will call pack_symbol, which will call pack_bang which triggers the atoms pack has stored to be output as another new list

binding pack_anything to anythings coming into the first inlet is done by calling class_addanything in pack_setup method

Regarding Max's join, make it, just an abstraction away. [list store] mostly does that and a great deal more.

Is there any way how to actually see how pack works internally , or any other object for that matter

well, it's open source, you can look at the code. Help file also tells you how it works. The help file of [pack] clearly states that the left inlet allows "anythings"

Really wish pd has someting like that

Pd is not MAX, it doesn't work like MAX. Having said all that... Pd has Cyclone, and Cyclone has [zl join].... (and all other [zl] thingies).

well... cyclone also has [join]

and ELSE has [merge], which is basically the same...

so yeah, you have many options.

@ porres , If you don't mind I will post this on the discord/else forum since it's out of the scope of this topic .
Thanks everybody for the suggestions .

Join 3 where third inlet is symbol
Then unjoin 3 , third outlet is a decimal : 1.91027e-20

Holy fucking shit, how did that get by?

in the first inlet of merge 16 it will output a list as expected becauseit's hot , but so does the 13 th input ..which is weird

yup, can reproduce such weird as hell thing

yup, can reproduce such weird as hell thing

fixed in master

Holy fucking shit, how did that get by?

also fixed