LINUX.ORG.RU

Фруктовый микс

 ,


0

2

Есть ли такой подход, когда для написания большей части логики используется функциональная парадигма, а для некоторых вспомогательных частей - императивная? Например разделять на уровне синтаксиса ЯП какие функции/методы являются «чистыми», а какие нет. Что-то на уровне псевдокода:

// объявления в чисто функциональном стиле
defunc PrimeNums = 2 : [n | n <- [3..], IsPrime n]
defunc IsPrime n = foldr (\p r-> p*p>n || (rem n p /= 0 && r)) True PrimeNums

// объявления в императивном стиле
def Foo(a, b, c):
    v1 = IsPrime(a)
    v2 = IsPrime(b)
    v3 = IsPrime(c)
    return v1 or v2 or v3
Причем вызов «обычных» def-методов возможен только из других def-методов, но не из defunc.
Существуют ли подобные ЯП? Может быть Lisp?



Последнее исправление: nerdogeek (всего исправлений: 1)

присоединяюсь к вопросу. что императивщина, что функциональщина в чистом виде говно.

u283
()
Ответ на: комментарий от emulek

почему? и у того, и у другого есть плюсы. и минусы. неужели нельзя их объединить, сохранив плюсы и избавившись от минусов?

u283
()

Например разделять на уровне синтаксиса ЯП какие функции/методы являются «чистыми», а какие нет.

gcc для сишки поддерживает атрибут pure :)

Может быть Lisp?

реализовать можно, искаропки такого не знаю

lazyklimm ★★★★★
()

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

vertexua ★★★★★
()

объявления в императивном стиле

Это точно не функциональный стиль? Или функциональный стиль это когда все в одну строчку со всякими fold, map, reduce?

crowbar
()
Ответ на: комментарий от nerdogeek

Кто знает, монады - это такой костыль или нет?

Нет, это удобная абстракция.

mix_mix ★★★★★
()
Ответ на: комментарий от nerdogeek

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

Монады это просто (так было написано). Я помню, что понял их, и это было правда просто, но потом все забыл. Суть монад состояния (мы здесь всегда опускаем это второе слово) — как пробросить грязный императивный мир в чистую функциональную среду, не загрязнив ее. Костыль или нет — решай сам.

Монада ST (state transformer) например позволяет представить тот же prng как чистую функцию, возвращающую очередное значение *и* новую себя, которая инкапсулирует измененное состояние. Не помню как именно, хоть убей. Сама монада просто дает не трахаться с идиотской по сути записью вызова и проброса нового стейта из/в стека вызовов.

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

Clean пошел по другому пути, там вместо монад своя идея, чем-то проще, чем-то сложнее, сильно не вникал.

Я тут 100% переврал, читайте в оригинале, там правда все просто.

arturpub ★★
()

haskel же

main :: IO() - действие pure :: a -> a - чистая ф-я

MyTrooName ★★★★★
()

Чувак, но ведь в хаскеле именно так все и есть =)

Waterlaz ★★★★★
()
Ответ на: комментарий от nerdogeek

Монады - не костыль.

Монады в хаскелле - костыль, потому что там нет простого кода с сайдэффектами. Костыль-фича, так задумано

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

нет простого кода с сайдэффектами

unsafePerformIO

Монады в хаскелле - костыль

справедливо только касательно IO. и то - лучший из существующих

jtootf ★★★★★
()
Последнее исправление: jtootf (всего исправлений: 1)

Такой подход есть. Используется в языках F#, Scala, Haskell и во всех лиспах, включая Common Lisp. Многое зависит от самого программиста. Императивщина еще часто используется для оптимизации и тюнинга уже работающих частей, которые прежде были написаны в функциональном стиле.

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

dave ★★★★★
()
Ответ на: комментарий от u283

почему? и у того, и у другого есть плюсы. и минусы. неужели нельзя их объединить, сохранив плюсы и избавившись от минусов?

плюсы == продолжение минусов. И минусы == продолжение плюсов. То, что является багом в ФП, является фичей в ИП.

Жаль, что вы этого не понимаете.

А писать так можно. Хоть на lisp'е, хоть на C++. Только я это считаю быдлокодом.

emulek
()
Ответ на: комментарий от nerdogeek

монады - это такой костыль или нет?

нет. Это круто.

emulek
()

