Combinations returns size limit error

I was attempting to find all possible 5-letter combinations, using the combinations block. However, when I ran it, I got this error:
untitled script pic (57)
Is there a way that I can change this size limit so that this block does not return an error? Or is this a JS thing that can't be changed?

EDIT: "ABCs" returns a list of all lowercase English alphabet characters. (a, b, c, d, e...)
EDIT2: Alternatively, I'll just use
untitled script pic (58)
but I would rather not because it's kind of slow.

The most likely reason it's returning that error, is because you're creating a list that is $$26^5$$, which is 11881376. I'm pretty sure a list that length would use up too much memory.

Agreed. However, I am on a computer with a lot of memory currently.

why do you need every single five letter combination in a list? this is a massive memory hog and i can't imagine you doing anything with this where you actually need every single combination in a list at once. where is this being used?

It's to show inefficient methods of code-cracking (and why you should always use a secure password). This would be to show some of the downsides of brute-forcing- although it does cover every possible combination, it takes forever to run and takes forever to get a list to check.
Now that I say this, I think that a 4-letter combination list is a better option... it won't take nearly as long to load in on people's computers (I'm showing this at a school I'm going to).

But still, my question remains: if you have enough memory to handle it, can you change the size limit put on the "combinations" primitive?

Actually, after running this script

I now realize it's not actually a limit because of memory. The script returns a result, I just don't know why it doesn't let you do it in the combinations block.

I think it's because it takes too long. I tried this:

And it took a couple seconds.

That’s odd. I wonder why it does that. @bh? Is this intentional??

Yes. IIRC Jens was more worried about time than space, because, like most primitive reporters, it's uninterruptable. But

which is just under a million items, took about a second on my not-that-fast computer so I may be misremembering. (I was trying to experiment to see if I'm right about "uninterruptable," but it ran too fast for me to get to the stop sign or even to click the block again!) But in any case, yes, I think this is the only primitive that takes exponential time and space in the size of the inputs, which made Jens nervous; newbies should feel safe playing with blocks to figure out what they do.

Maybe we should have a context menu option to let it run unbounded, I dunno. One more thing to discuss for the next release.

... of course, if you want an interruptable and unbounded version you can and should write it yourself, like this definition by @bh , one of the most beautiful things on Earth (don't y'all agree?):

Definitely beautiful, but if anyone actually wants to play with it, I think it'll be quite a lot faster with this optimization:

eliminating the repeated recursive call.

I totally agree with @jens , this is amazing @bh, the optimized version is lightning fast. Beautiful implementation. Is this the same official version used in the current snap?

No, the official version is the limited-to-a-million primitive, that's how this thread started! :~)

Thanks @bh,

Now, I made a tail recursive version of combinations by using a helper function. Originally it's performance is terrible - this is surprising, the reason is I am using append, I examined the code, found out the entire sequence would be reversed if I used the adding item in front of list block. But a quick reverse of the input list order before calling the helper function fixed that.

I really appreciate this experiment, as it helps to understand the performance hit using append versus item in front of list block.

After the fix, I compared your version speed against mine, there is virtually no noticeable differences.

Here is my version:

my combinations