-)

лул

а давайте попробуем тему закончить

а не просто попиздеть

Суть такова

пардон за мой французский

TH-код не должен выглядеть эстетично, он должен выглядеть "немного не очень" - чтобы не хотелось его использовать без необходимости :)

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

Программы можно писать хоть на цепях Маркова

можно

но маленько некомфортно писать сколько нибудь сложную систему

Вопрос в соответствии доменной логики философии и понятиям используемого языка и тулинге

https://hackage.haskell.org/package/lens-4.15.4/docs/Language-Haskell-TH-Lens.html

Благодарю!

вопрос в возможности адаптации языка к доменной логике

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

который при минимальном усилии бы мог адаптироваться под похожии модели

а я получать бабло

-)))

и заниматься опенсорцом

потому что мне прикольно

just for fun

Благодарю!

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

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

TypeCompose

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

Хотя бы тезисно

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

Если ты про Int | String, то это как раз не очень хорошая вещь. Главным образом потому, что: 1)тег всё равно надо где-то хранить; 2) матчить по этой фигне проблематично.

Да собственно, то что хотелось бы писать TH уже пишу, просто эстетически мне это не нравится :( а псевдокод (рабочий!!) type1OfSignals = toList $ do "sig1" +: [["NodeId"]] "sig2" +: [] "req3" +: [["B.ByteString"], ["Chan", "MsgToSender"]] type2OfSignals = toList $ do "sig4" +: [["IP"]] "sig5" +: [] "req6" +: [["B.ByteString"], ["Chan", "MsgToSender"]] type3OfSignals = toList $ do "sig6" +: [["IP"]] "sig7" +: [] "req8" +: [["B.ByteString"], ["Chan", "MsgToSender"]] genType "signalsForNodeType1" $ type1OfSignals <> type2OfSignals genType "signalsForNodeType2" $ type2OfSignals <> type3OfSignals genType "signalsForNodeType3" $ type3OfSignals <> type1OfSignals

так я и спросил именно псевдокод, чтоб видеть как должно быть эстетически приемлемо

ну и интересно-то не объявление в первую очередь а пример обобщенной функции которая с таким будет работать

+1

зачем?

ну и интересно-то не объявление в первую очередь а пример обобщенной функции которая с таким будет работать

А что в обобщеной функции такого у неё стоит оганичени по классу (SignalsForNodeType3 a =>) например, а работает через автогенерируемые линзы.

Зачем вообще 3 типа сигналов?

для начала

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

предположения должны быть записаны

Зачем вообще 3 типа сигналов?

Чтобы каждый получал, только то, что ему нужно.

ну так "сливай" то что не матчится

предположения должны быть записаны

Разумное мнение...

в этом и смысл фунцкционального программирования

как в школе

дано

решение

результат

если не все данные смог описать то фигово

И оценки по пятибалльной системе, ага

Оно матчится, но смысл матчить, если можно гарантирровать, что тебе просто не смогут послать лишнего?

чем это гарантировано?

ты программируешь функцию

Тем, что канал типизирован.

она должна всегда одно на входе и одно на выходе давать

без вариантов

если нужны типы

то ты должен типизировать вход

нужны гарантии

вычислений

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

Оно матчится, но смысл матчить, если можно гарантирровать, что тебе просто не смогут послать лишнего?

я все рано не понял, что именно нужно, это не класси-призмы случайно?

Нет... призмы там пока не применяются. Ладно... в целом пока всё хорошо. Эстетику оставим в стороне, тем более как выглядит идеал вопрос сложный и не до конца ясный...

но это же АТД с нескольими конструкторами которые объединяются в другие?

блин, опять какое-то абстракционирование идет

не знаю как по русски

DoList - это...

УЖАС это

https://www.stackage.org/lts-10.3/package/do-list-1.0.1

разве прикольно понимать, то что другие не понимают

?

мы решаем по большому счеты задачи

которые относятся к классическим морфизмам

но как моей маме это обяснить?

так просто блин функция

https://www.stackage.org/lts-10.3/package/do-list-1.0.1

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

как ей объяснить что выпечка хлеба - морфизм?

но как моей маме это обяснить?

никак... протестировано на моей маме :)

А зачем тогда это надо если моя мама это не понимает?

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

На выходе пересекающиеся множества сигналов... пока в этом месте достаточно.

ну всегда были вроде математики

а сейчас вдруг все это рядом стало

На выходе пересекающиеся множества сигналов... пока в этом месте достаточно.

ну а сигналы эти - конструкторы? Т.е. мы работаем с некоторыми множдествами конструкторов, которые могут пересекаться

Ага, верно.

Ладно, я спать...