LINUX.ORG.RU

Акторы и рекурсия.


1

1

Думал тут на досгуе о сабже, особенно о понимании тезиса о том, что любая система вычислений - есть частный случай модели акторов. Решил подойти именно с этого бока, поскольку поняв, почему рекурсия - это частный случай модели акторов, есть шанс приблизитья к пониманию того, например, почему LC - есть частный случай модели акторов.

Подход, немного сумасшедший, а может и не немного, но тем не менее.

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

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

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

Перемещено mono из talks

Я бесконечно далёк от этих ваших акторов, но мне показалось, что с помощью подобных алгоритмов можно намного более успешно программировать с помощью Finite State Machine. Я ошибаюсь?

Sadler ★★★
()

А вы там, когда не рассуждаете об акторах, монадах и лямбдах, код пишете?
Ну хоть чуть-чуть, а?

P.S. Сначала хотел добавить что-то обидное вроде «Теоретики хреновы», но потом подумал, что теория тоже нужна.
Было бы здорово если бы вы свои измышления проверяли на практике, но иногда и так сойдёт...

Stahl ★★☆
()

Ты всё-таки добрался до SICP?

31 Довольно долго считалось, что хвостовая рекурсия — особый трюк в оптимизирующих компиляторах. Ясное семантическое основание хвостовой рекурсии было найдено Карлом Хьюиттом (Hewitt 1977), который выразил ее в терминах модели вычислений с помощью «передачи сообщений»

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

Врядле оно добралось до SICP, лучше же на ЛОРе срать.

grouzen ★★
()
Ответ на: комментарий от Sadler

Я пока только вникаю, если честно, экспертное мнение высказать не могу, но мне кажется, чисто субъективно, что нет. У меня стойкое ощущение складывается (нубскоке, да), что акторы - это правильный взгляд на вещи, а Finite State Machine - лишь частный случай модели акторов. Но это - всего лишь нубское мнение человека, который бегло прошелся по верхам. Nevermind:)

anonimous
() автор топика
Ответ на: комментарий от Stahl

Да я не поклонник теорий, но как-то учиться надо, вот и заносит. А книжки, вроде «Освой Java за 2 недели», особо тоже не вдохновляют. А код я пишу исключительно for fun:)

anonimous
() автор топика
Ответ на: комментарий от korvin_

Вообще, я читал SICP, но дошел только до банковских счетов, ЕМНИП, 4 главы. То, что я написал, сформировалось из беглого просмотра англоязычных сайтов. Я просто нашел, за что зацепиться, и додумал сам. Кстати, на русском на эту тему почему-то вообще очень мало инфы.

Но за наводку спасибо большое, я и не знал, что в SICP эта тема обсуждается.

anonimous
() автор топика
Ответ на: комментарий от Sadler

можно намного более успешно программировать с помощью Finite State Machine

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

anonimous
() автор топика
Ответ на: комментарий от anonymous

Я всегда с подозрением отношусь к людям, которые употребляют фразы вроде, «dinosaur era technology», все мы знаем, что такое эти ваши нано-эры — скатывание в энтерпрайз говно.

anonimous
() автор топика
Ответ на: комментарий от anonymous

мировые эксперты

И, btw, я запарился читать, и в упор не увидел где там «мировые эксперты»?

anonimous
() автор топика

Угадал автора по заголовку

buddhist ★★★★★
()
Ответ на: комментарий от anonimous

Даглас Крокфорд - дебил, соответственно, он мог выражать что угодно. Монады не имеют смысла (другими словами, от наличия монад в языке нет никакого выигрыша для программиста), если нельзя писать код, параметризованный в конструкторе типа. А для этого нужно система типов с HKT

anonymous
()
Ответ на: комментарий от anonymous

Не о том речь, это было ответом на это:

где система типов вообще позволяет их выразить

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

anonimous
() автор топика
Ответ на: комментарий от anonimous

Ты не понял.

Чтобы выразить абстрактный (полиморфный) концепт монады - эндофунктор с двумя натуральными преобразованиями - нужна система типов с HKT

Частные случаи можно выразить хоть на бейсике, хоть на лиспе

anonymous
()
Ответ на: комментарий от anonimous

Д

Основная идея монад в том, что писать код один раз. Например, в Хаскелле ты можешь написать

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

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

