Implicit function arguments в Rust

Ээээ... А не проще просто в функцию передать? Ты по сути делаешь то же самое, но в пять раз длиннее.

Боже ж ты мой... ООП — это болезнь.

Если в App 100500 методов, то не проще.

То, что так можно сделать не означает, что так нужно делать.

Про ФП, вообще-то, можно сказать то же самое. Прятать Config за ReaderT, а потом пытаться стебаться с ООП... Ну, у каждого голова болит по своему.

Прятать Config за ReaderT, а потом пытаться стебаться с ООП...

Про ООП тут начали говорить сами фанаты ООП, они же начали предлагать свои странные костыли. Я не стебусь, я ужасаюсь этому б%#@&му цирку с конями, в котором вместо коней — хромой пони, а вместо дам — карлик-трансвестит.

Я, конечно, говнокодер, и с этим не спорю. Но я всё же не понимаю, чем плоха константная глобальная переменная с конфигурацией?

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

Но я всё же не понимаю, чем плоха константная глобальная переменная с конфигурацией?

Тем, что она должна инициализироваться в рантайме, а значит не может быть константной.

В крестах у неё может быть спецификатор const. extern const ... в заголовочном файле, подключать его во всех модулях, где нужна конфигурация.

Предполагаю, что в расте тоже можно подобное сделать.

Но мы ведь умнички и не делаем 100500 методов в классе, а делаем много разных объектов разного типа, каждому из которых теперь при инициализации нужно конфиг в щачло пихать.

Я не стебусь, я ужасаюсь этому б%#@&му цирку с конями, в котором вместо коней — хромой пони, а вместо дам — карлик-трансвестит.

В общем-то, тоже самое можно сказать и про пожелание из стартового сообщения темы. Тому, кто пишет на Haskell, этот маразм с ReaderT кажется классным решением, но для тех, кто на Haskell не пишет, это такой же цирк уродов.

По сути же темы, действительно интересно, можно ли в Rust-е получить нужный вам эффект каким-то другим способом. Ибо попытка притащить решение из ООП вряд ли будет лаконичной и удобной.

Но мы ведь умнички и не делаем 100500 методов в классе, а делаем много разных объектов разного типа, каждому из которых теперь при инициализации нужно конфиг в щачло пихать.

Ну так замечательно же богатство выбора:

• либо таскаем аргумент config через все методы;
• либо пихаем его в каждый конструктор, тогда методы будут иметь неявную ссылку на свой собственный экземпляр config-а;
• либо привязываемся к тому или иному варианту глобального стейта (в зависимости от ЯП это могут быть либо обычные глобальные переменные, либо статические члены класса, либо вариации на тему синглетонов).

В рамках ООП других вариантов не видно. Ну а в Rust-е и ООП нормального нет, так что там все как-то печальнее должно быть, на первый взгляд.

В крестах у неё может быть спецификатор const. extern const ... в заголовочном файле, подключать его во всех модулях, где нужна конфигурация.

В Rust нет заголовочных файлов. Ты сейчас предлагаешь грязный хак, я правильно понимаю?

В общем-то, тоже самое можно сказать и про пожелание из стартового сообщения темы. Тому, кто пишет на Haskell, этот маразм с ReaderT кажется классным решением, но для тех, кто на Haskell не пишет, это такой же цирк уродов.

Ты сейчас утверждаешь, что передача конфига аргументом в функцию — цирк уродов? Чувак, иногда лучше жевать чем говорить.

По сути же темы, действительно интересно, можно ли в Rust-е получить нужный вам эффект каким-то другим способом. Ибо попытка притащить решение из ООП вряд ли будет лаконичной и удобной.

Ну, do-нотацию в Rust уже закостылили макросами, но т.к. поддержки HKT нет и пока не предвидится, монад в духе Reader нам не видать. Можно попробовать накидать thread-safe хранилище String -> Any, и на месте делать тайпкаст, но это тоже ублюдочный костыль.

Вообще, в Rust много подобных проблем: подходы, которые считаются каноничными в других языках, в Rust не работают по каким-либо причинам, и приходится страдать. Например, в Rust нет человеческого Poll (mio::Poll работает не со всеми типами сокетов/файлов), и предлагается создавать по треду на fd со всеми вытекающими.

Ты сейчас утверждаешь, что передача конфига аргументом в функцию — цирк уродов? Чувак, иногда лучше жевать чем говорить.

Как-то у меня сложилось ощущение, что это не совсем простое протаскивание:

Это монадический трансформер. Если проще, это такая штука, добавляющая к каждой функции, которая с ней объявлена, лишний невидимый за счёт каррирования аргумент, доступ к которому можно получить через специальный метод.

Поскольку с Haskell-ом я сильно на «Вы», то не могли бы вы уточнить, этот самый аргумент Config в сигнатурах ваших функций будет присутствовать явно или все-таки его там не будет?

