Дополнение.
...и нечто , что я не понял, здесь на картинке почтив конце статьи
Это тот же ACME , портированный в Inferno...
Приёмы работы - копия с Оберона 100%. Но они это только в acme и делают, а не распространяют на всю среду операционки...
Кстати, Limbo - основной язык в Inferno - почти Оберон, только с "оcтаточными явлениями" в виде синтаксиса Си. Но объявления типов (сишные часто общественностью выставлялось геморроем) они сделали паскалеподобными... И есть интересная вещь в виде явной загрузки реализации модулей. То есть интерфейс может быть объявлен в одном файле, а реализацию этого интерфейса можно брать из нескольких модулей, какая вам больше нравится или подходит.
Кроме того, я согласен с аргументами, что разделитель между объектом и его полями, и модулем и элементом модуля лучше сделать разными по написанию...

Здесь будет
Module->module_item
и
object.object_part

Ну, и наконец апофеоз - до ребят дошло, что в компонентной системе всё же лучше со сборкой мусора...

Вирт не упоминается вообще. А если и вынуждены ссылаться, то с огромным черпаком дёгтя:
http://cm.bell-labs.com/sys/doc/acme/acme.html

The most ambitious attempt to face these issues was the Cedar system, developed at Xerox [Swei86]. It combined a new programming language, compilers, window system, even microcode a complete system to construct a productive, highly integrated and interactive environment for experienced users of compiled languages. Although successful internally, the system was so large and so tied to specific hardware that it never fledged.
Cedar was, however, the major inspiration for Oberon [Wirt89], a system of similar scope but much smaller scale. Through careful selection of Cedar's ideas, Oberon shows that its lessons can be applied to a small, coherent system that can run efficiently on modest hardware. In fact, Oberon probably errs too far towards simplicity: a single-process system with weak networking, it seems an architectural throwback.

Вот так вот!  throwback, паиаишь!

Но здесь Пайк очень Керниганом перекликается, в оценках. Это я на счёт статьи последнего “Почему паскаль не является моим любимым языком программирования”. Объединяет их то, что на момент написания статей (и по паскалю и по acme) у Вирта уже были и работали варианты систем, в которых были устранены, указанные Пайком и Керниганом “недостатки”, но авторы этого “не знали” или “не были а курсе дела”. Тогда к ним возникает вопрос о добросовестности и осведомлённости в своей области...

Ну а дальше трубы и литавры:

Acme is a new program, a combined window system, editor, and shell, ...

с признанием:

that applies some of the ideas distilled by Oberon.

Но, вот оказывается в чём пркимцщество, в отличие от оберона:

Where Oberon uses objects and modules within a programming language (also called Oberon), Acme uses files

Опаньки! Но ведь файлы, а вернее интерфейс доступа к ним – только подмножество тех решений, если мы примем точку зрения Оберона... У Кернигана я прочитал по этому поводу, что, мол, да, мы ограничены в абстракциях – работаем на уровне системы только с файлами (подразумевая и унифицируя под них всё от собственно файлов и до вывода графики), но зато приёмы работы уже определены и знакомы и дисциплины определения доступа тоже знакомы и привычны.
Может быть... Но мне кажется, что такое ограничение точки зрения программиста несколько искусственно и ведёт к не совсем “родным” решениям в той или иной ситуации...
Ну и в конце:

and commands within an existing operating system (Plan 9). Unlike Oberon, Acme does not yet have support for graphical output, just text. At least for now, the work on Acme has concentrated on producing the smoothest user interface possible for a programmer at work.

Ответ на »сообщение 1399« (Max Belugin)
___________________________
Интересно, что даже в bell-labs пришли к тому, же решению, что в Оберонах...
acme в Plan 9  и нечто , что я не понял, здесь на картинке почтив конце статьи
http://www.citforum.ru/operating_systems/inferno/
превозносятся, как новое и революционное достижение... :о) История повторяется...

Ответ на »сообщение 1398« (info21)
___________________________


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


Вполне вероятно что он имел ввиду использование комстроки в качестве API а не интерфейса пользователя: взять свой любимый редактор или среду разработки и вызывать оттуда компилятор...

В предвкушении судьбоносных эволюций Блэкбокса (что-то у оберонов пёр пошел) вот мысль какая образовалась об Обероне.

Тут один бывший товарищ настойчиво просил Оберон, но с командной строкой.
Положим, любые привычные юникс-образные команды реализованы под Обероном (ясно, что это самое главное; но все же требование командной строки имело явное место).

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

Командная строка -- ведь тоже вроде текстовый интерфейс, пусть и примитивный. Редактирование есть, история где-то хранится и вызывается, отображение литер на экране есть.
Ну, усовершенствовали его: не в одной нижней строке можно стало команду запускать, а в любой.

В юниксах с уиндоузами текстовые окошки -- навес над командной строкой. Понятно. Лишняя сложность. Но если уже текстовый интерфейс встроен на таком же базовом уровне, как раньше командная строка, то в чем проблемы?

С точки зрения профессионала, которого мы искали-искали (в чем указанный товарищ главную проблему видел) и, наконец, нашли: вводить команду в любом месте текста -- это что ему, профессионалу, концептуальное затруднение?

Есть один у меня знакомый, профессионал фортрана с 35-летним стажем: так он до сих пор отступов не признает и предпочитает янтарные буквы на черном фоне (чем-то там янтарные буквы лучше зеленых; говорит, научно было доказано).

