Firstof all , I 'd like to say that is the second forum I am posting this on because it is doing my head in .
If I have a pak object (PAK ) with s s s as arguments , it accepts and outputs a list , but I can not conclude if these are considered symbols or not ( see next )
Like this
If I use a pack ( PACK ) with s s s , the messages 'x ' and '-' in the second and third inlet , need to be converted to symbols in order for the pack object to work , the first inlet does not need it
Like this

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

@gentleclockdivider First inlet of [pack] and many objects treats everything on the first inlet as a list which it unpacks and fans out to the other inlets in order, a symbol or float is just a list of one element in this case.

This is standard behavior for vanilla objects. [pak] is not vanilla and many external objects go against vanillas standard behavior.

Thanks , but dont you mean "many NON vanilla objects go against vanillas standard behaviour ? "

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

@gentleclockdivider Yeah, will fix that error. The first inlet in the case of [pack] is always a list, a float or symbol is just a list of one element list. Internally [pack] works like this:

So left inlet will always add the appropriate selector even if it is a single element.

the '-' and 'X' are 'anything's in terms of pd types

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

@seb-harmonik.ar
That's exactly what thought
Is there any way how to actually see how pack works internally , or any other object for that matter . ?

@ 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

@gentleclockdivider of course, you can look at the code.

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

@gentleclockdivider manual or help files or here on the forum, too long ago to recall. Seb gives the full answer above, I put it in pd terms since most (including myself) find pd far easier to understand than pd's dense C.

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

True to that , some of pd modules are more flexible
List store appart from storing lists can also be used as a lookup ( get $1 ) , in max you need zl lookup etc..
Will try , thanks guys for the answers

@gentleclockdivider said:

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).

oh, you said it's [join] and not [zl.join]...

well... cyclone also has [join]

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

so yeah, you have many options.