Никак, только руками передавать.

Как-то у меня сложилось ощущение, что это не совсем простое протаскивание:

Это совсем простое протаскивание, которое скрыто каррированием и небольшой магией.

Поскольку с Haskell-ом я сильно на «Вы», то не могли бы вы уточнить, этот самый аргумент Config в сигнатурах ваших функций будет присутствовать явно или все-таки его там не будет?

В сигнатурах будет. В списке аргументов — нет. Например:

data MyConfig = MyConfig { getNumber :: Int }

f :: Int -> Reader MyConfig Int
f i = do
    num <- asks getNumber
    return (i + num)

Тут главное удобство в том, что этот самый MyConfig будет неявно передаваться вниз по всему стеку вызовов. Ну и да, сигнатуры в Haskell писать не обязательно, и всё будет работать без них.

Но я всё же не понимаю, чем плоха константная глобальная переменная с конфигурацией?

Потому, что глобальная переменная не аналог ReaderT. Ты можешь прокидывать с помощью ReaderT в функцию каждый раз разное значение (конфиг), сколько угодно раз.

Изначально странная идея каргокультить в Rust костыли из Haskell, придуманные для эмуляции императивщины в чистом языке. Рекомендованное решение - прокидывать иммутабельную ссылку на конфиг аргументом до первого стракта, там сохранять ссылку в поле и дальше использовать через self. Если очень лень, или если нужно иногда менять конфиг, можно сделать статический Mutex<T>. Собственно все, как в обычных императивных языках от С до Java, каким образом сюда умудрились приплести ООП и его отсутствие, я не понял.

предлагается создавать по треду на fd со всеми вытекающими.

Предлагается использовать Tokio, так-то.

Кстати, раз уж мы про C++ тут вспомнили, годный аналог будет выглядеть примерно так:

#include <iostream>

class Config { 
  public:
    Config() : addOrMultiply(true) { } 
    bool addOrMultiply;
};

static Config _conf;

Config& get_conf(void) { return _conf; }

int my_function(int a, int b, const Config& config = get_conf())
{
    if(config.addOrMultiply)
        return a + b;
    else
        return a * b;
}

int main(void)
{
    std::cout << my_function(2, 3) << std::endl;
    return 0;
}

Изначально странная идея каргокультить в Rust костыли из Haskell, придуманные для эмуляции императивщины в чистом языке.

Нет, для эмуляции императивщины в хацкелле есть другие штуки, а Reader — всего лишь эксплуатация того факта, что функции тоже являются монадами.

Рекомендованное решение - прокидывать иммутабельную ссылку на конфиг аргументом до первого стракта, там сохранять ссылку в поле и дальше использовать через self.

Я надеюсь, ты осознаёшь, что не все функции нужно совать в impl {}, и делать это только ради конфига — далеко не самая лучшая идея.

Если очень лень, или если нужно иногда менять конфиг, можно сделать статический Mutex<T>.

А если я хочу добавить тестирование с мокингом этого самого конфига?

Ты сейчас предлагаешь грязный хак, я правильно понимаю?

Я пробовал понять, как это можно сделать в расте. Но нихрена не понял.

Я так понял, что в расте даже глобальный хэшмап не объявить просто так. Для этого предлагают макрос lazystatic. Всё остальное я не осилил. М.б. кто-нибудь разбирающийся в расте расскажет, возможно ли там иметь static const и mut ссылку на него в main().

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

Ну а в Rust-е и ООП нормального нет, так что там все как-то печальнее должно быть, на первый взгляд.

Будет почти тоже самое: трейт + static.

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

Ну вот поэтому рекомендованная практика - прокидывать конфиг явным аргументом

Ты когда-нибудь слышал про принцип don't repeat yourself?

Все как обычных императивных языках.

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

Даже так как в С++ не выходит. После бурного, но непродолжительного секса с растовскими макросами у меня получилось вот это:

fn get_state() -> String {
    return "default state".to_string();
}

fn test(a: i32, state: String) {
    println!("{} {}", state, a);
}

macro_rules! call {
    ($name:ident, $($a: expr),* ) => { $name( $($a)*, get_state()) };
}

fn main() {
    let local_state = "local state".to_string();
    test(12, local_state);
    call!(test, 9);
}

local state 12
default state 9

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

Каноничные - это типа хаскеля? Большинство проблем раста упирается в no-GC и zero-cost abstractions.

Например, в Rust нет человеческого Poll

Казалось бы, при чём тут язык.

Ну т.е. тебе ответ-то и не нужен, ты тред создал чтобы пофанбойствовать. В следующий раз теги «вброс» и «срач» не забудь поставить.

Каноничные - это типа хаскеля?

