Даже сейчас один и тот же промпт, введённый дважды, даст два разных результата. Так что про "копирование" можете забыть. Не говоря уже о том, что там не "софт" а "дата", которая постоянно плывет...
Создание новых типов в таких случаях плодит лишние сущности, иногда подобные типы «выламываются» из общей системы, которую приходится под них адаптировать. А если еще добавить к этому, что это расширение библиотеки, которая не тобой писана… Увы, на частном примере это не очень хорошо заметно, поэтому и кажется, что проблема искусственная. В реальной ситуации, когда в системе десятки типов, это становится заметно, но как впихнуть такой пример в формат статьи, я пока не очень понимаю. Постараюсь все же развернуть тему чуть позднее.
Да, именованные экземпляры были бы неплохим решением. Интересно, что мешает их реализовать? Еще одну возможность я вижу в том, чтобы предоставить возможность перекрытия экземпляров в пределах модуля. В случае паранойи можно было бы предусмотреть расширение, которое отключающает проверку перекрытия экземпляров в некоторых случаях. А то получается, как в известной присказке — «Хаскель не даст вам прострелить свою ногу» :-).
Насчет «нужных в данный момент». Слишком часто такие определения многократно повторяются. Иначе не возникало бы желание обобщить их. Но не больше, чем это необходимо :-).
Двупараметрический тип попытались использовать как однопараметрический, редуцировав совершенно произвольно первый по порядку параметр. Или математика запрещает рассматривать другие случаи, когда нужно редуцировать, скажем, последний параметр, а остаток рассматривать как функтор?
Впрочем, в аппендиксе я все развернул. Я всего лишь против того, чтобы частное решение выносилось на уровень системы, тем более, в условиях, когда последствия такого решения невозможно заблокировать. Математика тут ни при чем.
Вообще, не очень удачно разделены группы. Поведение 2, 3, 4, 6, как правило, вызваны одной и той же чертой характера, поэтому почти всегда проявляются одновременно. То же самое можно сказать про пару 5, 7. Только первый и последний пункты стоят особняком.
Увы, скорее вынужден отнести себя к первой группе.
Спасибо! Честно говоря, просто замылился глаз, когда писал код, а компилятор не дал вменяемого сообщения — предложил заняться выводом типа, а не проверить вызов.
Приятно также, что увеличение сразу трех элементов теперь также работает. То есть, как минимум одну свою проблему я все-таки решил :-).
наверняка требуют RankNTypes расширения. Включите его.
Интересно, почему мне об этом ничего не сказал компилятор?
Самым простым, будет создать функцию
Увы, решение с отдельной функцией не подходит. Мне нужно либо вообще исключить кортежи из класса функторов, либо обеспечить единую обработку, но с нужным мне поведением.
Скажем так, если я заведу отдельную функцию both, то мне придется придумать, как реализовать вызов вида
both inc [1, 2, 3, 4, 5]
То, что вы пытаетесь определить как Функтор2 почти наверняка является БиФунктором.
Да, это классно. Теперь попробую еще поискать трифункторы. В другом комментарии я отметил, что это проблема семантического поиска. Я понимаю, что мне нужно, но не могу сказать, как именно это называется. Так что, hoogle не всегда рулит :-).
Написанную документацию тоже будут читать ИИ-агенты...
Я не извозчик, я водитель кобылы (с)
...пока не начнется вырождение в результате имбридинга...
Semver и Lock-файлы: ну да, ну да, пошли мы нахрен...
Поломку сортировки при смене таймзоны тоже можно поручить ИИ, он это неплохо умеет...
Коли человек разумен, то в принципе возможен только NGI, но не AGI. А так да, Пастернака не читал, но опровергаю (с)
Ещё веселее байка про "нема сечі терпіти ці пекельні борошна" (с) :-)
Никто и никогда не знает, какое из человеческих желаний приведет к экономическому прорыву. :-)
...и тут внезапно окажется, что опыт из реального мира вообще никак не коррелирует с опытом из "прочитанных" книжек :-)
Не получится. Потому что даже уже собранный человеческий мозг всё ещё нужно обучать, и то не всегда получается...
Даже сейчас один и тот же промпт, введённый дважды, даст два разных результата. Так что про "копирование" можете забыть. Не говоря уже о том, что там не "софт" а "дата", которая постоянно плывет...
Я бы написал. Ибо KISS рулит...
Что характерно, такая же хрень и с ИИ в ИТ будет...
Я переконвертировался в свидетеля раста :-)
Да, именованные экземпляры были бы неплохим решением. Интересно, что мешает их реализовать? Еще одну возможность я вижу в том, чтобы предоставить возможность перекрытия экземпляров в пределах модуля. В случае паранойи можно было бы предусмотреть расширение, которое отключающает проверку перекрытия экземпляров в некоторых случаях. А то получается, как в известной присказке — «Хаскель не даст вам прострелить свою ногу» :-).
Насчет «нужных в данный момент». Слишком часто такие определения многократно повторяются. Иначе не возникало бы желание обобщить их. Но не больше, чем это необходимо :-).
Впрочем, в аппендиксе я все развернул. Я всего лишь против того, чтобы частное решение выносилось на уровень системы, тем более, в условиях, когда последствия такого решения невозможно заблокировать. Математика тут ни при чем.
Вообще, не очень удачно разделены группы. Поведение 2, 3, 4, 6, как правило, вызваны одной и той же чертой характера, поэтому почти всегда проявляются одновременно. То же самое можно сказать про пару 5, 7. Только первый и последний пункты стоят особняком.
Увы, скорее вынужден отнести себя к первой группе.
Приятно также, что увеличение сразу трех элементов теперь также работает. То есть, как минимум одну свою проблему я все-таки решил :-).
Интересно, почему мне об этом ничего не сказал компилятор?
Увы, решение с отдельной функцией не подходит. Мне нужно либо вообще исключить кортежи из класса функторов, либо обеспечить единую обработку, но с нужным мне поведением.
Скажем так, если я заведу отдельную функцию
both, то мне придется придумать, как реализовать вызов видаДа, это классно. Теперь попробую еще поискать трифункторы. В другом комментарии я отметил, что это проблема семантического поиска. Я понимаю, что мне нужно, но не могу сказать, как именно это называется. Так что, hoogle не всегда рулит :-).