ну можно обойтись кортежами и {-# LANGUAGE GeneralizedNewtypeDeriving #-}

PatternSynonyms наверняка захочется

и на чём порешили?

большинство высказались за отделение в пакет

(который уже и так был до этого обсуждения)

для кортежа это логично

Полнофункциональные гетерогенные списки https://ruhaskell.org/posts/dynamic/2017/09/01/Fully-functional-heterogeneous-lists.html

type HList c = [C c] data C (c :: Constraint) = forall c a . C a ?

статью не читал

там пожестче:)

там как-то все очень непонятно, что и зачем

но этого же достаточно для того чтобы выразить что угодно

разве что можно добавить Typeable к c

разве что можно добавить Typeable к c

Примеры чего угодно?) Список из мейби изер и пар?) Можно сделать?

я про то, что все что хочется от гетерогенного списка

не всё

можно обращаться к элементам по единому интерфейсу

можно

или я не понял фразы

а получать данные в оригинальных типах уже нет

для этого я на прошлой неделе изобретал свои велосипеды

Typeable есть - можешь

а, ну да, с Typeable можно кастовать обратно

когда пишешь такие штуки логично Typeable требовать всегда

тогда можно всегда заткнуть дыру, которую упустил в дизайне =)

ждём разоблачающей статьи «а вот как это делается на самом деле в 5 строк»

человек все нормально сделал

у него тоже решение только в профиль

+- интерфейс под удобные ему задачи

data Wrap (constraint :: * -> Constraint) where Wrp :: (Show a, Typeable a, constraint a) => a -> Wrap constraint instance Show (Wrap a) where show (Wrp a) = show a

это тоже самое что data Wrap c = forall a . (Show a, Typeable a, c a) => W a

т.е. +- детали

instance Read f => Read (Food f) where readsPrec i s = [runState (sequence $ pure $ state $ head . readsPrec i) s]

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

чтобы читать тип Food, который объявлен как data Food f = Food {energy :: f, protein :: f, fat :: f, carbs :: f, price :: f}

читать как список аргументов

что-то меня гложат сомнения:)

работает так λ> (read "1 2 3 4 5")::(Food Int) 1 2 3 4 5

(show тоже выводит без конструктора)

я с Read очень мало работал, не знаю, как там принято делать

первая версия этого кода выглядел так readsPrec i s = let [(nrg, s1)] = readsPrec i s [(prt, s2)] = readsPrec i s1 [(fat, s3)] = readsPrec i s2 [(crb, s4)] = readsPrec i s3 [(prc, s5)] = readsPrec i s4 in [(Food nrg prt fat crb prc, s5)]

но потом я там увидел монаду State и понеслась

оба кода эквивалентны, если что

никогда не видел, чтобы Read для чего-то полезного использовался

никогда не видел, чтобы Read для чего-то полезного использовался

Ну а как тут

Через что ещё?

на парсеке это будет что-то вроде sepBy space number

Ну и many?

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

Read желательно писать так чтобы Read.Show работало

в base есть парсер-комбинаторы, если что

на них инстанс Read делается куда приятнее

причин писать свой Read не как deriving Read я наверное даже не знаю

в base есть парсер-комбинаторы, если что

Ну-ка?

Text.ParserCombinators.ReadP

Read желательно писать так чтобы Read.Show работало

У меня работает, если я правильно понял фразу

Форматы одинаковы

работает так λ> (read "1 2 3 4 5")::(Food Int) 1 2 3 4 5

в base есть парсер-комбинаторы, если что

Спасибо, гляну

вообще Read/Show это чисто технические вещи

для показа пользователю в файлы стоит всякие PrettyPrint и т.п.

но это моё странное мнение

+5 к мнению. Parsec/Text.PrettyPrint

Есть мнение, что Show и Read вообще должны быть только автовыводимыми

Вон, Universum (это такая прелюдия) только такие и позволяет

Есть мнение, что readP неудобен в использовании

https://github.com/serokell/universum#gotchas > Since show doesn't come from Show anymore, you can't write Show instances easily. Either use autoderived instances or Buildable.

:)

Автора позабавило упоминание?

:)

В чём основная философия функционального программирования?

чморить объектно-ориентированных

programming, motherfucker

философия в том, что с функциями всё работает без фмлософии

а базовые принципы ФП — это, конечно, functions are FCO и HOF

Второе какбэ из первого выводится

Просто у нас тут небольшая дискуссия. Говорю, что ООП против ФП прежде всего это разница с манипуляцией данными. Изменяемость против неизменяемости.

Речь именно о парадигмах.

нет конечно

и как может быть ФП против ООП

это вообще ортогональные вещи

Задачи решают функции, а не объекты

OOP was good back in the days, and it still has its uses today, but now everyone is realising modifying states is equivalent to kicking babies, so now everyone is moving to immutable objects and functional programming

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

тому що всё фп оно о какой-нибудь композиции функций, трансдьюсеров, монад, функторов и т.д.

альтернатива для ФП это императивное программирование

их можно сравнивать

ООП это о представлении данных и связанных с ними функциях

тогда уж правильнее будет декларативное vs императивное, не?

ООП сочетается как с ФП, так и с иммутабельностью

альтернатива для ФП это императивное программирование

так одного в другое уже намешали

@KolesnichenkoDS согласен

См. скала?))0)

ООП это о представлении данных и связанных с ними функциях

вот а можно об этом поподробнее? а то я уже столько разных определений ООП встречал, совершенно разных интересно ещё одно мнение выслушать

вы же знаете про featherweight java?

эта милота у Пирса в книжке есть

начинается с лямбда-инсчисления

вот а можно об этом поподробнее? а то я уже столько разных определений ООП встречал, совершенно разных интересно ещё одно мнение выслушать

потому что если инкапсуляция, наследование, полиморфизм, то если допустить что под наследованием можно понимать наследование поведения, а не реализации, то Haskell очень даже ОО-язык

классическое mainstream определение это про то, что система работы с данными где данные образуют иерархию со свойствами инкампуляция, наследование, subtype полиморфизм ?

и на каком-то моменте реализуется маленькая джава