перефразируй еще раз вопрос и подсказка: почтовые ящики процесса

А причем тут ООП?

перефразируй еще раз вопрос

А что именно неясно? А то мне тяжело понять, как лучше перефразировать.

Мне интересны особенности создания программ для гипотетической Erlang VM, которая бы работала в строгом соответствии с представлениями Hewitt'a.

почтовые ящики процесса

В смысле, «почтовые ящики процесса»? Насколько мне известно, у процесса ящик может быть только один.

А причем тут ООП?

In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole--like data structures, procedures, and functions which are the usual paraphernalia of programming languages--each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network. Questions of concrete representation can thus be postponed almost indefinitely because we are mainly concerned that the computers behave appropriately, and are interested in particular strategies only if the results are off or come back too slowly.

Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm--which I called object-oriented--for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modelling the ever more complex dynamic systems and user relationships made possible by the silicon explosion.

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

Paul Chiusano все объяснил про акторы

Да... Объяснил...

Though I don't know exactly what the replacement looks like yet. I do know what's wrong with actors

Дальше можно было бы не читать, но в комментариях автору вроде объяснили, какой он дурак.

перефразируй еще раз вопрос

А что именно неясно? А то мне тяжело понять, как лучше перефразировать.

Мне интересны особенности создания программ для гипотетической Erlang VM, которая бы работала в строгом соответствии с представлениями Hewitt'a.

почтовые ящики процесса

В смысле, «почтовые ящики процесса»? Насколько мне известно, у процесса ящик может быть только один.

Это опечатка, естественно у каждого процесса свой почтовый ящик. И заметь, эта концепция пронизывает концепцию акторов. Кстати в начале разговора там они тоже говорят process...mail boxes... )

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

p.s. также еще важно: нет никакой синхронизации фактически - все есть акторы, принимающие сообщения с некоторой буфферизацией благодаря mailbox. Это обеспечивает ассинхронность фактически, что дает дополнительную степень свободы процессам.

но изначально порядок тот, в котором пришли сообщения

...и он может несовпадать с тем, в котором ушли

но изначально порядок тот, в котором пришли сообщения

...и он может несовпадать с тем, в котором ушли

речь идет о порядке сообщений отправителя?

Смотря какая логика программы, не?

но изначально порядок тот, в котором пришли сообщения

...и он может несовпадать с тем, в котором ушли

между отправителем и получателем может произойти все что угодно, даже reverse order. Ответственность за порядок только на своей территории. Каждый отвечает за свой порядок.

однако есть исключение: для эрланга как правило сообщения идут конкретному получателю так-или иначе привязанному к pid - это означает что посередине исключено наличие посредника, если это явным образом не адресовано к нему. Типичная проблема при передаче сообщения: timeout, не соответствие матчинга, невалидный pid. Однако при этом сообщение может находится в почтовом ящике процесса если pid существует. Для чтения сообщения надо еще сделать receive или напрямую прочитать словарь процесса, что в общем порядке не рекомендуется. В общем случае для этих дел лучше использовать gen_server, gen_fsm...

If there is a live process and you send it message A and then message B, it's guaranteed that if message B arrived, message A arrived before it.

Вроде как это справедливо, если для них обоих матчинг есть. Если для какого-то нет матчинга, то он в мейлбоксе остаётся, пока матчинг не появиться (загрузка новой версии модуля например). В этом случае походу будет наоборот. Сначала В, а потом А. Но это емнип, я точно не уверен, что это так.

Что-то все так на эрланг накинулись. А говорили мёртвый.

Что-то все так на эрланг накинулись.

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

Я и не сомневался. Просто складывается мнение, что его популярность растёт. Интересно, это от того, что задач, где надо фичи ерланга, становится больше или всех достал буст со ствоим «замечательным» асио?

Если для какого-то нет матчинга, то он в мейлбоксе остаётся

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

Честно говоря, я немножко разочарован комментариями. Попробую уточнить вопрос. Вот полная цитата:

10.8 Is the order of message reception guaranteed?

Yes, but only within one process. If there is a live process and you send it message A and then message B, it's guaranteed that if message B arrived, message A arrived before it.

On the other hand, imagine processes P, Q and R. P sends message A to Q, and then message B to R. There is no guarantee that A arrives before B. (Distributed Erlang would have a pretty tough time if this was required!)

Что если существовала бы такая Erlang VM, которая не гарантировала бы даже того, что A попадет в мейлбокс раньше чем B, даже если они посланы одному процессу? Какой erlang-код смог бы заработать на такой VM?

Насколько я понял, Hewitt называет такое свойство «quasi-commutativity»:

Operations are said to be quasi-commutative to the extent that it doesn't matter in which order they occur. To the extent possible, quisi-commutativity is used to reduce indeterminacy.

Что-то все так на эрланг накинулись. А говорили мёртвый.

Ну так мертвых пинать безопаснее всего %)

Это похоже из серии: не запутывай себя и других. Конечно хорошо разобраться в деталях - главное не запутаться.

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

И правильно говорится в цитируемом тексте, что нет гарантии очередности (синхронности) доставки сообщений в сравнении между двумя процессами. Это асинхронность - ничто своевременного не гарантируется.

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

Не нравиться порядок следования сообщений

Мне нравится порядок следования сообщений в Erlang'е, но данный тред посвящен скорее модели акторов, в которой он другой.

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

Сначала спрашиваете про эрланг, но потом выясняется не совсем про эрланг...вам шашечки или ехать?

Сначала спрашиваете про эрланг, но потом выясняется не совсем про эрланг...вам шашечки или ехать?

Геометрия — не наука об измерении предметов, а computer science — не про изучение компьютеров.

Сначала спрашиваете про эрланг, но потом выясняется не совсем про эрланг...вам шашечки или ехать?

Геометрия — не наука об измерении предметов, а computer science — не про изучение компьютеров.

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

Какой erlang-код смог бы заработать на такой VM?

Тебе что - препод лабу не пимет если ты не ответишь на такой вопрос?

receive
  a -> 
    receive 
      b -> ok
    end
end  

очевидно что порядок важен для этого кода.

Да причём здесь пинать? Я в смысле, что спрашивают про него часто в последнее время.

очевидно что порядок важен для этого кода.

Наверное, имелось в виду, что порядок не важен? В обоих случаях мы получаем 'ok'.

ok, протормозил. Самый простой код для которого порядок имет значение вот:

receive
   a -> 1;
   b -> 2
end

ok, отлично! Теперь у нас есть минимальные примеры. Но веселье на этом только начинается.

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

Изучаю сейчас работы Gul Agha. Вернусь в тред позднее.

можно ли любое OTP-приложение переписать так, чтобы оно состояло только из процессов, для которых порядок безразличен.

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

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

Мне вот интересно, чем он лучше в «этой нише» той же clojure?

Мне вот интересно, чем он лучше в «этой нише» той же clojure?

Речь скорее шла о Erlang VM и ее OTP платформы в целом. Когда Clojure портируют на Erlang VM с поддержкой всего OTP, тогда может будет она и лучше. :) Хотя уже есть EFL и Elixir, вполне себе юзабельные.

EFL

что-то это плохо гуглится. можно ссылку или что-то подобное?

Erlang Flavored Lisp http://lfe.github.io/

компилируется в низкоуровневый байткод для VM и легко интегрируется с модулями написанными на Erlang

Спасибо! читал когда-то, но не придал значения.