S>Но я вижу что ты уверен что твой алгоритм имеет туже сложность, как алгоритм, который представил Владимир...
S>А на самом деле только лишь на последнем шаге (при добавлении финальной буквы к каждому из уже полученных паролей длиной k-1) тебе придется каждый пароль проверить на факт содержания в нем каждого символа из алфавита. Причем n-1 из этих проверок будут явно лишними.
S>Только на последнем шаге алгоритмическая стоимость генерации увеличивается в n(k-1) раз.
S>Твой алгоритм лучше полного перебора с последующей фильтрацией. Но намного ли?

Это спор о реализации транслятора, а не о языке.
Ты никогда не можешь точно знать как работает РС, потому как он довольно таки декларативен.
Вот например в декларативном SQL func1(1) + func(2) это тоже ниразу не вызов двух функций, как мог бы подумать тот же сишник.
По семантике, да, вызываются две функции, результаты складываются. А реально оптимизатор может разобрать в ноль эти функции сделать из них одну и еще и переписать
там все полностью.

S>Ладно, теперь я меняю условия задачи. Логично предположить что мы используем генерилку для брутфорса (хохмы для). Генерилка проверяет пароли по мере получения (кстати, твои не лезут в память 32х разрядного приложения уже при параметрах 5 из 30). И каждую минуту сбрасывает на винт число проверенных паролей, потому как хакеру периодически нужны ресурсы системы для решения других задач и он хочет продолжить счет с последнего сохраненного номера.
S>Вот так неожиданно меняются требования в реальном мире. Проявляй гибкость.
S>Наперед скажу, что в моем решении менять ничего не надо. Пропустить 10000 элементов (skip 10000 (p 30 10)) результирующей последовательности занимает 0,24s и 10001-ый элемент равен 'abcdefg3vl' при алфавите ['a'..'z']++['1'..'4']. Пропуск миллиона вариантов занимает <20 сек. Уже проблема, но я знаю, что подкрутить что бы пропуск занимал ничтожное время.

Вообщето скип, это почти тот же фильтр результата.
Сам знаешь что нормальная реализация начинает сразу с середины перебор,
а не чтото там скипит.