Реактивное програмирование

карринг
ФВП тут боком вообще

каррированная функция не фвп?

Не всякая ФВП функция обязанна быть каррированной. Строго говоря, ФВП, чтобы быть таковой, достаточно быть first-class

Мне надоело твое манипулирование терминами.

поэтому ФП (в понимании haskell-like) с декларативностью не связано

ФП (в понимании haskell-like)

Ты считаешь что ФП это - haskell и haskell-подобные языки.

А вот что такое ФПР, и как оно может быть вообще, существовать, вот это интересно, потому как ящетаю, что это в принципе невозможно.

Ты не понимаешь, как можно совместить ФП и РП.

Вот РП на haskell (это ведь haskell-подный язык, верно?): http://www.haskell.org/haskellwiki/Functional_Reactive_Programming

Не всякая ФВП функция обязанна быть каррированной

покажи пример такой функции не каррированной

манипулирование терминами.

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

Вот РП на haskell

Ты предлагаешь мне изучить заскель, птом перелопатить эту реализацию, чтобы убедиться в очевидном — ничего кроме сахара от РП там нет? Я и так догадываюсь, спасибо.

Ты о чем то о своем. Еще раз. ФВП - это фест-класс ф-ция, ничего более.

А вот что такое ФПР, и как оно может быть вообще, существовать, вот это интересно, потому как ящетаю, что это в принципе невозможно.

потому как ящетаю, что это в принципе невозможно.

Возможно. Я указал на реализации которые удовлетворяют твоим требованиям.

Че то запарился я с Вашим примером. Я не догнал сразу, что тут кто-то должен вносить изменения вручную, сами то данные не установяться, глупо было бы. Отсутствие ошибок не гарантирую, но смысл, думаю такой.

data={}

set_number=function(n){data.number=n; upgrade(); show()}
set_price=function(n){data.price=n; upgrade(); show()}
set_sum=function(n){data.sum=n; upgrade(); show()}

show=function(){
   if(!(data.price&&data.number&&data.sum))return;
   console.log("number: "+data.number); console.log("price: "+data.price); console.log("sum: "+data.sum)
}

upgrade=function(){
   if(data.sum&&data.price)data.number=data.sum/data.price
   if(data.sum&&data.number)data.price=data.sum/data.number
   if(data.price&&data.number)data.sum=data.price*data.number
}

set_number(2)
set_price(10)

console.log("\n")

set_sum(30)

console.log("\n")

set_price(20)

--------------\  
number: 2
price: 10
sum: 20


number: 3
price: 10
sum: 30


number: 1.5
price: 20
sum: 30

Даже set_number set_price set_sum можно переименовать в просто number price и sum для наглядности.

Вашим

Слушай, мы уже кусались, можно и на ты.

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

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

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

Как это ложится на «фп», я хз, это лишь баззворд без конкретных деталей активной схемы.

Именно так. Как конкретно ты будешь реализовывать реакции на событийный поток — псевдоимперативно или псевдофункционально — неважно. И тот и другой мир одинаков по возможностям вычислений, только подходы разные; в фп-подходе одно упрощается, а в императивном другое. Мыслить черно-белым просто глупо и по-адептски, и то и другое симулирует модель в конечном счете, неважно как именно.

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

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

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

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

на самом деле, в любом императивном ЯП

Бредня, такой язык только один - машинное представление и язык который максимально его представляет в «языковых» конструкциях и возможностях - си.

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

Поэтому ты написал правильно - реактивное «программирование» - это в примитивном случае твои функции(указатели). Но жопа там не в этом.

Устройство там примитивное:

a = 2;//хранит метаинфу зависимостей
b = 3;//хранит метаинфу зависимостей
f(a, b);//тут мы записываем в метаинфу перменной а и б то, что он них зависит функция f().
a = 3;//тут просто апдейтятся все зависимости записанные в переменную а.

В примитиве на сишке:

void f(int a, int b) { fprintf(stderr, "%d, %d\n", a, b);}

typedef struct {
  typeof(f) * fun;
  int * arg_a, * arg_b;
} fun_dump_t;

fun_dump_t dump_fun(typeof(f) fun, int * arg1, int * arg2) {
  return (fun_dump_t){fun, arg1, arg2};
}

typedef struct {
  int value;//у меня инты, у вас там просто var, ибо типов нет
  int dep;
  fun_dump_t dump;//тут конечно надо сделать список функций, но мне лень
} var_t;

var_t init_value(int value) {
  return (var_t){value, 0, (fun_dump_t){}};
}

void set_value(var_t * var, int value) {
  var->value = value;
  if(var->dep)
    var->dump.fun(*(var->dump.arg_a), *(var->dump.arg_b));//тут тоже вызов этого списка.
}

