Ответ на »сообщение 2495« (Сергей Прохоренко)
___________________________

Кстати, я не заметил в PL/I вкраплений функциональной или скриптовой парадигмы. И почитателей у него гораздо больше, чем у всех оберонов, хаскелей и питонов вместе взятых (обероны мне тоже нравятся, но однобокость в них сильно чувствуется).

Что-то я не слышал о популярности PL/I... Насчёт питонов не могу согласиться - питон сейчас весьма и весьма популярен...


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

Ну ежели на то пошло, то всё это прекрасно реализовано в Хаскелле - ярко выраженная декларативно-функциональная парадигма + жёстко выделленные императивные действия + всё это можно использовать как весьма удобный скриптовый язык.
Умельцы на Хаскелле даже ассемблер в виде eDSL сделали... Вот ещё бы ассемблерной производительности ему добавить...

Ответ на »сообщение 2507« (Сергей Перовский)
___________________________

Все остальное не настолько важно.

То, что Вы перечислили (виртуализация доступа и контроль доступа) сомнений не вызывает. Это можно и нужно делать на самом нижнем уровне. И не только для покупателей. :)

Я понимаю, что все это плохо вяжется с идеей перенацеливаемой ОС.

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

Ответ на »сообщение 2506« (Денис Зайцев)
___________________________

1) Если планируется реализовывать поддержку POSIX, то от понятия файла никуда не уйти: всякие fopen(), fread() и т.д. не дадут. Значит, POSIX нужно реализовывать на нижележащем уровне. Но тогда программы "из мира UNIX" получают привилегированное положение по сравнению с родными приложениями (доступ на более низкий уровень). Это противоречит идее реализации POSIX поверх базовых слоёв системы.

Не совсем так. UNIX-программы (как и любые другие в "Росе") не имеют полного доступа ко всем ресурсам компьютерной системы. Они работают в своей песочнице (виртуальной машине) с выделенными ей ресурсами и под контролем "Росы". При таком подходе можно делать и документы (фреймы, таблицы БД) поверх файлов, и наоборот.

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

2) Если планируется реализовывать поддержку существующих приложений (что "из мира UNIX", что "из мира Windows"), то - хочешь, не хочешь - а файловая система просачивается и на уровень пользователя, ведь мы-то знаем, что эти программы, хоть порой и декларируют, что работают с "документами", на самом деле работают с файлами в иерархической файловой системе.

Опять-таки внизу может быть и так, и так.

Ответ на »сообщение 2507« (Сергей Перовский)
___________________________


Я понимаю, что все это плохо вяжется с идеей перенацеливаемой ОС. Для управления швейной машиной авторизация пользователя необязательна, а для бортового компьютера противотанкового снаряда просто нелепа.
Поскольку любое проектирование я привык вести от цели, для меня абсолютно не ясен подход создания универсальной заготовки для абсолютно различных по назначению ОС. Может быть можно говорить о создании единого ядра ОС, но и в это верится с трудом.


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

В конце концов, можно иметь две-три альтернативные файловые системы (для микроконтроллеров, PC и суперкомпьютеров), и вообще компоновать ОС под конкретное "железо" из альтернативных блоков.

Ответ на »сообщение 2502« (Руслан Богатырев)
___________________________



Файл -- столь же фундаментальное понятие, как адресуемая ячейка памяти. Если делать систему прозрачной для программистов, то надо давать доступ к низкоуровневому представлению. Доступ этот может обеспечиваться как в специальных резервациях ("саркофагах"), так и путем  явного отключения контроля с предъявлением мандата (когда позарез потребовалось залезть на нижний уровень). Система должна быть устойчивой к дураку (который, увы, встречается и среди сисадминов), но допускать возможность разобрать себя до винтика. Только в отношении этой возможности требуется выстроить грамотный заслон ("опломбировать"). Кто решит отключить штатный режим (автопилота) и перейти на аварийный (ручное управление), должен отдавать себе в этом отчет и иметь необходимые полномочия. Более того, его действия все равно будут (по возможности, разумеется) идти под контролем.

Можно понять, для чего программистам прямой доступ непосредственно к памяти (особенно к регистрам, к кэш-памяти). Для максимальной скорости и для максимально полного использования. Гораздо менее понятно, зачем нужен прямой доступ к жестким дискам - достаточно иметь хорошо реализованные библиотечные процедуры. Но зачем, имея документы, лезть в по сути промежуточный файловый слой? Что это дает? Ничего, кроме потери функциональности. Разве современные СУБД значительно более медлительны, чем древовидные файловые системы? Думаю, что нет. Для ускорения можно не обрабатывать теги (в смысле не хочешь - не пользуйся), искать файлы непосредственно по имени, не использовать связи между документами, переписать алгоритм. Ускорение достигается всего лишь самоограничением программиста.

