Так как даже если мы сделаем hkt например в виде транспилятора в флоу, то под капотом всё равно должно быть что-то в таком духе

так а какая мне будет разница, что там под капотом

важно чтобы мне это писать не пришлось

открой fp-ts

типа такого? https://gist.github.com/kana-sama/0eec961da2c59dcdfa7dcddf5dfa9da4

Хз, вроде так

Я точно знаю, что в флоу можно проще, но так как гканти пишет на тс, то пусть делает как знает, а я чот устал от этого после года попыток

куда он дел

флоу

он сказал удалять не будет

Лол

"Концепция поменялась"

ну че за хуйня

ох пурса) https://twitter.com/jusrin00/status/964201036046053376

ну че за хуйня

Вовремя я funfix затестил

это одна конструкция!)

вся тайплевел магия в это вылазит с символами

интересно что за конструкция

У меня такое ощущение что я знаю в чем проблема

Перекликающаяся с затяжной разработкой флоу

типа такого? https://gist.github.com/kana-sama/0eec961da2c59dcdfa7dcddf5dfa9da4

export type HKT<F, U, L, A> = $PropertyType<$ObjMap<{ Self: [U, L, A] }, F>, 'Self'>

Фигня вся в том, что пока ты делаешь формализацию языка на етом вашем хаскельокамле — ты на коне и всё у тебя получается гладко и быстро, когда ты начинаешь формализацию хардкорного бескомпромиссно злобного прототипного наследования для js — ты в дерьме

И это реально всё объясняет

И почему у них es6 нет, и почему до сих пор не оптимизируются тривиальнейшие конструкции и так далее

Пацаны просто не вывезли

export type HKT<F, U, L, A> = $PropertyType<$ObjMap<{ Self: [U, L, A] }, F>, 'Self'>

Через $Call

ну да

Пацаны просто не вывезли

Короче единственный вариант — перестать понтоваться и сделать фп начиная не от хаскеля а от js, скорее всего с помощью бабеля

Я реально больше не вижу альтернатив; люди, которые в гробу видали весь ваш js никогда не сделают качественной имплементации компиляции в него же

Что означает, что теперь надеяться можно только на самих себя

Такие дела

и изредка Just

Если просто оставить открытым или редактировать код при этом? При редактировании разные треды могут накладываться Я ещё не успел портировать из redux-most поддержку hot reload

У меня всё это время в фоне был открыт репл, вроде распределение нормальное)

?

очень часто я сталкиваюсь с проблемой описаний матриц

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

простой пример - ADT и ООП - это по сути матрицы возможных значений и методов, ADT - закрытие множество значений и открытое множество методов, ООП - открытое множество значений, закрытое множество методов вот сейчас я решил наконец подумать про апи библиотеки для реализаций конечных автоматов. По сути конечный автомат это тоже таблица состояний и экшонов. Имея состояние и экшон мы можем по таблице узнать, какой экшон будет следующий Проектировать АПИ мы можем двумя разными способами - делать открытое множество состояний и закрытое множество экшонов (то есть сначала указываем список экшонов, а потом строим сколько угодно состояний) - делать октрытое множество экшонов и закрытое множество состояний (сначала указывает состояния, потом переходы) У обоих проблем я вижу одну фундаментальную суть, и мне кажется ее кто-то давно изучил и нашел какие-то тактики по решению этой неоднозначности

кто-нибудь слышал про такое? Какие пейперы?

а, нет, все проще лол

тут будет закрытое множество и экшонов, и состояний

а еще тут где-то зарыта дуальность

есть кметтовские машинки https://hackage.haskell.org/package/machines

хотелось бы конечно иметь такой инструмент как "уникальный тип". Я не знаю его настоящего названия, чтобы мы могли замкнуть все объекты, созданные с этим типом. Пример с той же машиной: создаем некую "машину", она нам дает некий уникальный тип. Все экшоны и состояния, созданные для этой машины, будут фантомно помечены этим типом, и поэтому их нельзя будет использовать для других машин можно было бы применить экзистенциальные типы как в ST хаскеля, там подобная проблема, но во флоу такого тоже нет вроде

есть кметтовские машинки https://hackage.haskell.org/package/machines

а это точно те же машинки?

я их не трогал, но думал, они про другое

