p
Тайп-классы Functor, Applicative, Monad, и пучок отдельных функций над монадами?
Ага, и потом делать Box<dyn Monad> везде😊
Size: a a a
2020 April 01
G
Ага, и потом делать Box<dyn Monad> везде😊
M: Monadp
M: MonadТы не сможешь вернуть две разные монады из функции)
G
Ты не сможешь вернуть две разные монады из функции)
(impl Monad, impl Monad)p
(impl Monad, impl Monad)Тоже не сможешь вернуть две разные монады
G
Тоже не сможешь вернуть две разные монады
Вот две разные монады, в чём проблема?
p
Вот две разные монады, в чём проблема?
Если что, я про это:
fn() -> Monad {
if cond { Monad1::new() }
else { Monad2::new() }
}
fn() -> Monad {
if cond { Monad1::new() }
else { Monad2::new() }
}
G
Если что, я про это:
fn() -> Monad {
if cond { Monad1::new() }
else { Monad2::new() }
}
fn() -> Monad {
if cond { Monad1::new() }
else { Monad2::new() }
}
Either
p
Either
Костыль
МБ
Костыль
Математика. Иначе, красиво и компонуемо не сделать при строгой типизации.
DS
Если что, я про это:
fn() -> Monad {
if cond { Monad1::new() }
else { Monad2::new() }
}
fn() -> Monad {
if cond { Monad1::new() }
else { Monad2::new() }
}
Такой код обычно не нужен.
Т.к. ты всё равно обычно работаешь с одним стэком эффектов. (Пусть будет Если есть какой-то локально используемый эффект G, то его обычно всегда можно через G ~> M в М засунуть.
Т.к. ты всё равно обычно работаешь с одним стэком эффектов. (Пусть будет Если есть какой-то локально используемый эффект G, то его обычно всегда можно через G ~> M в М засунуть.
p
Такой код обычно не нужен.
Т.к. ты всё равно обычно работаешь с одним стэком эффектов. (Пусть будет Если есть какой-то локально используемый эффект G, то его обычно всегда можно через G ~> M в М засунуть.
Т.к. ты всё равно обычно работаешь с одним стэком эффектов. (Пусть будет Если есть какой-то локально используемый эффект G, то его обычно всегда можно через G ~> M в М засунуть.
у меня постоянно перечисления на 10-15 вариантов
PS
Математика. Иначе, красиво и компонуемо не сделать при строгой типизации.
Это как раз к вопросу dynamic vs static в контексте компиляторов. Программист на Scheme, например, с трудом сможет себе вообразить сложности, которые заставили специалистов использовать монады для реализации комбинаторов парсеров. В целом, если говорить об общих подходах, то программирование на уровне комбинаторов как раз таким и является, на мой взгляд. В то время как монады — необходимая в некоторых случаях деталь реализации :)
DS
Это как раз к вопросу dynamic vs static в контексте компиляторов. Программист на Scheme, например, с трудом сможет себе вообразить сложности, которые заставили специалистов использовать монады для реализации комбинаторов парсеров. В целом, если говорить об общих подходах, то программирование на уровне комбинаторов как раз таким и является, на мой взгляд. В то время как монады — необходимая в некоторых случаях деталь реализации :)
Монады - с практической точки зрения - это прежде всего способ переиспользования кода, который использует данный тайпкласс для композиции значений.
И в этом смысле он достаточно ключевой, т.к. компизация такого плана встречается очень много где и его наличие позволяет более-менее удобно шарить реализации многих функций для совершенно различных типов.
И в этом смысле он достаточно ключевой, т.к. компизация такого плана встречается очень много где и его наличие позволяет более-менее удобно шарить реализации многих функций для совершенно различных типов.
ИЧ
Монады - с практической точки зрения - это прежде всего способ переиспользования кода, который использует данный тайпкласс для композиции значений.
И в этом смысле он достаточно ключевой, т.к. компизация такого плана встречается очень много где и его наличие позволяет более-менее удобно шарить реализации многих функций для совершенно различных типов.
И в этом смысле он достаточно ключевой, т.к. компизация такого плана встречается очень много где и его наличие позволяет более-менее удобно шарить реализации многих функций для совершенно различных типов.
обычный ООПешный подход с интерфейсами для шаринга функций насколько хуже?
DS
обычный ООПешный подход с интерфейсами для шаринга функций насколько хуже?
В большинстве часто используемых ОО языков ты просто не сможешь выразить нужный тип интерфейса. Даже для функтора какого-нибудь
Т.е. тебе нужно что-то вроде такого:
Т.е. тебе нужно что-то вроде такого:
trait Functor[F[_]] {
def map(fa: F[A])(f: A => B): F[B]
}ИЧ
В большинстве часто используемых ОО языков ты просто не сможешь выразить нужный тип интерфейса. Даже для функтора какого-нибудь
Т.е. тебе нужно что-то вроде такого:
Т.е. тебе нужно что-то вроде такого:
trait Functor[F[_]] {
def map(fa: F[A])(f: A => B): F[B]
}я про языки без функторов, и шаринг функций делается через концепцию интерфейсов
интересен сам подход, если монады это про шаринг функций, то насколько они мощнее подхода с интерфейсами
интересен сам подход, если монады это про шаринг функций, то насколько они мощнее подхода с интерфейсами
p
я про языки без функторов, и шаринг функций делается через концепцию интерфейсов
интересен сам подход, если монады это про шаринг функций, то насколько они мощнее подхода с интерфейсами
интересен сам подход, если монады это про шаринг функций, то насколько они мощнее подхода с интерфейсами
ну тебе нужно будет писать раз в 10 больше кода
DS
я про языки без функторов, и шаринг функций делается через концепцию интерфейсов
интересен сам подход, если монады это про шаринг функций, то насколько они мощнее подхода с интерфейсами
интересен сам подход, если монады это про шаринг функций, то насколько они мощнее подхода с интерфейсами
Тут разные вещи.
Монады - сами по себе - это не средство для полиморфизма, это просто одна из выразимых каким-то средством для полиморфизма абстракций. (Вон в скале монады можно и на интерфейсах выразить некоторым образом, см. трейт выше)
Монады - сами по себе - это не средство для полиморфизма, это просто одна из выразимых каким-то средством для полиморфизма абстракций. (Вон в скале монады можно и на интерфейсах выразить некоторым образом, см. трейт выше)
ИЧ
Evgenii Moiseenko
Что из вышеперечисленного не нужно в системном языке? Option, Either или Future?
При условии что все реализованы эффективно.
Вместо Option/Either лучше error код ручками везде прокидывать как в Go?)
При условии что все реализованы эффективно.
Вместо Option/Either лучше error код ручками везде прокидывать как в Go?)
там и монады есть, но они почему-то запрещены сообществом