Что делать с жунами , Что делать с жунами

[OpenGL]

Цитата applegame @ 26.04.21, 15:29

В Rust есть полноценная иммутабельность

В расте нет, там в этом плане всё точно так же.

[korvin]

Цитата applegame @ 26.04.21, 15:29

Честно говоря лень уже дальше разбираться. Мое знание Хаскеля достаточно базовое и довольно тяжело копаться даже в несложных кусках.
Погуглив по словам "haskell do imperative" обнаружил кучу упоминаний о том, что на хаскеле можно (но не нужно) писать имеративно, применяя монады, что do-нотация является псевдоимперативной или imperative style и так далее.

Отлично, "не читал, но мнение имею", "слышал звон, но не знаю где он". Как-то так.

Цитата applegame @ 26.04.21, 15:29

За счет побочных эффектов, очевидно.

А если б не было побочных эффектов?

Цитата applegame @ 26.04.21, 15:29

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

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

foo x = x + 1
bar x = x * 2
 
gee = foo . bar
qux = bar . foo

gee и qux --- это одинаковые функции или разные?

Впрочем, давай рассмотрим твой кусок:

a = foo(x)
bar(a)

заменим a на сам вызов:

bar(foo(x))

программа из императивной сразу стала функциональной?

Добавлено 26.04.21, 15:58

Цитата applegame @ 26.04.21, 15:29

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще.

Про никто довольно смелое заявление. И даже если действительно не существует ни одного человека/проекта, использующего такую возможность, это не означает отсутствие самой возможности.

Сообщение отредактировано: korvin - 26.04.21, 15:58

[D_KEY]

Цитата applegame @ 26.04.21, 15:29

Цитата korvin @ 26.04.21, 10:40

А за счёт чего наблюдаемый результат может измениться?

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

Так ты же выше отказался от общепринятого определения ИП, убрав оттуда изменение состояния. Откуда тогда побочные эффекты? До сих пор не понимаю, чем тебе не нравится "обычное" определение ИП.

Добавлено 26.04.21, 16:10

Цитата applegame @ 26.04.21, 15:29

Я писал много и на Си и на C++. Никто на парится иммутабельностью вообще.

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

За const парятся в обязательном порядке.

По поводу иммутабельности в узком смысле обычно задумываются в контексте структур данных и многопоточности. Зачастую что-то используют.

Да даже на системном уровне попадается что-то в духе RCU, например

Сообщение отредактировано: D_KEY - 26.04.21, 16:10

[korvin]

Цитата applegame @ 26.04.21, 15:29

Честно говоря лень уже дальше разбираться. Мое знание Хаскеля достаточно базовое и довольно тяжело копаться даже в несложных кусках.
Погуглив по словам "haskell do imperative" обнаружил кучу упоминаний о том, что на хаскеле можно (но не нужно) писать имеративно, применяя монады, что do-нотация является псевдоимперативной или imperative style и так далее.

А ещё есть шутка, что Хаскелл --- это лучший императивный язык.

https://wiki.haskell.org/Do_notation_considered_harmful

Цитата

Criticism
Haskell's do notation is popular and ubiquitous. However we shall not ignore that there are several problems. Here we like to shed some light on aspects you may not have thought about, so far.

Didactics
The do notation hides functional details. This is wanted in order to simplify writing imperative style code fragments. The downsides are that:

- Since do notation is used almost everywhere IO takes place, newcomers quickly believe that the do notation is necessary for doing IO,
- Newcomers might think that IO is somehow special and non-functional, in contrast to the advertisement for Haskell being purely functional,
- Newcomers might think that the order of statements determines the order of execution.

Обрати внимание на последний пункт. Да и остальные.

Ну и там далее в статье примеры "misunderstanding"

Сообщение отредактировано: korvin - 26.04.21, 16:17

[OpenGL]

А всё-таки, какое имеет отношение opaque struct к иммутабельности?

[applegame]

Цитата OpenGL @ 26.04.21, 15:40

В расте нет, там в этом плане всё точно так же.

Да ладно? Раст позволяет такие вот фокусы?
https://glot.io/snippets/fy2i5lgz8g

import std.stdio;
struct Foo {
    int a;
    this(int x) { a = x; }
}
 
struct Bar {
    Foo* foo;
    this(Foo* f) { foo = f; }
    void print() const {
        writeln(foo.a);
    }
}
 
void main() {
    auto foo = new Foo(10);
    const bar = const Bar(foo);
    bar.print();
    //bar.foo.a = 11; // ошибка компиляции, bar иммутабелен?
    foo.a = 11;       // опаньки, bar мутировал, компилятор не возражает
    bar.print();
}