Каноничные — это языки, фишки которых Rust заимствовал и которые Rust так или иначе должен заменить. У меня возникает ощущение, что разработчики Rust на начальных этапах не очень хорошо понимали, что они хотят или не хотят включать в язык, и в результате мы имеем то что имеем.

Большинство проблем раста упирается в no-GC и zero-cost abstractions.

Отсутствие implicit arguments — это какой из этих вариантов?

Казалось бы, при чём тут язык.

Стандартная библиотека — часть языка. Удивительное рядом.

Ну т.е. тебе ответ-то и не нужен

Что удивительно, это один из тех тредов, где меня действительно интересовал ответ, пока мне не начали про ООП рассказывать.

Потому, что глобальная переменная не аналог ReaderT. Ты можешь прокидывать с помощью ReaderT в функцию каждый раз разное значение (конфиг), сколько угодно раз.

Т.е. проблема в отсутствии в расте аргументов по умолчанию?

Каноничные — это языки, фишки которых Rust заимствовал и которые Rust так или иначе должен заменить.

Он заимствует всё, что быстро работает. Тот же хаскель в плане производительность даже рядом с rust не стоял.

Отсутствие implicit arguments — это какой из этих вариантов?

Ни один. «Большинство» != всё. Ваш КО.

Стандартная библиотека — часть языка.

И в каких системных языках есть poll в std?

Нет.

Ясно.

Тот же хаскель в плане производительность даже рядом с rust не стоял.

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=...

Разница меньше порядка, во многих случаях меньше двух раз, что довольно таки близко. И это на синтетических задачах. В реальности у Haskell может быть преимущество за счёт развитого рантайма и GC, но тут всё целиком зависит от задачи.

Разница меньше порядка

Ну все, растокапец.

Аргумент функции можно спрятать препроцессором, чтобы не ошибиться лишний раз.

Похоже, я вас изначально неправильно понял. Вероятно, в такой постановке задачи для C++ я бы вообще никакого ООП не притягивал за уши. А делали бы какие-то финты ушами с помощью лямбд и вариадик-шаблонов.

Нет, аргументы по умолчанию тут не при чём. Проблема в отсутствии в Rust HKT и сахара для монад.

В половине тестов - да, а во второй половине отставание в 4-8 раз с космическим потреблением памяти.

Он заимствует всё, что быстро работает. Тот же хаскель в плане производительность даже рядом с rust не стоял.

Но-но! Хаскель по скорости находится на уровне .NET и Java

А потом ты из нескольких потоков поменяешь/почитаешь Config и всё, приехали.

Если следовать семантике ReaderT, то Config иммутабельный.

($name:ident, $($a: expr),* )

Я использовал спецификатор «tt» вместо «ident» и «expr», с ними не получилось.
call!(test, 9) немногим лучше test(9, get_state())

А откуда возьмётся значение?

Проблема в отсутствии в Rust HKT и сахара для монад.

А в данном случае они что дают-то? Что можно один раз подставить для функции конфиг, вызывать много раз, потом подставить другой конфиг, и опять вызывать много раз не передавая конфиг аргументом? Или я во что-то совсем не въезжаю?

А потом ты из нескольких потоков поменяешь/почитаешь Config и всё, приехали.

const там для кого стоит?

Проблема в отсутствии в Rust HKT и сахара для монад.

Конкретно тут HKT мало что дадут. Вот автоматическое каррирование — да.

Хех

trait Chain<V> {
    fn go(self, f: Box<Fn(Self)->V>) -> V;
}

impl<U, V> Chain<V> for U {
    fn go(self, f: Box<Fn(U)->V>) -> V {
        (*f)(self)
    }
}

fn lift_r<S, U: 'static, V: 'static>(f: Box<Fn(U)->V>) -> Box<Fn((U,S))->(V,S)>
{
    Box::new(move |(u, s)| ((*f)(u), s) )
}

fn mul2(v: i32) -> i32 {
    v*2
}

fn add_state(s: (i32, i32)) -> (i32, i32) {
    (*lift_r(Box::new(move |v| v + s.1)))(s)
}

fn bx<U: 'static, V: 'static>(f: fn(U)->V) -> Box<Fn(U)->V> {
    Box::new(move |u|f(u))
}

fn main() {
    let result = (2,3).go(lift_r(bx(mul2))).go(bx(add_state));
    println!("{:?}", result);
}

При инициализации.

Что можно один раз подставить для функции конфиг, вызывать много раз, потом подставить другой конфиг, и опять вызывать много раз не передавая конфиг аргументом?

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

static mut _config: i32 = 0;

fn setconfig(n: i32) {
    unsafe {
        _config = n;
    }
}

fn config() -> i32 {
    unsafe {
        _config
    }
}

Всё просто, понятно и очевидно. Настоящий Zero-cost.