хотелось бы конечно иметь такой инструмент как "уникальный тип". Я не знаю его настоящего названия, чтобы мы могли замкнуть все объекты, созданные с этим типом. Пример с той же машиной: создаем некую "машину", она нам дает некий уникальный тип. Все экшоны и состояния, созданные для этой машины, будут фантомно помечены этим типом, и поэтому их нельзя будет использовать для других машин можно было бы применить экзистенциальные типы как в ST хаскеля, там подобная проблема, но во флоу такого тоже нет вроде

opaque ?

это не то вроде, если я правильно их понимаю

хотелось бы конечно иметь такой инструмент как "уникальный тип". Я не знаю его настоящего названия, чтобы мы могли замкнуть все объекты, созданные с этим типом. Пример с той же машиной: создаем некую "машину", она нам дает некий уникальный тип. Все экшоны и состояния, созданные для этой машины, будут фантомно помечены этим типом, и поэтому их нельзя будет использовать для других машин можно было бы применить экзистенциальные типы как в ST хаскеля, там подобная проблема, но во флоу такого тоже нет вроде

тэг повесить мб?

что за тэг? Ограничить я хочу не себя, а юзера, который пользуется моими функциями

ну для тега есть фантом Tagged

есть кметтовские машинки https://hackage.haskell.org/package/machines

Plan это из join patterns?

Plan это из join patterns?

это некий генератор

есть кметтовские машинки https://hackage.haskell.org/package/machines

сам с либой разбирался?

сам с либой разбирался?

та так, одним глазком глянул

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

ага

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

все это же конечные автоматы, мили, мура и тд

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

слушай может ты въедешь до конца) для меня это ща как Codensity IO просто как хитрый враппер над конинюейшн процессов (упрощает управление одним ресурсом) https://hackage.haskell.org/package/managed-1.0.6 мб ты поймешь что-то другое

ого, неплохо, неплохо. Ну да, это просто Codensity IO, ничего другого я не понял, но либу взял на заметку, благодарю собственно смысл в чем - с помощью монад и do-синтаксиса мы можем убирать вложенность (вложенность колбеков, вложенность проверок на Just, вообще понятие "вложенность"). Вот тут у нас вложенность withXXX, сделали конструкцию монадой и убрали эту вложенность

ого, неплохо, неплохо. Ну да, это просто Codensity IO, ничего другого я не понял, но либу взял на заметку, благодарю собственно смысл в чем - с помощью монад и do-синтаксиса мы можем убирать вложенность (вложенность колбеков, вложенность проверок на Just, вообще понятие "вложенность"). Вот тут у нас вложенность withXXX, сделали конструкцию монадой и убрали эту вложенность

ну то понятно, что там будет лапша из колбеков

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

import Control.Monad.IO.Class import Control.Monad.Codensity import System.IO import Control.Monad.Managed managedActions' :: Managed () managedActions' = do input <- managed (withFile "src/input.txt" ReadMode) output <- managed (withFile "src/output2.txt" WriteMode) contents <- liftIO $ hGetContents input liftIO $ hPutStr output contents managedActions :: Codensity IO () managedActions = do input <- Codensity $ withFile "src/input.txt" ReadMode output <- Codensity $ withFile "src/output.txt" WriteMode contents <- liftIO $ hGetContents input liftIO $ hPutStr output contents main :: IO () main = do lowerCodensity managedActions runManaged managedActions'

ого, неплохо, неплохо. Ну да, это просто Codensity IO, ничего другого я не понял, но либу взял на заметку, благодарю собственно смысл в чем - с помощью монад и do-синтаксиса мы можем убирать вложенность (вложенность колбеков, вложенность проверок на Just, вообще понятие "вложенность"). Вот тут у нас вложенность withXXX, сделали конструкцию монадой и убрали эту вложенность

а что ты имеешь ввиду вложенность проверок на Just?

да Maybe, если писать без монад, там на каждое действие появился case и вложенность будет расти мое замечание в том, что монады в общем случае убирают такие любые линейно увеличивающие уровни вложенности (что очень абстрактно видно из сигнатуры join M (M a) -> M a)

да Maybe, если писать без монад, там на каждое действие появился case и вложенность будет расти мое замечание в том, что монады в общем случае убирают такие любые линейно увеличивающие уровни вложенности (что очень абстрактно видно из сигнатуры join M (M a) -> M a)

ну как бы да) сплющивают некую структуру

ну пока как для операций IO я Managed не вижу) а вот Codensity (Maybe Int) например

