ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Построение интерпретаторов средствами языков логического программирования

Статья опубликована в выпуске журнала № 3 за 1993 год.[ 22.09.1993 ]
Аннотация:
Abstract:
Авторы: Резник В.Г. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 9201
Версия для печати

Размер шрифта:       Шрифт:

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

На практике эта идея сталкивается с рядом трудностей. Любая операционная система, в том числе MS DOS, содержит интерпретатор команд, но набор их минимален. Только файлы с расширением .bat являются интерпретируемыми. Оболочки DOS [1,2], используя окна, меню, списки файлов, деревья директорий и т.п., в основном ориентированы на работу с файлами. Развитие инструментальных средств идет по пути создания отдельных процессов (утилит) или применения готовых пакетов, например Norton Utilities 6.0 [3]. Большинство ограничений устраняется использованием интерпретаторов типа BASIC. Например MS DOS версии 5.0 имеет собственный интерпретатор QBASIC с мощной интегрированной оболочкой [4]. Но универсальные интерпретаторы малоэффективны при создании информационных систем. Для этого используют Clipper, FoxPro, Paradox и другие, которые более специализированы и имеют собственные развитые языки программирования. Общие тенденции развития инструментальных систем направлены на повышение их "интеллектуальности" и использование графических интерфейсов. Например в [5] обсуждаются графические способы визуализации процессов программирования, анализа и отладки, а в [6] — реляционный подход к организации обмена знаниями-между системами с искусственным интеллектом.

В данной статье предлагается система разработки интерпретаторов, для реализации которой используется язык логического программирования Turbo-Prolog [7].

СТРУКТУРА СИСТЕМЫ ПОСТРОЕНИЯ ИНТЕРПРЕТАТОРОВ

Структура системы построения интерпретаторов показана на рисунке I: исходный текст интерпретатора компилируется и объединяется с объектными модулями из библиотек, которые могут быть подготовлены с использованием таких языков, как Turbo-Assembler, Turbo-Pascal, Turbo-C, Turbo-Prolog. Подобным образом интегрированная среда Turbo-Prolog обеспечивает создание ЕХЕ-модуля интерпретатора с возможностями логического и функционального языков Программирования. Желаемый эффект упрощения разработки достигается посредством представления исходного текста интерпретатора в виде трех модулей. МОДУЛЬ

описания базовых типов и базы данных содержит синтаксические конструкции, задающие структуру грамматики интерпретатора. МОДУЛЬ базовых предикатов определяет словарный состав языка, отображая его на функции и предикаты библиотек объектных модулей. МОДУЛЬ алгоритмов интерпретации - универсальный. Он может оставаться неизменным, если не изменяется сама идеология построения интерпретаторов.

Общий алгоритм разработки конкретного приложения с помощью предлагаемой системы следующий: пишутся я отлаживаются основные функциональные компоненты, которые помещаются в библиотеки объектных модулей; дается описание базовых предикатов и, если необходимо, дополняются и модифицируются базовые типы данных; с помощью инструментальных средств Turbo-Prolog создается ЕХЕ-модуль интерпретатора, который затем рассматривается как ядро будущего приложения; проводится формирование баз знаний (правил, продукций, функций), которые интерпретируются ЕХЕ-модулем ядра приложения.

РЕАЛИЗАЦИЯ СИСТЕМЫ

На рисунке 2 показан пример МОДУЛЯ описания базовых типов и базы данных. Здесь выделены простейшие типы (имя предиката, строка, переменная, целое число, вещественное число), объединенные типом ЕХР. Этот список может изменяться и дополняться как указано выше. Синтаксическая конструкция типа ExpList (список простейших типов) задает структуру обращения к отдельным предикатам. Первый элемент списка - имя предиката, а остальные — аргументы. Тип Body описывает отдельный предикат: первый подсписок - заголовок предиката; остаток — тело предиката. Внутренняя база данных определяет структуру хранения отдельных предикатов в файловой системе DOS.

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

На рисунке 3 представлен демонстрационный пример МОДУЛЯ базовых предикатов. Описание дается множеством предикатов типа g(...) с тремя аргументами. Первый аргумент (строковый тип) — имя функции (предиката). Второй аргумент (список простейших типов) — аргументы функции (предиката). Третий аргумент (тип Body) - определяет конкретизацию переменных значениями простейших типов после выполнения базового предиката. Сколько переменных - столько подсписков должен содержать третий аргумент. Например:

й("Чтенне строки", [slr(F),var(S)],[[var(S),str(Z)]]):-bound(F),existlile

где "Чтение строки" - имя функции; str(F) -строковый тип (переменная F - имя файла); var(S) - переменная (S - имя переменной).

