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

в этом плане доставляют скринкасты сноймана

да чо дети...

у меня во время scrum чуваки стены делали

обшивали OSB

https://www.tweag.io/posts/2018-09-12-asterius-ffi.html @qnikst inline-wasm?

позже

пусть по человечески статик поинтеры использует сначала

ему вчера сказали, чтобы distributed-closure не переизобретал

Воу, это если доделать сделает GHCJS deprecated

это займет время

но вообще есть шанс, там вроде ещё дочерта работы

А TH как вообще планируется делать?

хз

там и гц-то нет, какой тх

все еще думаю, что webghc раньше юзабельным будет

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

в чём проблема бинарника в сотни мб?

Ну если этот бинарник часть веб странички....

веб?

wasm, это всё...

Не, соти мб это никуда не годится, после оптимизации и ужимания GHCJS выдаёт 500кб

500 кб - это для хелло ворлда?

Для проекта на 30к строк кода и 100+ модулей

ну и зависимостей штук 40-50

А сколько весит гхцжс, собранный собой?

Я не пробовал

в теории достаточно собрать программу с hint пакетом и посмотреть

Ну я хочу гхц на телефоне

Есть ещё ARM кросскомпиляция

Хм, нет, недостаточно, он посчитал себя dead code

и выпилил

надо ещё что-то поюзать там, репл например

Собери сам хгц как нодежс приложение

С его мега обвесом для нескольких stage и booting это будет нелегко

Использование ghc-api даже показательнее для практики будет

А сколько весит гхцжс, собранный собой?

он сам себя не соберет

Он как минимум должен уметь линковать сам себя к бинарям

он сам себя не соберет

(настало время собирать гхцжс. ghcjs сам себя не соберет. зачем мне llvm? у меня нет времени, чтобы…)

@ViktorCai будет жить. Поприветствуем!

@satiataoff будет жить. Поприветствуем!

Ребят, может ли кто - то просветить про mtl-style?

mtl style - это подход объединения моданических эффектов на основе интерфейсов. В этом подходе вводится 1 тип, и говорится какие эффекты он в себе инкапсулирует.

т.е. у нас есть описание эффектов MonadReader, MonadWriter, MonadIO ...

и есть тип data M = и мы говорим через instance MonadReader M ... что он может содержать в себе эффект Reader

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

т.е. напрмер: foo :: (MonadReader e m, MonadState s m) => a -> m b

в этом случае foo может работать с любым m который реализует соотвествующие инстансы

в дополнение к этому существуют дополнительные возможности

Ого, мощно, надо будет поробовать в скале попробовать

поскольку у нас есть трансформеры для которых есть инстансы MTL, то ReaderT e (StateT s m) имеют уже написанные инстансы MonadReader и MonadState

может лучше или перформантнее стеков

но там есть ограничения, которые всех бесят и поэтому пытаются изобретать что-то другое

т.е. если не думать про кейс описанный выше, то mtl решает проблему автоматического лифтинга в трансформерах

еее

(но с вводом функциональных зависимостей)

но там есть ограничения, которые всех бесят и поэтому пытаются изобретать что-то другое

интересно послушать, кто как с этим живёт

и можно сделать: newtype M = M { runM :: StateT S (ReaderT R IO) a } deriving (MonadState S, MonadReader R, MonadIO)

атоматом получив инстансов кучу

проблемы с mtl, т.к. у нас везде интерфесы, то оно будет тормозить без специализации

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

ERROR: S client not available

(или забить то дого как на самом деле словишь performance problem)

в этом отношении чистые трансформеры лучше, тем, что там все известно и у симлификатора больше шансов сделать работу

интересно послушать, кто как с этим живёт

есть несколько решений, старое описано у Pipponi это добавить теги, тем самым убрав зависимость, реализовано в ether

есть layers и monad-classes Ромы

про них я хорошо не скажу, я не использовал их в реальной жизни

поскольку я склонен считать первый описанный кейс - основным

ну и эффекты, они тоже решают эту проблему

но лучше про них, скажем @graninas спросить, он их и прочий free(r) любит

или ещё кого

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

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

типа популярного пакета, который можно было с -XSafe отправить в segfault за 1 минуту анализа кода

сейчас экосистема подрасширилась

ну и эффекты, они тоже решают эту проблему

что имеется в виду под эффектами?

Algebraic Effects

extensible-effects, freer и все это

там целая пачка либ, но нужно внимательно смотреть что ещё поддерживают

недавно в Haskell cafe был тред на эту тему

но в целом mtl (tagless) подход и free/effect (tagged) выражаются друг через друга

freer ближе к free, но tagless если мне не изменяет память

эти вещи потормознее, т.к. тащут интерпретатор эффектов с собой

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

зачем они могут быть нужны можно смотреть в статье олега про extensible-effects

он там показывает как некоторые юзкесы с mtl,tf выражаются излишне сложно в отличии от эффектов

как-то так

Есть еще одно решение от @int_index для решения проблемы расширяемых эффектов (если я правильно понимаю): https://github.com/int-index/caps Мы даже писали быструю маму для зависимых типов, чтобы caps работал получше и побыстрей: https://github.com/kowainik/typerep-map Надеюсь, что Влад когда-нибудь опишет более подробно свое решение, я не использовал, но хотелось бы узнать сравнение с другими подходами...

Victor будет жить. Поприветствуем!

Хай бледнолицые!

И сразу офтоп, может кто знает что с русскоязычным чатом о Rust случилось? Не могу его найти.