Oberon space

Стоп. А зачем тогда вообще разрешать какой-либо экспорта переменных? И чем, в конце концов, хуже экспорт одной переменной структурного типа чем экспорт 100500 переменных скалярного типа?

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

И таки что такое "переменная скалярного типа"? Насколько это понятие является языковым и не зависящим от деталей реализации?

Понятие "скалярные типы данных" вводятся в обращение ещё в школьном курсе информатики, и трактуются как не имеющие составных частей с точки зрения языка программирования.

Цитата: Kemet от Сентябрь 08, 2013, 04:05:17 am

Как уже предлагал в конференции, сделать по типу Модулы-3:
FROM ModuleName IMPORT X, Y, Z, P := Proc, P1 := Proc1;

неплохо , но требует расширения синтаксиса, как и в случае с алиасом.

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

Как уже предлагал в конференции, сделать по типу Модулы-3:
FROM ModuleName IMPORT X, Y, Z, P := Proc, P1 := Proc1;

Блекбоксёры постоянно ставят в достоинство КП то, что в нём записи можно создавать не только в куче, но и на стеке, в отличие от Явы, где все объекты создаются только на куче.
Этим они объясняют высокую производительность свой шины сообщений.

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

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

Для этого и предназначены opaque типы. Там, где нужны статические объекты в стеке - нужно использовать записи, естественно, экспортируя тип записи.

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

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

Слишком низкоуровневым язык получился. ИМХО.

Смотря где его применять. Для ПЛИС, например, вполне нормально.

А зачем? Никто ведь не мешает обойти массив в том порядке, который нужен.
Потому что иначе, по причине отсутствия динамических массивов, простой реализации не получится, придётся городить что-то подобное:
TYPE
  Chunk = POINTER TO ChunkDesc;
  ChunkDesc = RECORD next : Chunk; END;
  Chunk1024 = POINTER TO Chunk1024Desc;
  Chunk1024Desc = RECORD( ChunkDesc ) value: ARRAY 1024 OF INTEGER; END;
  Chunk512 = POINTER TO Chunk512Desc;
  Chunk512Desc = RECORD( ChunkDesc ) value: ARRAY 512 OF INTEGER; END;
  ...
  ChunkXXX = POINTER TO ChunkXXXDesc;
  ChunkXXXDesc = RECORD( ChunkDesk ) value : ARRAY XXX OF INTEGER; END;

  LIST = Chunk;
Или вообще, каждый элемент оборачивать. Но в любом случае, чтобы получить динамику, придётся городить списковые структуры или даже деревья.

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