Для работы приложений из "миров" UNIX и Windows, которым требуется древовидная файловая система, её можно эмулировать поверх документарной СУБД в чем-то вроде Java-"песочницы".

Ответ на »сообщение 2498« (Руслан Богатырев)
___________________________
О каком пользователи мы говорим? Системный программист, прикладной программист -- то же пользователи ОС. Для какой роли что открывать (какие уровни абстракции, какие сущности ОС и их атрибуты) -- непростой вопрос.
По мне продавец и кассир не пользователи магазина, а сотрудники. А пользователями являются покупатели :)
Чтобы магазин имел успех удобно должно быть прежде всего покупателю.
Впрочем, автоматизированное наведение порядка на носителях информации должно облегчить жизнь и администраторам и программистам.

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

Я понимаю, что все это плохо вяжется с идеей перенацеливаемой ОС. Для управления швейной машиной авторизация пользователя необязательна, а для бортового компьютера противотанкового снаряда просто нелепа.
Поскольку любое проектирование я привык вести от цели, для меня абсолютно не ясен подход создания универсальной заготовки для абсолютно различных по назначению ОС. Может быть можно говорить о создании единого ядра ОС, но и в это верится с трудом.

Размышляя над идеей сокрытия файловой системы от вышележащих слоёв, наткнулся вот на какие мысли:

1) Если планируется реализовывать поддержку POSIX, то от понятия файла никуда не уйти: всякие fopen(), fread() и т.д. не дадут. Значит, POSIX нужно реализовывать на нижележащем уровне. Но тогда программы "из мира UNIX" получают привилегированное положение по сравнению с родными приложениями (доступ на более низкий уровень). Это противоречит идее реализации POSIX поверх базовых слоёв системы.

2) Если планируется реализовывать поддержку существующих приложений (что "из мира UNIX", что "из мира Windows"), то - хочешь, не хочешь - а файловая система просачивается и на уровень пользователя, ведь мы-то знаем, что эти программы, хоть порой и декларируют, что работают с "документами", на самом деле работают с файлами в иерархической файловой системе.

Ответ на »сообщение 2504« (Руслан Богатырев)
___________________________

-- Norebo-0 (низкоуровневые средства, без ООП, близко к классической Модуле-2);

В Norebo-0 модель Модула-2 будет сильно урезана. Но даст бОльшие возможности работы с низкоуровневыми сущностями. По модели будет близка к классическому Си. Только в синтаксисе Паскаля, с модулями и др. проверенными временем вещами. Отображение на Си будет вполне прозрачным (в обе стороны).

При проработке Norebo будут внимательно изучаться позабытые решения языков 1970-1980 гг.: Mesa, Cedar, Euclid, языки Пер Бринч Хансена и др.

Раз уж коснулись этой темы, скажу, что в отношении нового языка (с условным названием Norebo, т.е. Oberon наоборот) просматриваются три уровня ("слоеный пирог"):
-- Norebo-0 (низкоуровневые средства, без ООП, близко к классической Модуле-2);
-- Norebo-1 (высокоуровневые средства, с поддержкой ООП, близко к классическому Оберону);
-- Norebo-2 (средства сверхвысокого уровня: композиция модулей и процедур/функций, интерфейсы, инварианты, протоколы и др.).

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

* Norebo-0 фактически работает на уровне системнозависимых средств, скорее всего, с сохранением синтаксиса и контуров Модула-2.
* Norebo-1 будет усеченным (строгим) классическим Обероном (без SYSTEM, с разделением на интерфейс и реализацию, с ограничением на побочные эффекты в процедурах, с ограничениями на экспорт переменных и т.п.)
* Norebo-2 будет иметь синтаксис, отличный от Паскаль-направления, ближе к декларативным языкам.

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

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

Ответ на »сообщение 2501« (Денис Зайцев)
___________________________

Судя по оживлённости дискуссии по вопросам электронного документооборота, пора заводить отдельную Interest group  по ЭД внутри проекта "Роса" :)

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

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

Сначала заведем спец. ветку на OberonCore по этому вопросу (все-таки лучше обустраивать сообщество в одном месте). А как там вопрос дозреет до Interest Group (внешней или внутренней) -- можно сформировать. Почему нет?

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