[Scheme] Если бы Scheme можно было сделать заново, что бы вы изменили?

Я немного ошибся - имелось ввиду не замыкание, а окружение, конечно. Кстати, что такое «окружение» о котором вы говорили? Т.е. можно написать код с multi-processing (гипотетическим - т.е. с этой самой абстракцией поверх языка) в котором будет что-то не так с окружениями, какой это примерно будет код? И не устранятся ли эти проблемы с помощью message passing?

BitC ещё туда же.

Уже самому не удобно что с перидичностью в 2 дня, но время, но дела.

Кстати, что такое «окружение» о котором вы говорили?

Ко мне лично лучше на ты или безлично.

окружение - англ. environment CLHS:/3.1.1 Introduction to Environments. Там определения и все остальное.

т.е. можно написать код с multi-processing (гипотетическим - т.е. с этой самой абстракцией поверх языка) в котором будет что-то не так с окружениями, какой это примерно будет код?

Железные нити допустим не абстракция а интерфейс к много-ядерности/процессорности.

Что может быть не так? Окружение раствориться в «процессе исполнения» и в случае многопоточного исполнеия становится очень сложно гарнтировать потокобезопасность. Как в противовес пытаемся изолировать процессы с помощью «чистоты» и IPC-зации, частным примером которой будет тупая передача сообщений (об умной чуть попозже). Цена такой изоляции драгоценные ресурсы расходуемы на работу IPC.

Код. Попробую пойти от обратного и показать пример кода с раздельными потоком исполнения и окружением.

;Делаем функцию которая берет соединение и сесию пользователя из окружения.
(defun print-user-sesion ()
   "Функция возвращает пользователю идентификатор сессии"
   (declare (special socket sesion))
   (print-html socket session))

;Создаем окружение и вызываем внуни него нашу фунцию
(progv '(socket user-session) (get-socket&user-session)
   (print-user-session))

Здесь у нас явно разделены выполняемый код, контракт окружения, источник данных для окружения, конструктор окружения и само выполнение кода в потоке исполнения в определнном окружении. Зачем нам все эти сложности? Количество активных процессов исполнения в системе чуть больше или равно количеству ядер/процессов. А количество окружений в виде пользовательских сессий и.т.п. тысячи Самым эфективный способ доступа к данным это доступ через разделяюмую память, но это требует гарантии ссылочной целостности. Такую гарантию может дать выделение окружений как fist-class объекта. А в примере окружение именно first-class, хоть и не явно. Некоторые могут сказать что то же можно добится передавая окружения аргументом, но в таком случае его придется конструировать из аргумента кажый раз при вызове, велосипедным образом повторяя приведенный пример. Что интересно, в примере работа с окруженим транзакционна. IPC же в этом случае выносится на технический уровень реализации потоков исполнения.

Теперь про легкие нити. Они создают иллюзию бесконечного количества потоков исполнения. А любая бесконечная иллюзия штука хрупкая. Пока задачи остаются ограничеными и можно обходится без межпроцессного взаимодействия, то нити остаются аналогом окружений и все до поры до времени хорошо. Но вот процессы встретились.. и мы вновь приходим к выбору разделеямая память / копирование контекста. Да, проблема будет несколько иной поскольку нити писали под себя и что-то пытались для этого учесть. Но и этих иллюзорных «легких нитей» уже запущена тьма и реальная передача сообщений между ними будет отнюдь не дешевой хотя бы из-за маштабов. Таким подходом можно достичь только маштабирования ценой ресурсов, и то только если у нас реально «умный планировщик». Какой из этого выход? Мы можем рассматривать сообщения как связи между «логичечкими» процессами, описывающие их взаимодействие. При таком подходе «процессы» становятся.кирпичиками, которые скрепляются связями в виде событиями/сообщениями в единый оптимальный процесс исполнения. Ссылочную целостность и контракты окружений гарантирует планировщик собирающий процесс исполнения из кирпичиков, так же как макросы в лиспе реализуют абстракцию собирая код из параметров и ее внутренней реализации. Внутренняя реализация планировщика это процессная алгебра - Pi-исчесление. Примерно так, по идее, работает Erlang. Но это уже другая пардигма имеющая очень мало общего с легкими нитями.

Сделал бы C++.

очепятка, Pi-исчисление

окружение - англ. environment

Действительно, чем ещё может быть «окружение» :) Я так и понимал, что речь идёт об environment и критериях thread-save, но за такое подробное объяснение - спасибо.

Сделал бы C++.

При попытке сделать из Scheme С++ произойдёт ССЗБ. Дажа Java «утаскивает куда-то на пол-пути от C++ к лиспу».