\x -> (x x)

Смотря каких. Ты просил лямбду — получи и распишись.

Не делай дурачка. System F не позволяет написать настоящий Y комбинатор.

Не делай дурачка. System F не позволяет написать настоящий Y комбинатор.

по-моему, это ты делаешь дурочка.

ты как-то можешь внешне определить, что этот комбинатор не «настоящий»?

википедию смотри

Лавсанчик некорректно выразился. Он хотел от тебя замкнутый лямбда-терм, который задает y-комбинатор. Ты такого терм не написал.

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

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

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

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

Ох ёпты, пацаны смотрите - живой жабоед!

Жаба?
нормальный?
язык?

Я конечно много пил, на НГ, но вроде еще не до белочки.
Или таки до?

Кто-нибудь, скажите что мне этот дурик JFreeM только кажется, что он существует только в моем воображении.
Иначе я не вынесу.

Лавсанчик некорректно выразился.

Это как всегда.

Он хотел от тебя замкнутый лямбда-терм, который задает y-комбинатор. Ты такого терм не написал.

Да ну? И что в нём незамкнутого?

википедию смотри

это не ответ

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

За суждение о _языке_ на основе результатов шутаута нужно нещадно бить в бубен и увольнять с работы с правом занимать программистскую должность в течение трёх лет.

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

с правом

с лишением права

спасибо, что поделился баттхёртом

спасибо, что поделился баттхёртом

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

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

Смысла в шутауте нет

Не совсем так. Понятно же, что как ни устраивай подобный шутаут - всё равно gcc будет где-то среди лидеров, а python - где-то в хвосте. Это чисто статистический факт. Да и более тонкие различия вполне правдоподобно выглядят.

выиграет тот погромист

Там не один погромист. Данная масса программистов на данном языке с данной (лучшей на момент) реализацией этого языка пишет программы которые демонстрируют такое-то среднее потребление памяти и расход времени на выполнение. И эти числа так-то соотносятся с соответствующими числами для других языков (реализаций, их масс программистов и пилящихся программ). И эти числа остаются примерно в одинаковом отношении.

Там не один погромист. Данная масса программистов на данном языке с данной (лучшей на момент) реализацией этого языка пишет программы которые демонстрируют такое-то среднее потребление памяти и расход времени на выполнение. И эти числа так-то соотносятся с соответствующими числами для других языков (реализаций, их масс программистов и пилящихся программ). И эти числа остаются примерно в одинаковом отношении.

На шутауте только числодробилки. А числодробилки - весьма небольшой процент задач, решаемый погромированием. В реальной жизни гораздо важнее, сколько погромистов надо, чтобы поднять проект в приемлемые сроки, и сколько в проект нужно положить денег, плюс риски (стопицот жавакодеров найти легче, чем пять лисперов).

В принципе, понятно, почему выплыли числодробилки, ибо один из основных критериев их работы - время выполнения - можно оценить холодным кремнием. А вот, например, красоту решения (на любом языке) можно оценить только субьективно, приняв вина хорошего года и закусив зрелым сыром. Попутно словив по хлебалу от приверженца хоть и того же языка, но другой школы погромирования.

На шутауте только числодробилки. А числодробилки - весьма небольшой процент задач, решаемый погромированием.

В реальной жизни обычно IO-bounded задачи, а эффективность их реализации не особо зависит от языка - в любом языке скорость выполнения IO будет зависеть не от смышлёности компилятора, а от скорости шины. Например, с точки зрения шутаута Erlang - полный тормоз с точки зрения скорости выполнения (да и с точки зрения потребления памяти), но это не мешает ему хорошо справляться с IO-bounded задачами за счёт его специфичной модели VM.

Но вот когда начинаются CPU-bounded задачи или любой вычислительный bottleneck между IO (при этом, таких мест может быть сколько угодно много и заранее нельзя точно определить где именно они будут), тогда хочется (всё-таки) чтобы не было сильных провисаний в таких местах (для интерпретируемых / JIT-ируемых ЯОВУ, например, есть такое известное явление как «тормозящий гуй», обычно проблема решается вылизыванием всего низкоуровневого кода GUI-библиотеки и/или реализацией этих частей посредством FFI).

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

Всё это, конечно, не касается эстетской стороны дела - касается только того как языки реализованы. Хотя, если в языке куча навороченных фич которые при этом реализованы плохо или их просто не получается реализовать хорошо - нафиг надо? Зависит от задач, конечно.

System F не позволяет написать настоящий Y комбинатор.

В хаскеле не в точности HM и не в точности System F, равно как и в ML-ях, F# и других подобных языках. Даже haskell98 = HM + рекурсивные типы (data / newtype) + рекурсивные функции (top-level / where / let). GHC = System F + рекурсивные типы + рекурсивные функции + undecidable type classes + undecidable type families + GADTs + т.п. расширения.

Так что Y определяется либо с помощью рекурсивных функций:

-- | Top-level recursion.
y :: (a -> a) -> a
y f = f (y f)

-- | Recursive let expression.
y :: (a -> a) -> a
y f = let x = f x in x

либо с помощью рекурсивных типов:

newtype Mu a = In { out :: Mu a -> a }

y :: (a -> a) -> a
y = \f -> (\x -> f (out x x)) (In (\x -> f (out x x)))

Это же касается топика (U комбинатор) - пишется с помощью рекурсивных типов и функций.

System F сама по себе даже не является тьюринг-полной так как обладает свойством строгой нормализации, чтобы вернуть Тьюринг-полноту нужно взять System F + Y, System F + letrec и т.п. расширения.

Всё это касается и остальных систем лямбда-куба (но не касается PTS) - все они суть сужения unrestricted LC которые, с одной стороны, вводят некую консистентность, но, с другой стороны, ломают тьюринг-полноту. Например, Agda не добавляет никаких расширений к MLTT которые бы могли нарушуть строгую нормализацию, поэтому, вообще говоря, не является тьюринг-полным языком (правда, тьюринг-полнота легко возвращается за счёт возможности определять примитивы и строить FFI к хаскелю), но, с другой стороны, обладает свойством строгой нормализации, что упрощает задачу именно доказательств (для чего она и нужна).

> (\f -> f (unsafeCoerce f)) id

Process haskell ошибка сегментирования

;)

Но при этом:

u f = f $ unsafeCoerce f
y f = u $ f . u
fac f n = if n == 0 then 1 else n * u f (n - 1)

-- u fac 5
-- > 120