unpack does not guarantee sequence, as does trigger.

It's not really "my" use case. I saw the post on FB about why [t 10 66 -100 3000] doesn't work as expected. That seems like a reasonable expectation based on how [pack 10 66 -100 3000] works, and a useful feature.

Also giving a list to [t f f f f] seems like it should work like [pack f f f f].

I am just saying that such irregularities and special cases in a language given similar syntax (as with English!) make it more difficult to learn, use, and master.

Whereas a language like Perl, things just seem to work as you would expect them to, based on similar patterns. You can often guess at the syntax and things just work, as opposed to learning a bunch of special cases.

I think given present behavior, [t 35] should throw an error to the console.

But I would prefer the change requested.

On Sun, Apr 14, 2019, 7:34 PM Alexandre Torres Porres <porres@gmail.com> wrote:

Em dom, 14 de abr de 2019 às 19:14, William Huston <williamahuston@gmail.com> escreveu:
Well if it breaks things, then that is a problem.

However, I think that sending a list to
[t l l l], and replicating the list to each output would have very few applications. I would like to see a patch where someone is using this feature.

I've done that lots of times

Anyway, that is not my use case.

My use case is

a) literals in [t] not working the same between [pack] with similar looking syntax (as illustrated)

not a good point as both objects are supposed to be quite different, and each object has its own design or "syntax"

b) sending a list to [t f f f]. Distributing the list to each float seems rather useful

this task is performed by [unpack f f f] already.

I don't really understand your use case, can you give us more details?

cheers