Не понял, что вы имели в виду, но подозреваю, что случай, когда итератор пробегает по массиву. Если так, то ленивости тут хоть отбавляй, покажите, где тут энергичность, когда исходная таблица может быть изменена по ходу пробега и итератор прочтёт, как ни странно, — последнее значение, то есть выполнит чтение лениво.
Если это не так, покажите лучше кодом, или попытайтесь сформулировать чётче.
>если у нас уже есть готовый список, то его итератор ну никак не назвать ленивым.
Можно. Список не ленив, но итератор — ленив. Пара итераторов является ленивым списком, вне зависимости от того, где реально находится этот список, и находится ли вообще, так как реально значение будет прочитано в момент обращения к элементу итератора, что и есть ленивость.
Итераторы — не очень сладкая форма ленивого списка, источник которого в случае энергичного языка указывается явно (реальный список, элементы файла, ввод пользователя), а в Хаскеле выглядит именно как список, который тоже может как реально существовать, так и не существовать.
Будет пустой список. Его product вычислить нельзя, но это не недостаток функции, а недостаток формулировки задачи (не сказано о том, что делать, если n <= 1).
even убралось. Прочтите исходные условия. Перемножить чётные. То, что они следуют через 1, это оптимизация, причём ручная, которая выглядит и в Хаскеле не хуже. Я вам ответил, что он не проведёт такую оптимизацию сам, но сделать список чётных можно.
even взят ради примера, давайте ещё попросим простоту чисел? И ваш шаг магически исчезнет (так как этот случай уже так не прооптимизировать), а в случае явного условия добавится isSieve.
Пойнт в том, что ручной for эффективнее, но зачастую не на порядок (а малые константы неинтересны, да и большие, если это не узкое место), а его понятность оставляет желать лучшего.
В первом случае должен быть просмотрен весь (бесконечный) список, так как компилятор не знает, что все остальные числа не пройдут условие. Какой-нибудь Coq, может быть, и смог бы с этим справиться, но Хаскель не может. Разумеется, если произведение не печатать, то никаких вычислений не будет вообще.
Именно этого не делает цикл. Человек хочет получить произведение элементов списка (а не пройтись по каждому и умножить на него), а сделаются они подряд, или попарно, это неважно.
Другое дело, что оптимизация оставляет желать лучшего.
Не надо мне рассказывать, покажите лучше код, такой же лаконичный, и при этом чтобы итерация была через 2 элемента. Ну или хотя бы просто такой же лаконичный. Боюсь, что я увижу там эмуляцию ленивости при помощи итераторов, а не циклы
Потому что иначе это копипаст с изменением, а не комбинирование.
Я хотел бы увидеть комбинацию двух независимо написанных циклов. Так как вы спросили, что мешает их комбинированию, я предположил, что вы утверждаете, что ничто.
Скомбинируйте. Не переписав один из них, а не меняя двух исходных.
а ты уверен, что сей код будет развёртнут в цикл с шагом 2, а не в цикл с шагом 1 и вызовом функции even на каждом?
Никто не говорит, что надо писать на Хаскеле критичные к скорости программы, а я что-то сомневаюсь, что тут будет battle-neck.
Основной тезис — так писать удобнее, и при этом в отличие от энергичных языков не сильно медленнее (ибо в энергичном действительно будет создание нового списка)
Я бы ни в коем случае не обидился, если бы от меня потребовали расписку при достаточно большой сумме, наоборот, я считаю, что я сам обязан её написать.
Вы забыли, что ЯПы сделали, чтобы избавиться от ручного вбивания машинного кода, а компиляторы, чтобы из этого языка делать всё обратно. Это на что смахивает?
Потребность в этом продукте для самого разработчика — лучшая мотивация
Как показывает практика — не лучшая.
И опять же, вопрос не в том, каким образом таки будут создавать бесплатные программы. Я ещё не выжил из ума, чтоб опровергать факты, бесплатные программы существуют, значит мотивация есть. Я спрашиваю, почему будущее за ними, куда денутся остальные мотивации, которые приводят к платному софту?
И я бы предпочёл, чтобы создавали не те продукты, которые хотят сами производители, а те, за которые я готов заплатить (не лично я). На этом держится рынок. Поэтому либо я буду оплачивать косвенно, например просматривая рекламу, либо я просто заплачу. Я за возможность выбора.
Если это не так, покажите лучше кодом, или попытайтесь сформулировать чётче.
Можно. Список не ленив, но итератор — ленив. Пара итераторов является ленивым списком, вне зависимости от того, где реально находится этот список, и находится ли вообще, так как реально значение будет прочитано в момент обращения к элементу итератора, что и есть ленивость.
Итераторы — не очень сладкая форма ленивого списка, источник которого в случае энергичного языка указывается явно (реальный список, элементы файла, ввод пользователя), а в Хаскеле выглядит именно как список, который тоже может как реально существовать, так и не существовать.
even убралось. Прочтите исходные условия. Перемножить чётные. То, что они следуют через 1, это оптимизация, причём ручная, которая выглядит и в Хаскеле не хуже. Я вам ответил, что он не проведёт такую оптимизацию сам, но сделать список чётных можно.
even взят ради примера, давайте ещё попросим простоту чисел? И ваш шаг магически исчезнет (так как этот случай уже так не прооптимизировать), а в случае явного условия добавится isSieve.
Пойнт в том, что ручной for эффективнее, но зачастую не на порядок (а малые константы неинтересны, да и большие, если это не узкое место), а его понятность оставляет желать лучшего.
product [2, 4 .. n]
О чём я и говорил. Ушли от циклов, да ещё и even убралось, ручками оптимизировали частное условие.
Придётся ручками:
product (takeWhile (<= n) fibs)
product [x | x <- fibs, x <= n]
Другое дело, что оптимизация оставляет желать лучшего.
Я хотел бы увидеть комбинацию двух независимо написанных циклов. Так как вы спросили, что мешает их комбинированию, я предположил, что вы утверждаете, что ничто.
Проще, чем где? Если чем в Хаскеле, то неправда.
sum [1..5]
sum [x | x <- a, even x]
Скомбинируйте. Не переписав один из них, а не меняя двух исходных.
а ты уверен, что сей код будет развёртнут в цикл с шагом 2, а не в цикл с шагом 1 и вызовом функции even на каждом?
Никто не говорит, что надо писать на Хаскеле критичные к скорости программы, а я что-то сомневаюсь, что тут будет battle-neck.
Основной тезис — так писать удобнее, и при этом в отличие от энергичных языков не сильно медленнее (ибо в энергичном действительно будет создание нового списка)
Доверяй, но проверяй.
Я бы ни в коем случае не обидился, если бы от меня потребовали расписку при достаточно большой сумме, наоборот, я считаю, что я сам обязан её написать.
Этот код ещё и читать проще.
Будет третья статья с пояснениями бенефитов, которые нам всё это даёт?
Как показывает практика — не лучшая.
И опять же, вопрос не в том, каким образом таки будут создавать бесплатные программы. Я ещё не выжил из ума, чтоб опровергать факты, бесплатные программы существуют, значит мотивация есть. Я спрашиваю, почему будущее за ними, куда денутся остальные мотивации, которые приводят к платному софту?
И я бы предпочёл, чтобы создавали не те продукты, которые хотят сами производители, а те, за которые я готов заплатить (не лично я). На этом держится рынок. Поэтому либо я буду оплачивать косвенно, например просматривая рекламу, либо я просто заплачу. Я за возможность выбора.