После выполнения данного предиката прочитанный файл должен быть записан в переменную (типа строка), поэтому третий аргумент содержит единственный подсписок [var(S), str(Z)].

Исходный текст интерпретатора показан на рисунке 4. Его алгоритм соответствует МОДУЛЮ алгоритмов интерпретации. Сначала подключается МОДУЛЬ базовых типов и базы данных (файл "GOAL_DO.DOM"). Затем дается описание предикатов: concatBody(...) - конкатенация списков типа Body; place(...), placel(...), place2(...) - подстановка конкретных значений вместо локальных переменных; check(...} и checkl(...) - проверка выполнения каждого правила в соответствии с требованием: все переменные типа var(...) должны быть конкретизи-

рованы; divideARG(...) — разделение конкретизированных и неконкретизированных переменных типа var(...) на два списка. МОДУЛЬ базовых предикатов подключается из файла "BASEJ3.PRO". Предикаты do_g(...) и do(...} определяют алгоритм выполнения правил, причем все подсписки, входящие в каждое отдельное правило, связаны общими переменными и логической операцией конъюнкции. Начало и завершение работы интерпретатора задается предикатом mygoal. Интерпретатор вызывается из командной строки DOS с указанием имени файла базы знаний (БЗ). Загружаемая БЗ должна иметь хотя бы одно правило с именем "цель". Если файл не найден, то интерпретатор заканчивает работу.

Пример использования интерпретатора

Рассмотрим чисто демонстрационный пример с использованием трех последовательно вызываемых БЗ. Первая БЗ загружается из файла "B1.BZ" (рис. 5). В результате должно быть создано рабочее окно и загружена вторая БЗ из файла "B2.BZ" (рис. 6) с указанием достичь цель — "цель 2". Если файл второй БЗ не найден, то выполняется альтернативная группа правил: выдается соответствующее сообщение; после нажатия любой клавиши рабочее окно удаляется, и интерпретатор заканчивает работу. Правила второй БЗ обеспечивают редактирование файла "Т2.ТХТ" и загружают третью БЗ из файла "B3.BZ" (рис. 7) с указанием достичь цель - "цель 3". Если файл "B3.BZ" не найден, то альтернативные правила аналогичны первому случаю. Третья БЗ обеспечивает редактирование файла "ТЗ.ТХТ", удаляет рабочее окно и завершает работу интерпретатора.

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

Предлагаемая система обеспечивает необходимые средства управления альтернативными ситуациями. Например, первая БЗ содержит предикат с заголовком пт("цель"), а тело предиката - подсписки [шп("Создание окна")] и [шп("цель 1")]. Сначала будет найден предикат с заголовком пт("Создание окна"), тело которого - обращение к единственному предикату с заголовком шп("Окно") и списком аргументов. Сам предикат с заголовком шп("Окно") отсутствует в текущей БЗ, поэтому он будет найден среди базовых предикатов типа g(...). Когда рабочее окно будет создано, начнется поиск и выполнение предиката с заголовком пт("цель 1"). Текст БЗ на рисунке 5 содержит два таких предиката. Порядок их записи соответствует порядку выбора возможных альтернатив при решении задачи. Выбор первой альтернативы предполагает: БЗ в файле "B2.BZ" может быть загружена; все предикаты текущей БЗ будут удалены из памяти ЭВМ; предикат с заголовком пт("цель 2") содержится в файле "B2.BZ". Выбор второй альтернативы означает, что файл "B2.BZ" не найден. Логика применения правил второй и третьей БЗ аналогична рассмотренной выше.

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

Спшсок литературы

1.      Миллер М.Дж. Мои любимые оболочки DOS - почему одной оболочки недостаточно // Мир ПК. - 1990, N 3. - С. 44 - 46.

2.  Маршал П. Оболочки DOS, какую выбрать? // Мир ПК.

-  1990, N 4. - С. 36 - 45.

3. Мендельсон Э. PC Tools 7.0 н Norton Utilities 6.0 начи наются там, где кончается DOS S.0 // PC Magazine, USSR.

-  1991, N 3. - С. 68 - 70.

4.  Очков В.Ф. Среда программирования QBASIC в руси фицированной версии MS-DOS 5.0 // Библиотека информа ционной технологии: Вып. 4. - М.: ИнфоАрт, 1992. - С. 108 - 132.

5.  Галаган Н.И. и др. Инструментальная система логи ческого программирования на основе графических спосо бов визуализации процессов программирования, анализа и отладки // УСиМ. - 1992, N 5/6. - С. 42 - 50.

6.  Цуканов А.В. и др. Организация обмена знаниями меж ду различными системами с искусственным интеллектом // Программные продукты и системы. - 1992, N 3. - С. 35 -40.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1200
Версия для печати
Статья опубликована в выпуске журнала № 3 за 1993 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: