Эксистенциальный тип не прокатит?

Возможно, но я не сталкивался с ними близко - есть понятное введение?

Да, но вы можете в один словарь положить по ключу инт и по ключу стринг? А в сабже придется городить тип-сумму

Но это обычно плохой практикой считается, мне кажется, что строчек как ключей достаточно. Тут можно скатиться в перлизм "всё есть строка"

Ну "плохая практика" это оценочно и религиозно. Так можно дойти до ненужности гетерогенных списков )

Эксистенциальный тип не прокатит?

С экзистенциалами мы придём уже к эмуляции класс-ориентированного (или скорее интерфейс-ориентированного, в духе го) программирования

Мне бы понравилось, если бы все функции могли принимать условно любой тип и внутри по кейсам определять свое поведение в зависимости от WHNF типа - но без того чтобы городить этот универсум-тип-сумму руками явно. И думаю (надеюсь) Dynamic здесь будет ближе к желаемому. Хотя я мало его пробовал - поэтому и хотел посмотреть как это делают умельцы.

Тут же (при таком выборе) еще и гетерогенные коллекции (по значениям) бесплатно получаем - так?

Помню, кто-то написал статью "Хаскель - мой любимый императивный язык", продемонстрировав (о боже) как в ИО-монаде с дунотацией можно писать на нем в махровом императивном стиле.

Я бы очень хотел почитать такую же статью, только с заменой слова "императивный" на "динамический" - тем более все утверждают, что это можно

А так даже на банальном примере - мне надо полиморфную по типу функцию, которая будет печатать любой тип - если он инстанс Show - то брать его show, если нет - то писать "какая-то хрень". Но я навскидку не скажу как я могу написать в коде условие имплементации типом нужного класса

Мне хочется проверять в функции мое прилетевшее значение на то что оно умеет, и в зависимости от этого делать разное. А не чтобы мне компилятор гарантировал что оно это точно умеет из типа.

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

Я бы очень хотел почитать такую же статью, только с заменой слова "императивный" на "динамический" - тем более все утверждают, что это можно

Ну предполагается, что можно, если ты бойлерплейта много пишешь. По сути мы переносим синтаксис динамического языка на конструкторы нашего универсального типа. Была лямбда -- у нас конструктор Fn, был дикт или {, у нас Map, был литерал -- у нас String и т.д. Т.е. можно на динамический язык как на маленькое подмножество статического языка. А дальше есть проблема с тем, чтобы не пытаться размыть границы. То есть пока мы в узком мирке динамичности существуем всё хорошо (как в мирке IO в вашем примере выше). Как только мы выходим в жестокий мир остальных типов, но всё становится намного грустнее, потому что системф, типы с хитрыми кайндами или осколки зависимых типов просто не существуют во время рантайма. И вы с этим ничего не поделаете, вам просто некуда будет навесить тег об их поведении, понимаете? То есть скорее

Ну если брать аналогию из "императивной статьи" - там все получается красиво и элегантно - никто не запрещает нам написать сколько угодно чистых функций вне ИО и потом использовать их в ИО. И никаких жестких границ и проблем размытия - все очень гармонично

Если позволите аналогию с вульгарным ООП (джава) - то там я с типами могу провернуть точно такую же элегантную штуку по слиянию границ. Нужна мне функция на Интеджере - указываю ее тип максимально узким и ноннулабл. Надо расширить ее поведение на возможность принимать нулл (вульгарная Мэйби-монада для бедных) - убираю ноннулабл и пишу отработку нулла в ее теле - и все! И ничего больш ене переписываю и все работает! Надо расширить ее до Интов или Даблов - меняю тип аргумента на Интерфейс - и то же самое! Она волшебно научилась принимать любой тип нужного интерфейса. Надо расширить ее космически - меняю тип аргумента на Объект и внутри отрабатываю кейсы по любому инстансеОв и дефаултом если непонятно что. Вот так, элегантно и расширяемо (не надо писать про овноархитектуру, я в курсе вашего мнения). И ничего нигде в других местах переписывать при этом не надо - наша функция полиморфится до любой степени полиморфности, при этом изменяется только ее собственный код.

То же самое с коллекциями - надо - будут Интеджеры, надо - Интерфейсы, надо - Объекты. Я в курсе, что все считают Джаву статически типизируемым языком ) Но мне это никак не мешает в ней. Я понимаю, что это из-за ограничения ее системы типов иерархичной структурой. Но я могу написать статью в духе упомянутых выше: "Джава - мой любимый динамический язык". Причем, тут и С# и многие другие подойдут. Соль в том, что там я могу договориться с компилятором чтобы он делал только нужные мне проверки - а когда не надо, не мешал ) В сабже я так не могу и не знаю можно ли это вообще.

@bravit111 а будет запись лекции? или лучше, будет ли повтор лекции где-то еще?

Запись будет, а насчёт повтора не уверен, это ж меня кто-то позвать должен, а кому это надо...

у нас пересеклось с дедлайном прост

https://mail.haskell.org/pipermail/ghc-devs/2018-April/015557.html

https://mail.haskell.org/pipermail/ghc-devs/2018-April/015557.html

т.е., GHC будет писаться на Visual Studio? о, и SharePoint тут же

Да, но вы можете в один словарь положить по ключу инт и по ключу стринг? А в сабже придется городить тип-сумму

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

т.е., GHC будет писаться на Visual Studio? о, и SharePoint тут же

я только на 2/3 письма догадался в календарь заглянуть

The full power of Word :)

😂 👍🏻

сегодня почту открывать страшно

все шутить будут

вон вчера с ночи шутили что я чятике людей травлю и пруфы собирали : (

https://mail.haskell.org/pipermail/ghc-devs/2018-April/015557.html

это же троллинг

зачот

Письмо звучит, как реклама VS

как издевательство над стартапами

> 1 Apr This might be the thing

конечно

а что, team foundation еще живо?

а, сегодня первое апреля

надо отключить все каналы связи

хотя про ICO могли бы и провести, почему нет

а что, team foundation еще живо?

Team Foundation server мы используем

@cblp_su но зачем?

все шутить будут

То есть чатик в Logo Russian Community переименовывать не будем? :(

Я даже черепашку припас :(

а надо было?

Подскажите, а по каким причинам stack может не добавлять в exposed-modules некоторые модули?

У меня часть добавляется, а часть — нет.

Почему?

@cblp_su но зачем?

не я выбирал. наверно, потому что вся остальная инфраструктура уже от Микрософта

легаси, в общем

легаси, в общем

нет, свежее административное решение

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

Подскажите, а по каким причинам stack может не добавлять в exposed-modules некоторые модули?

в смысле не добавлять?

он же это автоматом не делает

имелся в виду hpack, наверное

Ну я вызываю stack build, появляется .cabal-файл. Там часть моих модулей указана, часть пропущена

Не пойму такой избирательности :-/

пиши их руками уже

И куда?

В какой файл?

в package.yaml

Хм, явно какой-то глюк. Пишу в package.yaml: library: source-dirs: src exposed-modules: Ontology.Math.NumRelations

В cabal-файле появляется

Ontology.Math.NumRelationsSubstitute

Откуда ...Substitute?

пиши package.cabal

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

В питоне ключём словаря может быть любой объект, если оный имеет __eq__ и __hash__

тогда экзестенциальные вопросы мучать не будут

пиши package.cabal

В смысле, вручную?

Не автогенерировать?

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

ага

Так это ж не молодёжно?

и кабал и стек сейчас говорят если модули есть

Надо ж на stack'е всё делать

такие

hpack не добавляет в exposed-modules то, что указано в other-modules, например

В питоне ключём словаря может быть любой объект, если оный имеет __eq__ и __hash__

Ну я и улитка

Не, я там всё вытер, там пусто в other-modules

пиши package.cabal

В моё время кабал вручную только и писали. А ща развелось автогенераторов

Можно почитать доку hpack. Возможно он слишком умный :) Или это бага и её надо отрепортить