@Gleber1 http://xgrommx.github.io/rx-book/content/guidelines/using/index.html#use-the-publish-operator-to-share-sideeffects

Observable .ajax(..) .flatMap(...) .retryWhen() .publish() И далее будет уже мой map из пайпа идти, таким образом разве будет паблишится что то при этом возвращая мне результат flatMap?

То есть по сути нужно вернуть два action

нет не так

нужно запаблишить экшн а венуть результат запроса

Вот только там где мы запаблишем мы ведь должны быть полписаны на него а не на экшн который мы паблишим

если publish без селектора то надо еще refCount или connect потом, или просто share

оу https://github.com/purescript/purescript-eff/issues/29#issuecomment-350956258

@xgrommx И все же оно ведь шарит именно сайд эфеект do/subscribe а не возвращаемое значение если я верно понял

То есть мне то нужно запаблишить action при этом возвращая не экшн а то чо было до паблиша

https://github.com/safareli/purescript-fff

@ZeroBias поясни за флоу

че не так-то

чет у меня флоу не способен вообще ничего вывести

если сделать class Maybe<T> {} и отнаследоваться от него то все норм

зачем nothing генерик

чтобы map нормальный прописать

и chain потом

ну вообще я потыкал flow и он мне прямо сильно слабоватым показался, хз чего не так много чего и выводит (x => x нормально не выведет, даже если <T>(x: T) => x ), какие-то неясные баги с юнионом

то есть я не чувствую той прям надежности, что я за стеной типов и хуй что соберется, если я где-то что-то упущу

то есть я не чувствую той прям надежности, что я за стеной типов и хуй что соберется, если я где-то что-то упущу

вообще он сам выводит <T?x: T) => x из x => x

и ещё некоторые плюшки , но многого из тс не нахожу

шото этот флоу не але

хде выводит?

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

че не так-то

Просто посмотри на мою имплементацию

Не всегда изобретение велосипедов это правильный путь

да там был код для теста возможностей флоу

Я понимаю твой подход

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

Забудь его)

И конкретно с флоу я тебе серьёзно говорю, именно попытки разобраться "через имплементацию не глядя" приведут тебя в тотальное any

https://gist.github.com/kana-sama/e531b96adb87dfafb6f109161530a3b6 - вот такое сработало и это заебись

Из за редактора, потому что вс код по уебански работает

а что по твоему нормально работает?)

https://gist.github.com/kana-sama/e531b96adb87dfafb6f109161530a3b6 - вот такое сработало и это заебись

это простой пример

а что по твоему нормально работает?)

Ну не вставай так в позу, я могу бесконечно рассказывать о том, как всё отстойно в его имплементации)

https://gist.github.com/kana-sama/e531b96adb87dfafb6f109161530a3b6 - вот такое сработало и это заебись

Разница в том, что тут ты не пытаешься кастовать тип, а выводишь нормально)

const value: type это explicit cast, ето законно но не эффективно

да подожди

Из за редактора, потому что вс код по уебански работает

Вроде они обещали поработать над поддержкой флоу и дать возможность отключать проверки TS.

мы говорим про id

const id = x => x;

какой каст?

flow ide кстати на данный момент работает хуже стандартного

как узнать тип дефа через cli?

const id = x => x;

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVBjOA7AzgFzAEsATMAXjAA8KA+a9LPQgQwuJIAoBWASlRYA6fHABiRKgFMuvIA

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

как узнать тип дефа через cli?

Вбей в консоль flow help, там все команды будут

Ох

Ладно, сейчас встану

нет гарантий, что не будет number => string по типу

хорошо хоть не мономорфит по первому вызову

нет гарантий, что не будет number => string по типу

он знает что там T => T. a и b разных типов

или что ты ожидал обобщить ?

я ожидал вывод буквально <T>T => T

как это ожидается

да у них и плейграунд - херня

без подсветки )

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

и автокомплита

в случае тс плейграунда я бы постыдился выебываться

ERROR: S client not available

зачем тс вообще тут вспомнил?

Три сообщения выше

https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVUCuA7AxgFwEs5sxCATAHgBUA+ACgA8AuMagSlerAG8wAnAKb5M-UozABfdLhIBnfGACGYALxly9AKztUs7ArAAjNRvoByLed1KAdPjgAxQo0Gb2QA

тогда зачем вывод если самому приходиться указывать?

Чтобы ты спросил

щас бы уходить от вопросов и указывать на нерелевантные системы на подобии софизма "а вы госдолг сша видели?"

Тебе я уже вообще давно не собираюсь ничего доказывать и пояснять

Дейли ремайндер

меня не интересуют твои обидки

И конкретно с флоу я тебе серьёзно говорю, именно попытки разобраться "через имплементацию не глядя" приведут тебя в тотальное any

лул

Вроде они обещали поработать над поддержкой флоу и дать возможность отключать проверки TS.

а теперь вспомни, сколько месяцев они это обещают

чтобы флоу вывел полиморфный тип, нужно его вручную указать, после чего он его спокойно выводит из аннотации)

чтобы флоу вывел полиморфный тип, нужно его вручную указать, после чего он его спокойно выводит из аннотации)

ну если честно то в хаскелл id :: forall a . a -> a id x = x просто в многих местах этот forall имплисити

да ты шо

не верю

какое это имеет отношение к текущей теме?

В флоу кстати тот же принцип, во многих местах аннотация не потребуется, но так как ты здесь описываешь инвариантную функцию в бивариантном виде (проще говоря, записываешь её в корне), то требуется добавить тот же forall

Нормальным для вывода типа является ковариантная последовательность изменения типов (что ожидаемо)

Ввиду того, что принцип, превращающий декларацию в бивариантную запись не зависит от языка, было бы очень забавно, если бы флоу в данном случае не нуждался в forall в то время когда хаскель нуждается (но он не будет потому что это небезопасное суждение в общем случае) В то время как правила игры в хаскеле все принимают не рефлексируя, как есть, основная проблема жс же в том, что все дофига умные и твёрдо уверены, что лучше системы типов знают как надо мастачить выводы, даже если сами поди расты юзают

да дело не в этом, ты сейчас рассуждаешь со стороны правил вывода и какого-то порядка я рассуждаю со стороны юзера, который со всеми этими правилами вывода типов не знаком и для него АБСОЛЮТНО не понятно, почему λx.x имеет не ожидаемый тип ∀α. α → α, как видно из определения лямбды, а какие-то полумономорфные типы да и тип a|b -> a|b не гарантирует же, что для a вернется именно a (но это почему-то работает, полагают там какой-это имплиситный индекс или неявный анализ какой-то)

Да нифига у тебя тут не видно, в этом и прикол

Я именно про это и говорю

Твоё суждение о том, что здесь обязан быть a -> a по дефолту нарушит контрвариантное использование этой функции

Именно в этом смысл forall a

Ты явно задаёшь ограничения на сабтайпинг

И только после этого можешь юзать так как тебе хочется

ага, стопец, сабтайпинг, я понял

Твоё суждение о том, что здесь обязан быть a -> a по дефолту нарушит контрвариантное использование этой функции

это когда я возвращаю подтип?

я все думал, какая тут вообще разница, бивариативность у нас или инвариативность

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

хотя я погулил, existential quantification таки что-то меняет