Есть ли такой подход, когда для написания большей части логики используется функциональная парадигма, а для некоторых вспомогательных частей - императивная?

Конечно есть, вон на Хаскеле всё так и пишут обычно.

yoghurt ★★★★★
()
Ответ на: комментарий от arturpub

Монада ST (state transformer) например позволяет представить тот же prng как чистую функцию, возвращающую очередное значение *и* новую себя, которая инкапсулирует измененное состояние. Не помню как именно, хоть убей.

вот так и возвращает. Как ты сказал.

emulek
()
Ответ на: комментарий от vertexua

В хаскеле совершенно другой подход.

anonymous
()
Ответ на: комментарий от vertexua

Это хаскелль. Именно в точности так там и прянято делать.

Что сделать с хаскелем, чтобы не трахаться с типами? Т.е. вообще, или только в крайнем случае, когда надо что-то оптимизировать или предохраниться от неверного использования. Да - с ошибками в рантайме. Да - с потерей производительности. Но чтобы мне на строчку кода

defunc PrimeNums = 2 : [n | n <- [3..], IsPrime n]

не надо было ещё самому лепить строку с типами, пока мне это действительно не понадобится?

Если это другой язык, то какой? :)

yyk ★★★★★
()
Ответ на: комментарий от yyk

не надо было ещё самому лепить строку с типами, пока мне это действительно не понадобится?

В хаскелле не нужно «лепить строчку с типами», до тех пор, пока вывод типов может тебя понять.

anonymous
()
Ответ на: комментарий от yyk

Но чтобы мне на строчку кода

defunc PrimeNums = 2 : [n | n <- [3..], IsPrime n]

не надо было ещё самому лепить строку с типами, пока мне это действительно не понадобится?

Так не лепи. Вывод типов её прекрасно съест.

Miguel ★★★★★
()
Ответ на: комментарий от yyk

Еще есть -fdefer-type-errors, который переносит все ошибки типов в рантайм, но это для мазохистов.

anonymous
()
Ответ на: комментарий от yyk

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

Но это не отменяет траходрома с типами.

vertexua ★★★★★
()
Ответ на: комментарий от Miguel

Так не лепи. Вывод типов её прекрасно съест.

Автолифтинг в ИО не выводится, так что придется лепить.

anonymous
()
Ответ на: комментарий от vertexua

Но это не отменяет траходрома с типами.

Спасибо. Тогда останусь пока с тем траходромом, который привычнее ;)

yyk ★★★★★
()
Ответ на: комментарий от tailgunner

«Просто» это получается только с подходящей системой типов, которая разделяет чистый и грязный код.

anonymous
()

// объявления в императивном стиле

No.

theNamelessOne ★★★★★
()
Ответ на: комментарий от Miguel

Анонимус, видимо, зачем-то хочет чтобы к IO автоматически подставлялось liftIO в трансформерах.

anonymous
()
Ответ на: комментарий от arturpub

Сама монада просто дает не трахаться с идиотской по сути записью вызова и проброса нового стейта из/в стека вызовов.

Это не монада не дает, а do-нотация.

ovk48 ★★★
()
Ответ на: комментарий от nerdogeek

Кто знает, монады - это такой костыль или нет?

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

ovk48 ★★★
()
Ответ на: комментарий от anonymous

«Просто» это получается только с подходящей системой типов, которая разделяет чистый и грязный код.

Да нет, это действительно просто. И никакой системы типов не нужно.

anonymous
()
Ответ на: комментарий от Miguel

Какой ещё автолифтинг

Автоматическое поднятие ф-и в IO.

и какое он имеет отношение к декларации типов?

Прямое

anonymous
()
Ответ на: комментарий от anonymous

Автоматическое поднятие ф-и в IO.

Допустим.

и какое он имеет отношение к декларации типов?

Прямое

Какое именно?

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

Автоматическое поднятие ф-и в IO.

Вредно, потому что лифтинг нужен не только для IO и монадных трансформеров. Иначе просто может поломаться вывод типов.

dave ★★★★★
()
Ответ на: комментарий от u283

неужели нельзя их объединить, сохранив плюсы и избавившись от минусов?

В итоге как обычно получится сохранить минусы и избавиться от плюсов.

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

По сабжу - а почему категорически низя обычные методы вызывать из чистых?

Потому что тогда чистые перестают быть чистыми.

ovk48 ★★★
()
Ответ на: комментарий от dave

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.