Feature request: Allow "anything" as a type in [pack]

[mxa]

This would allow for polymorphic/generic code and one could for example make an abstraction which could do what [swap] does but with symbols and floats mixed.

[umlaeute]

use [zexy/pack] instead :-)

zexy's [pack] implementation used to override the built-in [pack] to allow something like that, but people complained so loudly that i had to undo that.
either my design or the feature might be flawed (i'd rather bet on my design, but who knows...)

[porres]

Other similar externals are cyclone/pak and else/pack2, but they're more useful if you want all inputs to be hot.

But anyway, seems like an 'anything/a' in pack wouldn't be bad, and I wonder if they could also take lists, so you can join and merge two or more lists as well!

[porres]

This would allow for polymorphic/generic code and one could for example make an abstraction which could do what [swap] does but with symbols and floats mixed.

why not also just allow swap to take symbols as well?

[porres]

I wonder if they could also take lists, so you can join and merge two or more lists as well!

the problem with this is that you can't have a proper counterpart with unpack...

[mxa]

I wonder if they could also take lists, so you can join and merge two or more lists as well!

the problem with this is that you can't have a proper counterpart with unpack...

Not every time an unpack counterpart is needed.

[mxa]

use [zexy/pack] instead :-)

zexy's [pack] implementation used to override the built-in [pack] to allow something like that, but people complained so loudly that i had to undo that.
either my design or the feature might be flawed (i'd rather bet on my design, but who knows...)

ClaudiusMaximus mentioned [lpack] from pdlua as well.

[mxa]

why not also just allow swap to take symbols as well?

honestly I don't understand why [swap] exists since its functionality can be built with more basic objects: [pack f f] and [$2 $1(

[porres]

many objects can be built with other basic ones. For instance, I can implement [moses] with [<] and [select], swap can also be implemented like this:

So yeah, it's just a matter of convenience.

[porres]

Not every time an unpack counterpart is needed.

even though I like the idea of being able to join lists, I wouldn't know how to unjoin them with unpack, so this functionality could be better implemented into a new function in [list], actually I think there was a PR about it.

[porres]

I think there was a PR about it.

nope, there wasn't, there's a PR for [list join] and [list unjoin] but they do different things. Well, maybe we could open a new feature request or PR for that, but it'd be separate from this one. And btw, cyclone/join and cyclone/unjoin & else/merge and else/unmerge do that.

Now, there are two suggestions here:

• a) make pack/unpack deal with either float or symbol;
• b) make swap deal with either float or symbol

I could implement both suggestions into separate PRs, but not this month.

[umlaeute]

whatever you do, make sure that the implementation

• is not performing much worse
• still allows for automatic distribution of list-messages over all the inlets

[porres]

hmm, how about list prepend for a more flexible [swap]?

[porres]

I deleted one of the messages above, anyway, as far as implementing a more flexible [swap], [list prepend] can do it. So we don't need to add this functionality to [pack] so you can do that. Using "$2 $1" in messages also swaps things as mentioned.

It still feels to me that adding 'anything' to [pack] looks useful though

[umlaeute]

keep in mind that [list prepend] is

• about 3-4 times slower than [swap]
• does not allow for automatic distribution of list-messages over the inlets