Subject: Re: Re[2]: RAFAL & JAVA
From: A.A.Vladimirov (vladimi@mech.math.msu.su)
Date: Wed Jan 19 2005 - 18:34:50 MSK
В Срд, 19/01/2005 в 16:26 +0200, Leonid Belous пишет:
> Добрый вечер, всем!
>
> Антон, хочу заранее извиниться за возможную свою неумелость, но ...
> провести предлагавшиеся эксперименты с Вашим хозяйством как с "черным ящиком" мне не удалось.
> Напрямую (так, чтобы у Вас чего-нибудь не менять) у меня не собирается не только под FreeBSD,
>но и под тремя вариантами Linux (ASP, ALT, Mandrake, Debian).
> С грехом пополам (убрав в makefile параметр, вызываший ругань -mtune=pentium3 )
Извиняюсь: данный параметр для компиляции не принципиален (и, возможно,
поддерживается не всеми gcc).
> удалось собрать под одним из Linux, но запустить zamena.ref в режиме скрипта не удается
> (ругань типа bad interpreter).
Если интерпретатор действительно лежит по указанному после #! пути, это
довольно странно. Проверю.
Кстати, забыл написать, что makefile предполагает запуск make из-под
root'а (нужны права на запись в некоторые системные каталоги). Равно как
забыл написать, что внутри файла Bibliotekoj лежит ещё один makefile
(для библиотек функций), предполагающий самостоятельный запуск.
Так что бейте меня, а равно топчите меня ногами. (C) И.Ильф и Е.Петров
> Казалось бы, должен был проработать из командной
> строки эквивалентный запуск (с удалением первых трех строк в zamena.ref)
> >refal zamena.ref
>
> Но в этом случае выдается сообщение: Eraro: apliko je sendeterminita funkcio.
Чему я на сей раз не удивлён: вторая и третья строки относятся не к
shell, а к Рефалу (подключают библиотеки функций ввода-вывода и
интерактивного режима). Если их убрать, программа действительно не
сможет заработать по причине неопределённости ряда функций.
> Пробовал давать >refal test , где файл состоит из одной строчки из 4-х единиц,
> получил сообщение: Dosiero z.ref, linio 1: malbona determino de objekto.
>
Перевод:
Файл z.ref, строка 1: неверное определение объекта
Полагаю, здесь всё дело в том, что Ваш файл не есть рефал-программа :)
Кстати: у меня (Fedora Core 3, локаль ru_UTF-8) все сообщения об ошибках
выдаются на русском языке (ибо одна из строк makefile'а генерирует файл
с русским переводом оных). Попробую проверить, что будет под другими
русскими локалями (и дистрибутивами).
> Антон, наверное бы я разобрался и подправил кое-где, кое-что в Вашем "черном ящике"
> или в настройках Linux, но я быстро прекратил эти попытки по следующей причине.
> Нникак не умаляя возможной оригинальности Вашей разработки
> (содержащей сотни строк на С), хочу остановиться на одном негативном моменте.
>
> Комментарии написаны на языке, как я понимаю, типа Esperanto.
Точнее, на ЛОМАНОМ эсперанто. Поскольку на первом этапе разработки я не
был уверен, буду ли опубликовывать результат, решил попрактиковаться :(
Комментарии, конечно, надо будет перевести на что-то более читабельное.
> Вопрос по сути:
> Зачем Вам интерпретатор языка Рефал, а не интерпретатор,
> написанный на языке Рефал для Вашей конкретного класса задач?
>
> Как мне показалось, Вам пока нужно было в диалоге воспринимать текст
> с учетом кодировки Юникод, а потом с ним что-то делать? Зачем в диалоге
> вводить и обрабатывать предложения на языке Рефал?
> У меня когда-то стоял подобный вопрос, когда Рефал применялся при
> создании системы компьютерной алгебры "Сириус".
>
> Вспоминая нашу с Вами переписку, относительно нехватки встроенных функций
> в Рефале для обработки текста в кодировке Utf-8, задаю вопрос - Вам не
> хватает встроенных функций в Рефале и неустраивают компилирующие реализации Рефала,
> поэтому Вы решились написать свой интерпретатор с языка Рефал?
> Скорее всего я Вас неправильно понимаю, посему прошу разъяснений.
>
Да нет, скорее всего, это я недостаточно подробно описал, что меня не
устраивает в том же Рефале-5.
Во-первых: язык преподносится как бестиповый, на деле __не являясь
таковым__. Ибо макроцифры, буквы и составные символы - это, в сущности,
три разных типа данных. При этом объём этих типов конечен. Поэтому,
например, чтобы "подружить" юникод с Рефалом-5, нужно или вводить
__новый тип данных__, или заниматься трюкачеством. При использовании
длинной арифметики тоже нужно помнить, что натуральное число - это не
символ, а целое выражение - и помнить, когда оное нужно брать в скобки,
а когда - нет (впрочем, насколько я помню, из Рефала-плюс макроцифры уже
убрали).
Во-вторых: насколько я смог понять, реализация Рефала-5 сделана таким
образом, что все встроенные функции (понимая так функции, написанные не
на Рефале, а на C) должны быть "вбиты" в ядро, и физически не могут быть
вынесены в библиотеки, которые можно было бы подключать (или не
подключать) независимо от ядра. Что тоже, на мой взгляд, не есть самое
разумное решение.
Поэтому я и попробовал написать реализацию, которая бы:
1) имела ровно один тип символов (натуральные числа, величина которых
ограничена лишь размером оперативной памяти), к которому сводились бы
все остальные. Именно таким подходом, например, обусловлено появление
числа 10 в файле zamena.ref (это - код символа перевода строки).
2) содержала бы в ядре минимальное число функций, вынося всё прочее в
библиотеки, писать которые можно было бы на основе максимально простых
стандартных приёмов.
Поскольку технологию написания компиляторов Рефала я, мягко говоря, не
очень представляю, то реализация получилась интерпретирующей (и довольно
топорной, хотя, по результатам моих тестов, скорость работы не сильно
отстаёт от Рефала-5). Возможность замены машины по ходу её работы
оказалась при этом __следствием__ характера реализации, а не собственно
целью.
С уважением,
Антон Владимиров
This archive was generated by hypermail 2b25 : Wed Jan 19 2005 - 19:01:08 MSK