и он это неоднократно заявлял

пруф есть в гугле

это что, mansplaining?

он имел ввиду под типами именно то что имеется под типами ввиду в хаскел

и под классами иммено то что в хаскел

λeonid пруф ты найдешь в гугле

лады

там же люди занимались математикой

а не жопоебным перекладыванием баз данных в вэб и складыванием обратно

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

а не выложить в интеренеты

на похапэ

и впринципе не важно на каком языке ты будешь еба..ся в ж..пу

да ты не кипятись, братан.

но блин надо иметь принципы -)))

да насрать ващеё

мне просто скучно -))

у кого-то нервишки шалят ))

и впринципе не важно на каком языке ты будешь еба..ся в ж..пу

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

Ты вообще смолтолк видел?

он имел ввиду под типами именно то что имеется под типами ввиду в хаскел

и под классами иммено то что в хаскел

вообще да

но это не говорит о том что я согласен -)

а с хаскел как то срослось

и понял и согласен

Его Кей и написал

Смолтолк

Ну я понимаю о чем ты

Где в хаскеле посылание сообщений?

Вопрос стоит не а конекртной реализации а вообще о принципе

Зачем нужно посылание сообщений?

Нужно ли оно вообще?

Оно нужно потому что так смоллталк придумано?

Почему вообще изменение состояния должно вызываться сообщениями?

Выбирать нужно. Шашечки или ехать. К Кею аппелировать или говорить о ненужности сообщений

Взять Эльм

Там сигналы

Ибо Хаскель уж точно не классическое ООП по Симуле и Смолтолку

Как в смолтолк

Зачем ооп вообще?

Там сигналы

Уже нет ?

В хаскель мне нравится теория типов напримеръ

да

язык не идеальный

Но выразительный же

К чему мы стремимся?

Значит Хаскель не нужен?

алан кэйс ниогда не имел ввиду под ооп то что вы имеете ввиду

он имел ввиду под типами именно то что имеется под типами ввиду в хаскел

и под классами иммено то что в хаскел

Зачем ооп вообще?

Хаскель нужен

Как эатп развития

как и этериум

или биткойн

Хаскель это очень хороший фундамент

Но не строительный блок

По крайней мере я так думаю

Что совсем ничего? Я не верю, что не существует библитечки позволяющей перебирать AST более комфортно :(

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

Зачем ооп вообще?

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

Это не я спрашивал

Гребаный телеграм

-)

лул

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

ERROR: S client not available

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

Суть такова

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

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 типа сигналов?

для начала

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

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