anonymous
()
Ответ на: комментарий от anonimous

Вообще, я читал SICP, но дошел только до банковских счетов, ЕМНИП, 4 главы. То, что я написал, сформировалось из беглого просмотра англоязычных сайтов. Я просто нашел, за что зацепиться, и додумал сам. Кстати, на русском на эту тему почему-то вообще очень мало инфы.

блжад, всё это уже было в SICP. Читай дальше.

emulek
()
Ответ на: комментарий от AIv

ssize_t read(int fd, void *buf, size_t buf_size).

грубо ssize_t и есть монада.

nanoolinux ★★★★
()
Ответ на: Д от anonymous
Основная идея монад в том, что писать код один раз. Например, в Хаскелле ты можешь написать

mapM :: Monad m => (a -> m b) -> [a] -> m [b]

один раз и использовать этот mapM для любой имплементации класса Monad

а как это в C++?

emulek
()
Ответ на: комментарий от AIv

в '\n': последовательность действий с передачей результата первой второй - это монада. Другое дело, что в хацкеле можно обобщить и установить правило передачи :)

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Фигасе... оказывается я сплошь и рядом тоже юзаю монады!

А зачем тогда разводить вокруг этого такой туманище?

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

«There are so many things in computer science and programming that are far harder to understand than monads. Reading code written with dynamically typed languages, implementing balanced trees, debugging numerical methods that are subtly unstable, finding memory leaks in someone else's code, reasoning about concurrent code, and so on. Some of these things never ever become easy no matter how much time you spend on them. Monads are just a one time bump with a nice payoff when you're over.» Dan Piponi.

qnikst ★★★★★
()
Ответ на: комментарий от emulek

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

qnikst ★★★★★
()
Ответ на: комментарий от emulek

применяет функцию, принимающую значение типа 'a' и возращающая значение типа 'b' в монадическом контексте, к списку значений типа a, и получает список типа b в монадическом контексте. Что конкретно это делает зависит от монадического контекста.

примеры:

1. Reader применение функции:

> let f = mapM (+) [1,2,3] -- создает штуку, которая в применении к числу выдаст список результатов:
λ> f 5
[6,7,8]

2. Maybe - значение которое может иметь или не иметь результата.

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

λ> let f = mapM (\x -> if x > 5 then Nothing else Just x)
λ> f [1,2,3]
Just [1,2,3]
λ> f [1,2,6]
Nothing

3. List - много вариантов значения, соотв при применении к списку будут перебраны все варианты

λ> let f = mapM (\x -> [x,x-1,x+1])
λ> f [3]
[[3],[2],[4]]
λ> f [0,10]
[[0,10],[0,9],[0,11],[-1,10],[-1,9],[-1,11],[1,10],[1,9],[1,11]]

а есть ещё много забавных и интересных и применимых вариантов :)

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Другое дело, что в хацкеле можно обобщить и установить правило передачи

А где это нельзя? По-моему, для этого достаточно лексической области видимости, не?

anonymous
()
Ответ на: комментарий от anonymous

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

  m b ; g ,  m b = Nothing
 -------------------------   M-Nothing
         Nothing


  m b ; g , m b \in Just
 -------------------------   M-Just
         g b

и пишем как это будет выглядеть в другом языке..

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

изоморфов

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

vonenij
()
Ответ на: комментарий от AIv

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

А зачем тогда разводить вокруг этого такой туманище?

Да ну нафиг, никому они не вперлись в программировании. Тот же Clean спокойно без них обходится

vonenij
()
Ответ на: комментарий от anonymous

Выше же обьяснял, пусть у нас есть указатель, который указывает на null или данные. Хочется написать следующий код:

a * v = f();
if (v) {
   return g(*v);
} else return null;

Уровней вложений if может быть много. Т.е. семантика следующая, если у нас функция вернула null, то и все вычисление возвращает null, иначе возвращается результат.

qnikst ★★★★★
()
Ответ на: комментарий от vonenij

Тот же Clean спокойно без них обходится

я бы не сказал, что uniqueness typing - это «свободно». это, в общем-то, куда жёстче, чем в Haskell

jtootf ★★★★★
()
Ответ на: комментарий от qnikst

Короче хуйня которая работает как && в норм языках, но еще и значение пробрасывать позволяет.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.