[OpenGL]

Именно в таком виде нет, т.к. если бы было можно, то легко было бы нарушить правило BC "на объект есть только одна mut ссылка". Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

use std::cell::Cell;
 
struct Foo
{
    field: Cell<i32>,
}
 
impl Foo
{
    fn new() -> Self
    {
        Foo{field: Cell::new(42)}
    }
}
 
fn main() {
    // Иммутабельный объект
    let f = Foo::new();
    println!("{:?}", f.field.get());
    f.field.set(-42);
    // Упс, он поменялся
    println!("{:?}", f.field.get());
}

Вывод:

42
-42

Сообщение отредактировано: OpenGL - 27.04.21, 09:16

[applegame]

Цитата korvin @ 26.04.21, 15:52

Отлично, "не читал, но мнение имею", "слышал звон, но не знаю где он". Как-то так.

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

Цитата korvin @ 26.04.21, 16:11

А ещё есть шутка, что Хаскелл --- это лучший императивный язык.
https://wiki.haskell.org/Do_notation_considered_harmful

Я читал эту статью. Первый раз лет пять назад, когда изучал Хаскель, второй раз позавчера
То что там написано не опровергает того что пишу я. Результат выполнения инструкций в do-нотации будет таким же как если бы они выполнялись последовательно, вне зависимости от того чистые там функции или грязные. Согласен? В точности как в ИП. Статья большая, а ты выбрал одну фразу и выдрал ее из контекста. Молодец, чо.
В шутке про лучший императивный язык, как обычно только доля шутки. На Хаскеле можно извратиться и писать императивно, я видел даже эквивалент обычных циклов, сделанный на монадах. Правда Хаскель скорее все же худший императивный язык

Цитата korvin @ 26.04.21, 15:52

А если б не было побочных эффектов?

Без побочных результат не изменится. Но в ИП мы не знаем есть ли там побочные эффекты или нет. Компилятор может знать, а может и не знать об этих эффектах.
Поэтому в ИП последовательность инструкций важна, а в ФП нет. Нужели ты оспариваешь даже этот тезис? Он жн полностью согласуется как с моим определением, так и с общепринятым. Повторю вопрос, у тебя какое-то свое определение?

Цитата korvin @ 26.04.21, 15:52

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

Я ответил на этот вопрос, ты правда никак не отреагировал.

Цитата korvin @ 26.04.21, 15:52

Впрочем, давай рассмотрим твой кусок:

