@fsharp_flood - страница 2354

Ilya

Чо это за стрелочка, кстати? Перл какой-то.

Shub

первая ссылка на сохацкого сразу, лол

Hog

Чо это за стрелочка, кстати? Перл какой-то.

стопэ

Крылатый

Неужели не понятно? Вот плюсик в кружочке, а вот стрелочка.

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

Doge

https://0-8-2.arrow-kt.io/docs/apidocs/arrow-optics/arrow.optics/-p-optional/codiagonal.html Ну так оно. Линзы и кококо.

Просто я же линзы из Control.Lens использую, в скале или тем более котлине я ими не злоупотребляю. Но да, идея откуда название теперь понятно.

Ilya

Я нашёл какую-то пдфку Asymmetric Lenses in Scala Тони Морриса.

Ilya

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

Ну оператор плюсик в кружочке я из универа помню. Но я не помню, что он делает.

Ilya

Не исключено, что это совсем другой оператор плюсик в кружочке.

Ilya

https://stackoverflow.com/questions/839479/what-does-a-circled-plus-mean Эм, XOR.

Крылатый

Это там ксор.

Крылатый

А тут может быть что-то другое?)

Ilya

А, ну типа два опшина со значением дают None!

Ilya

Полезная штука.

Doge

Не исключено, что это совсем другой оператор плюсик в кружочке.

В данном случае автор видимо имеет тип сумму в виду. Т.е. A ⊕ B изоморфно Either[A,B] Т.к. выше он для типа-произведения использует ⊗ (Т.е. A ⊗ B изоморфно (A, B))

Doge

Cм. в статье пункт: 4. Representing an Asymmetric Lens in Scala

Shub

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

Doge

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

Ну название для функции Choice a a -> a и вправду так себе. Но сложно для обобщенной штуки такого рода придумать разумное название.

Shub

прям вот представляю следующую беседу с ПМами - "вы чо, чуваки, не понимаете разве, что ваша фича не сработает, ведь в картезианской бикатегории пара термов диагональный и бидиагональный ссылаются на каноническое ко-умножение и дуальное умножение? вы тупые штоле?"

Shub

Ну название для функции Choice a a -> a и вправду так себе. Но сложно для обобщенной штуки такого рода придумать разумное название.

видишь ли, комизм ситуации в том, что конкретно эта кодобаза застряла на уровне F# 3.5, поэтому племенное знание - это что Choice на самом деле Result. и в связи с этим я хочу поинтересоваться: какой больной ублюдок придумал использовать Result<a,a>?

Doge

видишь ли, комизм ситуации в том, что конкретно эта кодобаза застряла на уровне F# 3.5, поэтому племенное знание - это что Choice на самом деле Result. и в связи с этим я хочу поинтересоваться: какой больной ублюдок придумал использовать Result<a,a>?

Ну в процессе преобразований (за счёт mapr) получают Result<a,a>, ну а дальше нужна функция, чтобы достать оттуда единственное значение. Нормальные люди её называют fromResult, см: https://hoogle.haskell.org/?hoogle=Either%20a%20a%20-%3E%20a%20 У вас решили выпендреться

Hog

видишь ли, комизм ситуации в том, что конкретно эта кодобаза застряла на уровне F# 3.5, поэтому племенное знание - это что Choice на самом деле Result. и в связи с этим я хочу поинтересоваться: какой больной ублюдок придумал использовать Result<a,a>?

а внутри a - код ошибки? :)

Ilya

Shub

а внутри a - код ошибки? :)

ну если он в обоих веточках находится, то как он может быть кодом ошибки?

Ilya

О, кажется, я понял, какую проблему пытаются решить линзы. Хороший документик.

Shub

Ну в процессе преобразований (за счёт mapr) получают Result<a,a>, ну а дальше нужна функция, чтобы достать оттуда единственное значение. Нормальные люди её называют fromResult, см: https://hoogle.haskell.org/?hoogle=Either%20a%20a%20-%3E%20a%20 У вас решили выпендреться

это какое- то шизотипическое мышление, ты не находишь?

Hog

ну если он в обоих веточках находится, то как он может быть кодом ошибки?

| Error ({ Oshibka = x }) -> ...

Крылатый

| Error ({ Oshibka = x }) -> ...

У меня перманентные флешбеки от таких названий

Hog

У меня перманентные флешбеки от таких названий

уретрирую

Крылатый

уретрирую

Пожалуйста, только не при всех.

Doge

это какое- то шизотипическое мышление, ты не находишь?

Ну идея была сделать что-то вроде unwrap_or_else в том же расте, как бы идея здравая, но реализация так себе.

Doge

Как минимум надо было в отдельную функцию выделить вот это mapr |> codiag и назвать её приличнее.

Denis

member unwrapOrElse с AutoOpen и вперед

Denis

Как с крышкой делают

Dr. Friedrich

https://hisham.hm/2020/01/20/dynamic-type-systems-arent-even-simpler/

Ilya

You follow through the code to see all places that third argument is used and realize the accepted type of the third argument depends on what you give to the second argument. А зачем так делать?

Vasiliy

там графон показывают

Ilya

You follow through the code to see all places that third argument is used and realize the accepted type of the third argument depends on what you give to the second argument. А зачем так делать?

Это ж выстрел в ногу почти гарантированный.

Vasiliy

