речь-то про дерайвинг для произвольного произведения

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

хотя я за дерайвинг для произведения, да

ну можно обойтись кортежами и {-# 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

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

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

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