переименование

...которые в лямбда-абстракции

Спасибо!

...которые в лямбда-абстракции

связанные

бета — это подстановка выражения в тело

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

тайпклассы так назывались в первой же статье где они описываются. https://people.csail.mit.edu/dnj/teaching/6898/papers/wadler88.pdf ну и это не какой-то там термин у которого может быть точное определение, это "фича", которая определяется правилами типизации и трансляцией в язык без этой фичи.

Даже SPJ в каких-то докладах говорил next Haskell will be strict, ибо слишком уж она непредсказуемая, ленивость эта

это же шутка. (правда, "пророчество" сбылось, есть же прагма language Strict которой никто не пользуется)

тайпклассы так назывались в первой же статье где они описываются. https://people.csail.mit.edu/dnj/teaching/6898/papers/wadler88.pdf ну и это не какой-то там термин у которого может быть точное определение, это "фича", которая определяется правилами типизации и трансляцией в язык без этой фичи.

спасибо!

это же шутка. (правда, "пророчество" сбылось, есть же прагма language Strict которой никто не пользуется)

А сколько было радости когда появилось

это же шутка. (правда, "пророчество" сбылось, есть же прагма language Strict которой никто не пользуется)

Нет, это не шутка. С ленивостью действительно есть проблемы.

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

Может, упростить контроль над ленивостью? Например, при вызове ф обозначать, что пусть всё в ней лениво | строго.

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

Нет, это не шутка. С ленивостью действительно есть проблемы.

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

Может, упростить контроль над ленивостью? Например, при вызове ф обозначать, что пусть всё в ней лениво | строго.

Есть уже, ! и force

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

нет, не связано

(по словам его автора, по крайней мере)

И вообще, строгости добавить проще чем ленивости

Если не ошибаюсь, строгость обусловлена простотой написания бэкендов во всё подряд

А часть функций, которые берёт на себя ленивость берёт тотальность с кодатой

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

конечно реально

в cabal style

когда что-то работает, что-то нет, интерфейс для инопланетян

И вообще, строгости добавить проще чем ленивости

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

но если понимаешь, что там к чему - то все прекрасно

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

как раз наоборот

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

допилят

получится как в идрисе "ленивость"

(по словам его автора, по крайней мере)

Я общался с автором и у меня другое впечатление сложилось

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

вы про имплементацию, а я про программистов

получится как в идрисе "ленивость"

Да, или как в идрисе

покажите мне хоть один язык, в котором есть нормальная ленивость, а там уже и поговорим

что проще, а что нет :)

покажите мне хоть один язык, в котором есть нормальная ленивость, а там уже и поговорим

нормальной нет нигде же.

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

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

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

вот причина, которую называет сам автор > 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 запихивать

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