И ты мне предлагаешь проверить память после этого. Обсуждали же уже этот кусок и этот вопрос. Смотри конец поста: Что делать с жунами (сообщение #3846765)

Цитата D_KEY @ 26.04.21, 16:02

Так ты же выше отказался от общепринятого определения ИП, убрав оттуда изменение состояния. Откуда тогда побочные эффекты? До сих пор не понимаю, чем тебе не нравится "обычное" определение ИП.

То что в моем определении нет необходимости в мутабельных переменных, не означает, что ИП не может иметь побочных эффектов. В общепринятом определении наличие последовательности инструкций - это необходимое, но недостаточное условие для ИП, а в моем это необходимое и достаточное условие.
Почему мне не нравится общепринятое определение, я тебе уже объяснял, но ты игнорируешь мои объяснения. Еще примеры:
Это императивщина?

int a = foo(x)
if(a == 0) return 1;
a = a + bar(a);
if(a == 1) return 2;
return 3;

Теперь добавим иммутабельности.

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

Теперь это функциональщина?
Опять начнешь растекаться мыслью по древу, что тут нельзя точно сказать, что это смесь разных парадигм и так далее?

Цитата D_KEY @ 26.04.21, 16:02

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

За const парятся в обязательном порядке.

Ты похоже один из тех, кто думает, что const в C/C++ - это и есть иммутабельность.
За const в мейнстриме начали парится с появлением его в C++ и C, то бишь в начале 90-х. С иммутабельностью мало кто парится и по сей день.
Что касается лично меня. Я начал париться за const с 1994-го когда мне в инстутуте объяснили зачем он нужен. На иммутабельность я обратил внимание когда начал писать на D (лет 7 назад), а окончательно уверовал в ее полезность, когда начал изучать ФП на примере Хаскеля (лет 5 назад).

Цитата D_KEY @ 26.04.21, 16:02

Да даже на системном уровне попадается что-то в духе RCU, например

RCU прямого отношения к иммутабельности не имеет. Имутабельность может форсировать RCU, но не наоборот.

Добавлено 27.04.21, 10:08

Цитата OpenGL @ 27.04.21, 09:14

Именно в таком виде нет, т.к. если бы было можно, то легко было бы нарушить правило BC "на объект есть только одна mut ссылка". Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

Мде. Похоже и правда полноценную иммутабельность можно сделать только в языках с GC.

[D_KEY]

Цитата applegame @ 27.04.21, 09:59

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

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

[D_KEY]

Цитата applegame @ 27.04.21, 09:59

Почему мне не нравится общепринятое определение, я тебе уже объяснял, но ты игнорируешь мои объяснения.

Ты не объясняешь, а приводишь странные примеры, в основном Как и ниже, собственно.

Цитата

Теперь это функциональщина?

Зависит от наличия побочных эффектов
Ты приводишь очень маленькие куски кода.

Цитата

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

Так если оно так и есть?

Цитата

Ты похоже один из тех, кто думает, что const в C/C++ - это и есть иммутабельность.

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

[applegame]

Цитата D_KEY @ 27.04.21, 15:36

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

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

Цитата D_KEY @ 27.04.21, 18:02

Ты не объясняешь, а приводишь странные примеры, в основном Как и ниже, собственно.

А в чем их странность? Подобный код встречается сплошь и рядом.

Цитата D_KEY @ 27.04.21, 18:02

Зависит от наличия побочных эффектов

Ха. Хорошо, пусть foo и bar - это чистые функции, этот код написан в ФП-парадигме?

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

Цитата D_KEY @ 27.04.21, 18:02

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

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

Цитата D_KEY @ 27.04.21, 18:02

Так если оно так и есть?

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

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

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

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

immutable a = foo(x)
if(a == 0) return 1;
immutable a1 = a + bar(a);
if(a1 == 1) return 2;
return 3;

даже если функции считать чистыми, все равно, в определенном смысле, имеет мутабельный стейт. Условно говоря - это контекст (в лице стека, например). В третьей строке в контексте появилась новая переменная a1 - считай мутировал стейт. Какая по сути разница: в коробке лежал синий кубик, мы вытащили его и положили вместо него красный кубик или лежал синий, а красный мы положили рядом? Один фиг содержимое коробки (стейт) изменилось.
В русской википедии в статье о ФП (не ИП, ) есть интересная цитата:

Цитата

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

Обрати внимание на выделенную часть. Это не то самое о чем я написал выше?
В таком смысле получается, что последовательность инструкций и мутабельный стейт являются следствиями друг друга. То есть достаточно включить одну из этих сущностей в определение и другая автоматически будет следовать из нее.

Сообщение отредактировано: applegame - 28.04.21, 08:27

[D_KEY]

Цитата applegame @ 28.04.21, 08:08

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

Если нет побочных эффектов, то последовательность действий фактически важна лишь с точки зрения корректности вычислений. А тут нет никаких отличий от ФП.

[applegame]

Цитата OpenGL @ 27.04.21, 09:14

Но тем не менее это не иммутабельность, т.к. ничто не мешает менять объект, на котором нет mut, посредством Cell:

По поводу Rust. А вот этот вот Cell - это же не конструкция языка, а элемент стандратной библиотеки. Он внутри unsafe? Я к тому, что не является ли этот Cell каким-то способом, так сказать обмануть компилятор?
Ну как скажем в D можно тоже при желании мутировать immutable переменные в unsafe коде через cast.

Добавлено 28.04.21, 09:43

Цитата D_KEY @ 28.04.21, 08:45

Если нет побочных эффектов, то последовательность действий фактически важна лишь с точки зрения корректности вычислений. А тут нет никаких отличий от ФП.

Есть: в чистом ФП само понятие последовательность вычислений не имеет сымсла. Ты остальное-то читал?

[D_KEY]

Цитата applegame @ 28.04.21, 09:40

Есть: в чистом ФП само понятие последовательность вычислений не имеет сымсла.

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

Добавлено 28.04.21, 11:24

Цитата applegame @ 28.04.21, 08:08

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

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

Добавлено 28.04.21, 11:27

Цитата applegame @ 28.04.21, 08:08

даже если функции считать чистыми, все равно, в определенном смысле, имеет мутабельный стейт. Условно говоря - это контекст (в лице стека, например). В третьей строке в контексте появилась новая переменная a1 - считай мутировал стейт. Какая по сути разница: в коробке лежал синий кубик, мы вытащили его и положили вместо него красный кубик или лежал синий, а красный мы положили рядом? Один фиг содержимое коробки (стейт) изменилось.

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

[korvin]

Цитата applegame @ 28.04.21, 08:08

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

И какая нам польза в этом знании?