Можно, конечно, провести формальную аналогию: минимализм Оберона <--> минимализм интерфейса командной строки.
Но все-таки: алгоритм формулировать на формальном языке -- дело левополушарное, а глазами экран сканировать -- правополушарное -- и аналогия разрушается: треть мозга, делающая в риал-тайм фурье-трансформ образа на сетчатке, помощнее будет, чем 7 регистров кратковременной памяти в левом полушарии, в которых компонуются инварианты цикла и т.п.
Известно же всем присутствующим, что, например, в распечатке программа -- как разложишь листочки -- "виднее". Так что вроде двумерный интерфейс заведомо помощнее будет практически, а не только теоретически. Применить к системным ЯП это еще никто толком не смог (разве что отступы придумали), а рабочие бумажки на столе (окошки на экране) каждый может разложить с большим нередко удобством. Зачем отказываться? (Крайние случаи не берем. Может, конечно, у товарища именно крайний случай.)

Дурацкая, конечно, мысль. Но интересно наблюдать фенОмен инерции мышления в разных ее проявлениях.

Ответ на »сообщение 1396« (Ivan)
___________________________
MODULE  PrivMeta;
IMPORT  Log := StdLog, Meta;

TYPE
MyType* = POINTER TO RECORD
s : ARRAY 10 OF CHAR;
END;

PROCEDURE ( mt : MyType ) Test (  ), NEW;
VAR 
BEGIN
Log.String(mt.s); Log.Ln;
END Test;

PROCEDURE DoIt*( );
VAR 
item : Meta.Item;
myObj : MyType;
s : Meta.Scanner;
BEGIN
Meta.Lookup("PrivMeta", item);
ASSERT( item.obj = Meta.modObj, 20);
item.Lookup("MyType", item);
ASSERT( item.obj = Meta.typObj, 21);
myObj := item.New()(MyType);
myObj.s := "OK";
myObj.Test();
END DoIt;

BEGIN
END PrivMeta.

Что-то я перемудрил. Предыдущий вопрос снимается, всё работает.

Но попутно возник другой - как в ЧЯ создать объект по его имени? Как это реализовано в модуле Stores? Он вроде импортирует только Files, и ни там, ни там я похожих функций не нашёл.

Вопрос по поводу ЧЯ.

Я реализую понятие координат. По идее это абстрактное понятие, допускающее несколько реализаций:

TYPE
  Coords* = POINTER TO ABSTRACT RECORD END;
  Coords2D* = POINTER TO RECORD(Coords) END;
  CoordsND* = POINTER TO RECORD(Coords) END;
...
  PROCEDURE (c : Coords) Dim(): INTEGER, NEW, ABSTRACT;
  PROCEDURE (c : Coords) Get(i : INTEGER): REAL, NEW, ABSTRACT;
...

Всё работает. Но я хочу использовать возможности модуля Stores. Пишу

TYPE
  Coords* = POINTER TO ABSTRACT RECORD(Stores.Store) END;
...

ругается "base type must be abstract", что в принципе понятно. Ставлю

TYPE
  Coords* = POINTER TO EXTENSIBLE RECORD(Stores.Store) END;
...

ругается на процедурах "record must be abstract", что тоже понятно. Но ведь пустые расширяемые методы в данном случае бессмысленны, т.к. тип реально абстрактный! И что делать?

И попутный вопрос: как повесить действие на Ctrl+BackSpace?

Ответ на »сообщение 1393« (Владимир)
___________________________

Угу, теперь понятно. :о)

Ответ на »сообщение 1390« (Сергей Крысов)
___________________________
Вроде как ББ вырос из Native Oberon, и все команды ОС (dir, copy и т.д.) есть процедуры какого-то модуля, отсюда и ограничение в 2 параметра...
А может и не отсюда...

Да нет же, Сергей, я уже написал в №1388:
commanders are used as convenient alternatives to menu entries during development
Если не понятно, я переведу:
коммандеры используются как удобная альтернатива для пунктов меню вовремя отладки
А там, в файле конфигурации меню, когда Вы описываете команду, вы можете максимум два параметра описывать у процедуры. Вот оттуда и "растут ноги" данного ограничения... :o)

О передаче параметров через коммандер:

Все допустимые комбинации параметров (до 4-х) описаны в документации модуля StdInterpreter (упоминается в конце документации модуля Dialog).

На всякий: строковые параметры должно заключать в одинарные кавычки, а всю команду -- в двойные:
(!)"Module.Do('a','b',2,3)"

Никакого глубокого смысла в ограничении на параметры в коммандере нет.

-----------------------
Вот еще два кунштюка по поводу параметров:

1) модуль-пример ObxParCmd -- кнопка в тексте, умеющая узнавать о своем контексте (читать там параметры).

2) если в command-line при вызове ББ поставить параметры:

BlackBox.exe /par "my parameter list"

то их можно найти изнутри ББ в переменной Dialog.commandLinePars.

В частности, так можно запускать несколько автономных экземпляров ББ (ББ-процессов; причем не обязательно на одной машине), настроенных на общение друг с другом по TCP/IP средствами модуля CommTCP.
Настройку отдельных ББ-процессов можно делать в процедуре Config.Setup (или еще в Startup.Setup; см документацию к Config).