import Control.Monad.IO.Class import Control.Monad.Codensity import System.IO import Control.Monad.Managed managedActions' :: Managed () managedActions' = do input <- managed (withFile "src/input.txt" ReadMode) output <- managed (withFile "src/output2.txt" WriteMode) contents <- liftIO $ hGetContents input liftIO $ hPutStr output contents managedActions :: Codensity IO () managedActions = do input <- Codensity $ withFile "src/input.txt" ReadMode output <- Codensity $ withFile "src/output.txt" WriteMode contents <- liftIO $ hGetContents input liftIO $ hPutStr output contents main :: IO () main = do lowerCodensity managedActions runManaged managedActions'

смысл либы возможно в MonadManaged и куче инстансов для склейки ресурсов типа Monoid, Num

все равно пока не придумал крутого применения

MonadManaged нужен для вклейки монады в продакшен-стек

коденсити например так фиг вклеишь

добротного примера пока придумать не могу

лол

так, пацаны, которые хоть немного шарят в автоматах

у стейта может быть стейт?)

ну то есть можем ли мы вместо какого-либо стейта использовать семейство стейтов

все еще плохо, еще одна попытка

у стейта может быть стейт?)

я бы это назвал неким деревом автоматов, и у него должна быть хитрая свертка например через traversable я делал RoseTree Observable -> Observable RoseTree типа у меня было розовое дерево из каких-то событий и я после traversable получал то что надо инкрементальные слепки деревьев

возьмем типичный пример - турникет у него два состояния: открыт и закрыт и два экшона: дать монетку и толкнуть (открыт, дать монетку) -> открыт (открыт, толкнуть) -> закрыт (закрыт, дать монетку) -> открыт (закрыт, толкнуть) -> закрыт я хочу расширить это тем, что например если я положу две монетки подряд, то я могу и толкнуть минимум два раза подряд (открыт_n, дать монетку) -> открыт_n+1 (открыт_0, толкнуть) -> закрыт (открыт_n+1, толкнуть) -> открыт_n (закрыт, дать монетку) -> открыт_0 (закрыт, толкнуть) -> закрыт

возьмем типичный пример - турникет у него два состояния: открыт и закрыт и два экшона: дать монетку и толкнуть (открыт, дать монетку) -> открыт (открыт, толкнуть) -> закрыт (закрыт, дать монетку) -> открыт (закрыт, толкнуть) -> закрыт я хочу расширить это тем, что например если я положу две монетки подряд, то я могу и толкнуть минимум два раза подряд (открыт_n, дать монетку) -> открыт_n+1 (открыт_0, толкнуть) -> закрыт (открыт_n+1, толкнуть) -> открыт_n (закрыт, дать монетку) -> открыт_0 (закрыт, толкнуть) -> закрыт

replicateM 2 push » replicateM 2 pull

/pidor@SublimeBot

Woop-woop! That's the sound of da pidor-police!

Ведётся поиск в базе данных

Я в опасности, системы повреждены!

Ну ты и пидор, ilia auvinen

replicateM 2 push » replicateM 2 pull

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

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

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

какие-то завтипы уже

ну да

)

ну да

http://docs.idris-lang.org/en/latest/st/machines.html

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

самое время

https://youtu.be/X36ye-1x_HQ?t=1877

возьмем типичный пример - турникет у него два состояния: открыт и закрыт и два экшона: дать монетку и толкнуть (открыт, дать монетку) -> открыт (открыт, толкнуть) -> закрыт (закрыт, дать монетку) -> открыт (закрыт, толкнуть) -> закрыт я хочу расширить это тем, что например если я положу две монетки подряд, то я могу и толкнуть минимум два раза подряд (открыт_n, дать монетку) -> открыт_n+1 (открыт_0, толкнуть) -> закрыт (открыт_n+1, толкнуть) -> открыт_n (закрыт, дать монетку) -> открыт_0 (закрыт, толкнуть) -> закрыт

в этом случае убрать зависимость результата функции от индекса состояния можно (добавив третье состояние), но я не уверен, что это возможно всегда (только-открыт, дать монетку) -> открыт_0 (только-открыт, толкнуть ) -> закрыт (открыт_n , дать монетку) -> открыт_n+1 (открыт_0 , толкнуть) -> только-открыт (открыт_n+1 , толкнуть) -> открыт_n (закрыт , дать монетку) -> только-открыт (закрыт , толкнуть) -> закрыт

а, нет, я не убрал, осталась зависимость открыт(n) -> только-открыт | открыт, а автомат усложнился

/pidor@SublimeBot

Согласно моей информации, по результатам сегодняшнего розыгрыша пидор дня - Ilia!