Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Oleg N. Cher]

Значит это может быть достигнуто путём использования встроенного интерпретатора, но написанного библиотечным способом. Я начинаю думать, что лямбда-исчисление доступно для Оберона. Вот смотрите, возьмём для примера BlackBox Component Builder. В нём есть подсистема Dev, содержащая компилятор Компонентного Паскаля. Он вызывается с помощью команды активации компиляции из меню. Не составит никакой проблемы вызывать компилятор из своего собственного модуля. Не составит и никакой проблемы переориентировать компилятор брать входной текст (на Компонентном Паскале) не из текстового окна, а прямо из вызывающего кода. Это может выглядеть так (код условный):

MODULE Lambda;

IMPORT Dev, Kernel;

CONST
  MyCode = "MODULE MyCode; IMPORT Out; BEGIN Out.String('Hello, integrated World!') END MyCode;";

  BEGIN
    Dev.CompileText(MyCode);
    Kernel.LoadModule("MyCode");
    Kernel.RunModule("MyCode");
END Lambda.

Данный подход конечно пользуется компилятором и ядром, но зато - никакой интерпретации.

---------- Post added at 23:42 ---------- Previous post was at 22:10 ----------

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

Просто Дельфи- или Си-программист воспринимает компилятор как нечто совершенно отчуждённое от его личного кода. В Оберон-системе компилятор - такой же компонент, как и любой другой. И точно также ему можно посылать сообщения и получать ответы. Точно так же обстоят дела и с IDE, документами, окнами и любыми другими контролами.

Именно поэтому в Оберон-системе как правило не нужен внутренний скриптинг на другом, отличном от Оберона языке. Т.е. это конечно возможно, но зачем, если Оберона во многом достаточно. И всё это - без использования виртуальной машины. Или с ней, если понадобится.

[Advertiser]

[Eltaron]

Это может выглядеть так (код условный):

А указатели на функции в Обероне есть? Скомпилировать в рантайме кусок кода - это одно дело, но его же надо ещё и передать в функцию, выполняющую сортировку или поиск.
В любом случае, когда код записан строкой - он не типобезопасен. Он вообще не безопасен, там и опечатки могут быть, и что угодно ещё. В C# и C++11 очень круто то, что все эти конструкции проверяются ещё на этапе компиляции.

[Oleg N. Cher]

А указатели на функции в Обероне есть?

Конечно есть:

PROCEDURE Fn(): INTEGER; BEGIN RETURN 0 END Fn;
...
VAR fn: PROCEDURE (): INTEGER;
BEGIN
  fn := Fn; ...
...
END ...

В любом случае, когда код записан строкой - он не типобезопасен. Он вообще не безопасен, там и опечатки могут быть, и что угодно ещё. В C# и C++11 очень круто то, что все эти конструкции проверяются ещё на этапе компиляции.

Ну собсно обработку ошибок я опустил для упрощения. А так - почему бы не проверить вывод компилятора и не отреагировать соответствующим образом.

Я опасаюсь, что ново-программисты будут использовать такое средство как лямбды, для которого конечно можно придумать хорошее применение, втуне. Т.е. не понимая чётко всего механизма. А оно как - компилируется? А потом? Куда-то загружается и запускается? Т.е. вся эта тянучка из компилятора и рантайма присутствует в конечном продукте. И накладные расходы соответствующие. Для сортировки списка или поиска элемента - это уже слишком.

Как обстоят дела с INTEGER 64bit в языке ОБЕРОН ?

В зависимости от реализации. В стандарте Оберона/Оберона-2 размеры типов не зафиксированы. Традиционно (ETH Oberon, A2/AOS, XDS) INTEGER = 16 бит; LONGINT = 32 бита. Для 64 битов в некоторых реализациях есть тип HUGEINT.

В Component Pascal, XDev/WinDev INTEGER = 32 бита; LONGINT = 64 бита. Есть ли возможность использовать именно 64-битный INTEGER? В XDev/WinDev - да. Размер всех типов задаётся в специальном файле-конфигураторе Ofront.par, выглядящем примерно так:

CHAR 1 1
BOOLEAN 1 1
SHORTINT 2 2
INTEGER 4 4
LONGINT 8 8
SET 4 4
REAL 4 4
LONGREAL 8 8
PTR 4 4
PROC 4 4
RECORD 1 1
ENDIAN 1 0

Коим образом можно "перенести" работу с битовыми полями с С на Оберон ?

Для работы с битовыми полями предлагается тип SET, что во многом снижает потребность в логических операциях AND, OR, XOR. Несмотря на некоторую громоздкость записи, логические операции для целых в Обероне всё-таки можно использовать.

Вирт Н. SET: Недооцениваемый тип данных и его компиляция для ARM

Как обстоят дела с объединениями ?
union {
u16_t var1;
struct {
u8_t aaa;
u8_t bbb;
}
}

var1 = 0x1122;
tmp = aaa + bbb;

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

Какая альтернатива предлагается для замены объединений? Расширяемые записи.

TYPE
  Father = (*EXTENSIBLE*) RECORD
    a, b, c: INTEGER; (* Это общие для всех потомков поля *)
  END;
  Son = RECORD (Father)
    d, e: CHAR; (* Это только данные сына *)
  END;
  Daughter = RECORD (Father)
    d, e: SET; (* Это только данные дочери *)
  END;

Оберон строг в проверке типов и на этапе компиляции, и в рантайме. Он спроектирован так чтобы по максимуму обезопасить работу с указателями. Соответственно нет смысла кастить объект типа Son в объект типа Daughter и пытаться работать с полями сына как с полями дочки. Вместо этого применяется охрана типа:

obj: POINTER TO Father; (* Это указатель на отца и др.членов семьи *)
BEGIN
  IF obj IS Son THEN ... END; (* Проверка того, что это сын *)
  WITH obj: Daughter DO (* Гарант того, что объект - дочь *)
    (* Если объект не дочь - ловится ошибка исполнения или исключение *)
  END

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

В принципе, мне объединения ещё ни разу не понадобились, кроме как в биндингах к SDL 1.3 (там есть их два штуки).

Хочу подчеркнуть, что Оберон - маленький язык. Если хочется увидеть в нём прямые аналоги всех сишных возможностей, то этого нет. Но зато, например, компилятор ARM Oberon-07 занимает ~ 3 000 строк исходника. OP2 (Oberon Portable Compiler) ~ 10 000 строк.

Так что присуща некоторая аскетичность. Но, в принципе, возможностей хватает, просто нужно слегка перестроить мышление.

[AlexG]

Общий вопрос:
Как обстоят дела с INTEGER 64bit в языке ОБЕРОН ?
Коим образом можно "перенести" работу с битовыми полями с С на Оберон ?
Как обстоят дела с объединениями ?
union {
u16_t var1;
struct {
u8_t aaa;
u8_t bbb;
}
}

var1 = 0x1122;
tmp = aaa + bbb;