void set_dep(var_t * var, fun_dump_t fun) {
  *var = (var_t){var->value, 1, fun};
}


int main(void) {
  var_t a = init_value(5);
  var_t b = init_value(3);
  set_dep(&a, dump_fun(f, &a.value, &b.value));//добавляем функцию f() в метаинфу переменно b.

  set_value(&a, 1);
  set_value(&b, 2);
  set_dep(&b, dump_fun(f, &b.value, &b.value));//добавляем функцию f() в метаинфу переменно a.
  set_value(&a, 3);
  set_value(&b, 4);
}

1, 3
3, 2
4, 4

Так это реализовано, а примитивные случаи, которые ты описал - это указатели, которые итак есть в си.

Парадигмы не перестают существовать от того, что ты реализуешь их на Си. Если бы парадигм не было, тебе нечего было бы реализовывать. Такие дела.

Лучше уж так (хотя тоже говно):

function variable(val) {
  var observers = [];
  var value = val;

  return {
    get value() {
      return value;
    },

    set value(val) {
      value = val;
      observers.forEach(function (observer) {
        observer.propagate();
      });
    },

    subscribe: function (observer) {
      observers.push(observer);
    }
  };
}

function assign() {
  var expr = arguments[0];
  var args = Array.prototype.slice.call(arguments, 1);
  var observers = [];
  var value;

  var ret = {
    get value() {
      return value;
    },

    propagate: function () {
      value = expr.apply(null, args.map(function (arg) {
        return arg.value;
      }));

      observers.forEach(function (observer) {
        observer.propagate();
      });

      return value;
    },

    subscribe: function (observer) {
      observers.push(observer);
    }
  };

  args.forEach(function (arg) {
    arg.subscribe(ret);
  });

  value = expr.apply(null, args.map(function (arg) {
    return arg.value;
  }));

  return ret;
}

function observe(thing, handler) {
  var ret = {
    propagate: function () {
      return handler.call(null, thing.value);
    }
  };

  handler.call(null, thing.value);

  thing.subscribe(ret);

  return ret;
}

function example() {
  var x = variable(5);
  observe(x, function (value) {
    console.log('x is set to', value);
  });

  var y = variable(7);
  observe(y, function (value) {
    console.log('y is set to', value);
  });

  var z = assign(function (x, y) {
    return x + y;
  }, x, y);
  observe(z, function (value) {
    console.log('"(x + y)" evaluates to', value);
  });

  var w = assign(function (x, z) {
    return x * z;
  }, x, z);
  observe(w, function (value) {
    console.log('"x * (x + y)" evaluates to', value);
  });

  console.log('');

  console.log('=================================');
  console.log('Manually setting x to', 3);
  x.value = 3;
  console.log('');

  console.log('=================================');
  console.log('Manually setting y to', 10);
  y.value = 10;
  console.log('');
}

Ты запаришься вручную обновлять все «переменные», если у тебя их будет больше десятка.

Охохо, вот теперь я вижу что ты вообще не шаришь. Ты мыслишь в каких древних парадигмах. Сейчас они лишь кирпичик для реализации разных разновидностей параллельных программ. И функциональные кирпичики местами подходят куда лучше. А вообще реактивное программирование похоже на Go. Я бы даже сказал что эта идея лежит в основе основ этого языка.

А вообще реактивное программирование похоже на Go. Я бы даже сказал что эта идея лежит в основе основ этого языка.

Не можешь развернуть мысль?

Пока сам разбираюсь. Но постараюсь объяснить. Есть горутины и есть каналы. Горутины автоматом берут из каналов данные, обрабатывают и кладут если надо в следующие каналы. Грубо при поступлении каких то данных в каналы они автоматом идут дальше.

Горутина1 -> канал1 -> горутина2 -> канал2 -> ... -> горутинаN -> каналN.

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

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

В целом идея его мне нравится. А вот синтаксис не очень. Хотя вот в том же эрланге мне нехватало структур, а тут из коробки.

Глянь в сторону elixir.

Да Go тупо быстрее, да и вообще сочетает кучу нужных фич. Типизация, структуры данных, горутины, интересный вариант ооп с учетом более 30 лет выстрелов себе в ногу ранних вариантов. И компиляция конечно же. А еще он будет нативно поддерживаться андроидом. Эрланг норм только не тянет на язык общего назначения. А вот Go вполне может потеснить даже джаву.

каналы говно т.к. могут забиваться

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

Да, и кстати, эта парадигма нам как-бы, в очередной раз, намекает, что никакой разницы между функциями и данными нет, BTW.

В компутере всё состоит из 0 и 1. Всё что выше это синтаксический сахар.

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

Ты меня натолкнул на мысль что надо посоветовать анонимусу пристально поизучать машину тьюринга, её вариации, ну и близкие темы. Конечные автоматы по-моему.