OberonCore

Появилась одна идея использования "Рокот".
На мой взгляд, была бы интересна трансляция программ, написанных на языке MATLAB в язык Оберон. Такой результат работы, пожалуй, будет полезен многим. Хотя бы тем, кто имеет алгоритм работы в Матлабе и хочет реализовать его на некотором языке, получая на выходе некоторый компонент-библиотеку.

Тут Рокот сам по себе неважен.

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

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

Не могу судить.

Там так запущено всё, да?

Кстати, в матлабовском симулинке функции можно писать на разных языках, в том числе на Аде. Но там всё строго по шаблону. Фактически нужно написать заранее придуманные разработчиками MATLAB "заклинания", кое-где подставив свои параметры. Шаг вправо, шаг влево - растрел!

Так называемые М-файлы пишут на языке MATLAB. После Оберонов "не возбуждает" . Для математических приложений это без сомнения мощный инструмент. Хотя несколько тормозёвый. Как зависнет, выдаёт окно с фирменным логотипом Java . Много специализированных функций. Частенько использую для моделирования, для расчета коэффициентов цифровых фильтров и т. д..

Извиняюсь, если не в тему или давно известно…

Ещё есть такое применение Рефала.

Можно кратко, чем отличается Рефал-0 от Базисного Рефала и от Полного Рефала (Рефал-5)?

Я не помню точно, чем именно шире те Рефалы, чем мой.
У меня самый минимум для работы на двух стеках символов без динамической памяти и рантайма.
Поэтому отсутствуют древовидные списки - "изюминка" Рефала.
Ну и всё прочее...

Т.е. скобочек нет?
Зато синтаксический сахар из полного рефала присутствует. Это хорошо.

А что Вы имеете в виду под синт. сахаром?

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

Ну, например where конструкция.
У вас это называется "Образцы с условиями":

Ещё одно ограничение - только одна e-переменная в образце. Для того, чтобы сделать возможным безоткатное сопоставление (тупой линейный поиск).

Стоп. А разве в коде процитированном выше вот тут:

в образце не две e-переменные (eIdent, e3)?

Пардон. До двух e-переменных, конечно.

Пробую тут компонент генерации кода из рефала.

Взял тестовый код из википедии.
для строки AbbA все работает, для строки 'AwbbA' все работает, а вот для строки 'AbbAw' или 'wAbbA' получаю trap в сгенерированном коде.

Пётр, постараюсь посмотреть сегодня-завтра, отпишусь здесь.

Пётр, Вы неправильно готовите

Вот пример рабочей главной процедуры - взято из RocotObxSolvePath.


Только AbbAw надо выделять - там чтение выделения.

В чём фишка? в том, что in и out - это - не строки!! А рабочие стеки! Refal-0 не использует никакой памяти в процессе работы, кроме этих стеков.

С out-том идёт работа слева направо (вершина стека - в конце out), с in-ом - справа налево (вершина стека - с начала массива).
Это значит, что в процессе работы вершина может идти в меньшую сторону от p. На некоторых алгоритмах - нет. Но на Вашем - получается, что сгененированный код пытается использовать -1-ю ячейку массива in.

Поэтому:
1) Брать in и out с запасом под работу алгоритма. В in класть данные к концу массива, оставляя место в начале.
2) После окончания работы алгоритма левая часть результата лежит в out[0..r-1], правая - в in[p, q-1]. Их нужно конкатенировать.

Да, теперь всё работает.
А размер отступа от начала in в 10 символов рассчитывается или наугад взят?