GHC 8.8.1

А мне вот например интересен другой вопрос, почему в haskell списки могут содержать только однотипные данные, почему кортежи каждый имеет свой тип исходя из содержимого. Ведь например в том же Python удалось избежать этого ограничения, с чем принципиально связано это неудобство?

А мне вот например интересен другой вопрос, почему в haskell списки могут содержать только однотипные данные, почему кортежи каждый имеет свой тип исходя из содержимого. Ведь например в том же Python удалось избежать этого ограничения, с чем принципиально связано это неудобство?

Хахахаха! Отличный вброс. Алсо нет, в хацкелле есть HList.

Не вброс, просто стало интересно чего это они решили меня так огорчить (вы так кстати и не пояснили в чём причина), еще немного огорчило что нельзя делать кортежи единичной длинны, ваш haskell меня намеренно доводит до слез :'3

нельзя делать кортежи единичной длинны, ваш haskell меня намеренно доводит до слез
длинны

Меня до слёз доводит твоя альтернативная орфография.

То есть вы не знаете с чем это связано? Ясно, подождем тех кто знает.

Или речь про интерпретатор?

Да. Я про https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

Правда, посмотрел - там неполный R5RS.

Ведь например в том же Python удалось избежать этого ограничения, с чем принципиально связано это неудобство?

В питоне нет выбора тела функции по типу аргументов.

еще немного огорчило что нельзя делать кортежи единичной длины

А зачем? Кортеж нужен, чтобы несколько разнотипных значений сохранить в одной переменной. Кортеж единичной длины — это само значение в этом кортеже.

Это он про http://hackage.haskell.org/package/Only не в теме. А ещё Identity есть.

Потому что в Python вместо нативной структуры словарь с любыми данными

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

Нет, но кажется я не говорил что оно там есть, а спрашивал почему те вещи о которых я спрашивал, реализованы так как они реализованы.

mutual tail recursion

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

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

а спрашивал почему те вещи о которых я спрашивал, реализованы так как они реализованы.

Если бы у списков не было типа элемента, то к ним нельзя было бы применять никакие функции. Например, map (+ 1) имеет тип [Num] -> [Num]. А если бы был просто List, то применить (+ 1) к элементу произвольного списка нельзя, поэтому было бы очень неудобно.

SBCL и Kawa умеют разворачивать mutual tail recursion.

Это может быть заботой JVM, если компилятор из соображений совместимости обязан каждый вызов функции транслировать в вызов функции JVM.

И часто тебе приходится писать код, где нужно что бы среда умела разворачивать mutual tail recursion или используешь call/cc? Не пойми неправильно, спрашиваю потому что, как я понял, ты пишешь на Racket за деньги

Можно транслировать в то и то. Тоесть функция поддерживает внешний вызов, но уже внутри себя сама вызывать не будет, а будет работать по циклу

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

Да.

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

Если бы было так просто! Я не стал оспаривать слова monk, потому что неохота было, да и надоело.

Для той же схемы трансляторы часто используют механизм «трамплина», но мне кажется, что это не очень быстро, особенно на JVM. Здесь скорее вопрос в плоскости рантайма - как там реализовано соглашение о вызовах. Это самый главный момент.

В книге PAIP описан пример такого соглашения, но я не понял, может ли оно работать без GC (честно говоря, забыл детали, потому что прочитал книгу больше 10 лет назад). Но я знаю точно, что GHC поддерживает оптимизацию хвостового вызова и там отличное от Си соглашение о вызовах. Совпадение ли это?

Какие задачи решаются?

Иногда одну рекурсивную функцию удобнее разбить на две. Например, когда у тебя есть два различных условия для выхода из рекурсии вместо одного.

Конечно, можно сделать код менее читаемым и запихать всё в одну функцию, но ты понял.

Объяснил, как боженька. Наверняка, он всё понял. Хацкелевая запись каррированных функций очень интуитивна, да.

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

Умение разворачивать — это оптимизация. Мой первый проект за деньги был рекурсивным парсером сайтов на питоне. То, что на каждый уровень парсинга строка копировалась, не помешало использовать его несколько лет (ну сжирал сотню мегабайтов ОЗУ на парсинге небольшого HTML, но ведь работал). А сейчас оптимизацию tail recursion даже gcc умеет делать.

или используешь call/cc?

Активно — в web-разработке. В остальном — примерно так же часто, как в Си используется goto (и примерно для того же).

Наверняка, он всё понял.

Молчит, значит понял.