Это связано с тем что Идрис сделали строгим

вот причина, которую называет сам автор > The original reason is not even anything to do with practical choice. It was just the way I wanted to do it at the time, having already implemented a lazy VM for an earlier project. https://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgwc6f/

Покажите мне ЯП где я могу как в хаскеле понаписать любой ерунды в where и не боятся что вычеслю слишком много

вот reasoning для всяких исключений, тотальности, линейных типов - он проще со строгостью

но если вы выберите строгий по умолчанию язык, то о прямой ленивости можно забыть

максимум что будет всякие итераторы стримы и т.п.

что конечно хорошо, но немножко меньше

Покажите мне ЯП где я могу как в хаскеле понаписать любой ерунды в where и не боятся что вычеслю слишком много

Это прекрасно и удобно, никто не спорит. Проблема в цене, которая за это заплачена: непредсказуемые затраты по памяти… а неиспользуемые байндинги, кстати, многие компилятора прекрасно выбрасывают. Конечно, это implementation-dependent, что хуже

они же не неиспользуемые

что конечно хорошо, но немножко меньше

Да, полностью согласен

Herbert Valerio Riedel говорит, что следующий за 2.2 cabal будет 3.0 и там по умолчанию уже будет nix-style local build (https://github.com/haskell/cabal/issues/5074#issuecomment-360978451), ссылается при этом на проект для GSoC. Как считаете, это реально?

прямо скажем, это было реально уже годы назад, это просто было не кабалистский подход, отдать пользователю что-то недоделанное, а потом получать фидбек и допиливать

они же не неиспользуемые

вот я про это да

вот с непредсказуемыми я не знаю

вот я про это да

Тогда определите что такое ерунда в where :)

в общем-то они считаются

@ulysses4ever все локальные переменные, которые используется в коде, но не вычисляются во всех ветках

Никто не спорит, что первоклассная ленивость удобней, чем костыли, но костыли практичней

Как раз наоборот. Для строгости нужны новые примитивы (seq), а для создания отложенного вычисления просто завернуть в лямбда-функуию с unit-аргументом. Примерно так + немного сахара в Скале

нет, это не ленивость, да и в скале это не так имплементировано

Тогда определите что такое ерунда в where :)

case foo of ... -> ... -> ... -> ... where ... ... ...

но я например не осилю посчитть

как в Элис что ли?

Про Элис слышу впервые 😔

Никто не спорит, что первоклассная ленивость удобней, чем костыли, но костыли практичней

все говорят что ленивость плохо, а мне норм.

впрочем в строгом языке тоже не факт, что всегда осилю

Про Элис слышу впервые 😔

http://www.ps.uni-saarland.de/alice/manual/futures.html

Ленивость не практична. хаскель не практичен.

все говорят что ленивость плохо, а мне норм.

Про плохо я не слышал, я слышал про практичней, потому что предсказуемее

Вообще-то () → a это не ленивость, т.к. a будет перевычисляться каждый раз

в идрисе и перевычисляется (в скале - нет)

Если вас (как меня например) не сильно волнует производительность, то, конечно, ленивость ок и очень удобна

Что мы тут вообще делаем все? У нас терапевтическая встреча клуба людей с Стокгольским синдромом?. Какой-то Фрейдистский фалос в голове мешает нам писать на практичных ЯП?

ой...

ну зачем так-то

: (

нас раскрыли

пшшш

Про плохо я не слышал, я слышал про практичней, потому что предсказуемее

Предсказуемее вообще без ГЦ

*кидает дымовую шашку и и исчезаезт*

Никто не спорит, что первоклассная ленивость удобней, чем костыли, но костыли практичней

Так удобней, а эдак практичней. Deos not compute

ну черт знает, я в haskell непредсказуемые тормоза и из-за ленивости и из-за строгости видел

Это прекрасно и удобно, никто не спорит. Проблема в цене, которая за это заплачена: непредсказуемые затраты по памяти… а неиспользуемые байндинги, кстати, многие компилятора прекрасно выбрасывают. Конечно, это implementation-dependent, что хуже

я бы не сказал, что предсказуемое N в строгом языке практичнее чем N в худшем случае в ленивом и константа в лучшем

Пора выходить из чата?

и в идрисе у меня была куча всего O(N^2) вместо O(N) т.к. он строгий

а переписывать и сильно усложнять код, чтобы он был O(N) не хотелось

но то, что имея тип структуры нельзя сказать сколько она занимает в ленивом языке - может быть проблемой

ФП в ленивом языке точно практичнее, чем в строгом Правда практичность ФП довольно сомнительна пока

Есть уже, ! и force

Разве ! устрожает всю цепочку? Думал, только непосредственно вызываемую ф (первую в цепочке)..

! вычисляет то, перед чем оно стоит до WHNF

и в идрисе у меня была куча всего O(N^2) вместо O(N) т.к. он строгий

Да, это изначальный и единственный аргумент за ленивость: вычисления лучше структурированы. Но есть оборотная сторона, которая перешивает для многих. Мне казалось, Саймон часто говорил, что эта фича получилась довольно противоречивой. Но искать лень

изначальный и единственный агрумент за строгость: програмисту кажется, что он лучше её понимает

причем понимает, т.к. учился на строгих яп

ну, не только кажется, ведь он действительно учился на них

хотя не, изначальный, т.к. это проще написать

я вот сейчас одному школьнику помогаю

он входит в программирование через хаскель

и лисп

скинул ему курсов и книжек, вроде учится

а нормальных книжек не то, чтобы много

правда это не единственный и даже не главный аргумент решает будет язык ленивый или строгий фактически его имплементатор, потому главный аргумент за строгость: ее проще имплементировать

единственное когда я увидел проблему с ленивостью, это когда пытались определить семантику и понять что с linear-types делать

ленивость там 100500 радостей приносит, которые в строгом языке понятнее как решать

Разве ! устрожает всю цепочку? Думал, только непосредственно вызываемую ф (первую в цепочке)..

Устрожает только голову. А для всего есть force.

force вычисляет агрумент до NF всегда проходя его

evaluate . force все вычисление

но с другой стороны force даже по вычисленному пробежится, поэтому хорошо бы его в newtype Once запихивать

"Его" -- вычисленное?

результат

И как это приведёт к однократному пробегу?

data Once a = Once () a если таскать такое вместо a то последующие форсы не будут пробегать структуру

once :: NFData a => a -> Once a once a = Once (rnf a) a instance NFData (Once a) where rnf (Once () _) = ()

Прикольно! :)

https://www.schoolofhaskell.com/user/edwardk/snippets/once

почему только последующие? похоже, что на эту структуру вообще rnf не действует как ожидается

Не, там имеется ввиду, что надо где-то в коде дёрнуть once, а последующие force уже не будут на неё действовать

но если не дёрнуть once, то force вообще никогда не будут действовать? в чём смысл слова "последующие" перед "force"?

Ну так, да.

Это структура в которой WHNF=NF (но создачать её можно только once)

а, надо обернуть данные в once (sic!), а не в Once!

почему только последующие? похоже, что на эту структуру вообще rnf не действует как ожидается

все в порядке с ней

обернуть тип нужно в Once конечно же

создать Once можно вызвав метод once

обернуть тип нужно в Once конечно же

этого недостаточно же

создать Once можно вызвав метод once

не можно, а нужно