Epic Games анонсировала Unreal Engine 5 и показала длинное демо на движке, которое работает на PS5. Первая полноценная демонстрация возможностей консолей нового поколения. https://dtf.ru/hard/135122

Shub

Ну идея была сделать что-то вроде unwrap_or_else в том же расте, как бы идея здравая, но реализация так себе.

я не сильно понимаю, почему это может быть здравая идея. Result<> традиционно используется, чтобы заэнкодить два разных состояния, каждое из которых может быть детализировано (DU для успешных операций, DU для неуспешных) и явно зафорсить два разных обработчика для обеих видов возврата. если кому-то нужно только значение из Result - зачем заворачивать возврат в Result?

Doge

я не сильно понимаю, почему это может быть здравая идея. Result<> традиционно используется, чтобы заэнкодить два разных состояния, каждое из которых может быть детализировано (DU для успешных операций, DU для неуспешных) и явно зафорсить два разных обработчика для обеих видов возврата. если кому-то нужно только значение из Result - зачем заворачивать возврат в Result?

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

Shub

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

что в принципе делается таким же количеством строк без морфизмов и странных конверсий Result<a,b> -> Result<a,a>

Doge

что в принципе делается таким же количеством строк без морфизмов и странных конверсий Result<a,b> -> Result<a,a>

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

Крылатый

Epic Games анонсировала Unreal Engine 5 и показала длинное демо на движке, которое работает на PS5. Первая полноценная демонстрация возможностей консолей нового поколения. https://dtf.ru/hard/135122

Нет RTX, дизлойс отпизка

Shub

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

хз, я не вижу никакого выигрыша, ни от функции, ни от логики. кодировать логику дефолтным значением резалта - а зачем нам системы типов тогда? давайте неуспешное тоже кодировать значением, например пустым списком, или там каким-то bottom value

Doge

хз, я не вижу никакого выигрыша, ни от функции, ни от логики. кодировать логику дефолтным значением резалта - а зачем нам системы типов тогда? давайте неуспешное тоже кодировать значением, например пустым списком, или там каким-то bottom value

Ну значение может быть по логике. Т.е. какой-нибудь fallback по бизнес-логике - это нормально.

Крылатый

хз, я не вижу никакого выигрыша, ни от функции, ни от логики. кодировать логику дефолтным значением резалта - а зачем нам системы типов тогда? давайте неуспешное тоже кодировать значением, например пустым списком, или там каким-то bottom value

bottomless

Doge

хз, я не вижу никакого выигрыша, ни от функции, ни от логики. кодировать логику дефолтным значением резалта - а зачем нам системы типов тогда? давайте неуспешное тоже кодировать значением, например пустым списком, или там каким-то bottom value

Ну здесь не логика, здесь что-то типа, если такой-то процесс прошел успешно, то возьми значение из него, если нет - залоггируй причину и возьми такое-то fallback значение.

Doge

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

Shub

Ну здесь не логика, здесь что-то типа, если такой-то процесс прошел успешно, то возьми значение из него, если нет - залоггируй причину и возьми такое-то fallback значение.

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

Doge

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

Я же не знаю контекста, я описываю скорее где может понадобится функция подобного плана в общём случае. Как пример, в расте тот же unwrap_or_else есть из коробки на резалте именно с таким поведением.

Shub

@grishace есть где-то нормальный гайд по asyncseq? кроме блога петрищчика и недописанной офдоки ничего не находится

Hog

@grishace есть где-то нормальный гайд по asyncseq? кроме блога петрищчика и недописанной офдоки ничего не находится

Это оно :(

Igor

@vshapenko а ваше приложение на f# можно скачать/посмотреть? под android

Vasily

Пока нет

Igor

давайте уже, а то нечем крыть что "на xamarin не пишут софт"

Vladimir

@grishace есть где-то нормальный гайд по asyncseq? кроме блога петрищчика и недописанной офдоки ничего не находится

у меня есть небольшой пример) https://github.com/fsharplang-ru/pulsar-client-dotnet/blob/develop/src/Pulsar.Client/Internal/MultiTopicsConsumerImpl.fs#L72-L82

Ayrat

у меня есть небольшой пример) https://github.com/fsharplang-ru/pulsar-client-dotnet/blob/develop/src/Pulsar.Client/Internal/MultiTopicsConsumerImpl.fs#L72-L82

А можно было сразу через match!

Ayrat

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

Ayrat

Надо посмотреть

Vladimir

А можно было сразу через match!

согласен) правда наверное это писалось еще до того как match! зарелизили)

Shub

у меня есть небольшой пример) https://github.com/fsharplang-ru/pulsar-client-dotnet/blob/develop/src/Pulsar.Client/Internal/MultiTopicsConsumerImpl.fs#L72-L82

хороший пример. я приблизительно до такого дошел своим умом. вообще ответ на мой вопрос нашелся как ни странно в примерах для AsyncSeq

Vladimir

согласен) правда наверное это писалось еще до того как match! зарелизили)

а нет, ниже по коду там как раз match!

Shub

кстати, вот этот сниппет match message with | Result msg -> let newMessageId = { msg.MessageId with TopicName = topic } yield Result { msg with MessageId = newMessageId } | ex -> yield ex -- это случайно не Result.map?

Shub

впрочем это не существенно

Shub

ща, у меня другой вопрос есть

Vladimir

Да) Только там кастомный Result, поэтому нет)