Конструкторские решения в Турбо Прологе

В этом разделе мы обсудим, почему включение правил, операторы и ме-

тапрограммирование могут быть смоделированы в Турбо Прологе, а не являют-

ся встроенными функциями, и почему Турбо Пролог был создан как типизиро-

ванный компилятор. К важнейшим причинам таких отличий Турбо Пролога от

традиционного Пролога относятся:

- резкое возрастание скорости;

- лучшая читаемость кода;

- уменьшение времени разработки (для практических приложений);

- лучшее обнаружение ошибок;

- упрощение поддержки программы.

Мы не утверждаем, что у вас никогда не возникнет ситуации, в которой

очень важными окажутся возможность включения правил, операторы и метап-

рограммирование. Однако, по только что указанным причинам лучше смодели-

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

не включать их непосредственно в язык. Традиционные интерпретаторы языка

Пролог позволяют восстанавливать, удалять и добавлять новые предложения к

интерпретируемому исходному коду. Когда программисты, работающие с языком

Пролог, говорят о метапрограммировании, они обычно имеют в виду именно

эту возможность. При традиционном программировании на Прологе большое

внимание также уделяется использованию готового окружения почти до неко-

торого пренебрежения к окружению, структурам и моделям, создаваемым поль-

зователем.

Программирование, ориентированное на правила, - требуемое для экс-

пертных систем - традиционно базировалось на включении базы знаний непос-

редственно в исходный код программы (другими словами, вместе с управляю-

щим кодом). Работая с базой знаний, надо было использовать возможности

встроенной в традиционный Пролог интерпретации обратной цепочки рассужде-

ний для:

1. Преобразования базы знаний в синтаксис языка Пролог;

2. Включения всех правил в систему;

3. Вызова главной гипотезы.

Хотя эта традиционная техника и проста, но она запутана, неэффектив-

на и ограничена.

Она запутана, потому что управление программой смешано с базой зна-

ний; новые факты и правила, включаемые в базу знаний, смешиватся с исход-

ным кодом программы. Это означает, что отсутствует разделение базы данных

и исходного кода ваших средств разработки (таких как пользовательский ин-

терфейс, вычисления коэффициентов доверия, графы правил и т.п.).

Она ограничена, потому что если вам требуется что-нибудь отличное от

обратной цепочки рассуждений в глубину, то традиционный Пролог не может

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

лючительно медленно, ее придется создавать с самого основания. Механизм

вывода традиционного языка Пролог не подходит для большинства практичес-

ких приложений (таких как экспертные системы), поэтому механизм вывода

должен быть смоделирован, как это и делается в Турбо Прологе. Однако, ме-

ханизм вывода, созданный на традиционном Прологе, окажется интерпретируе-

мым интерпретатором - выполняющим алгоритм, очень сильно зависящий от

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

Это годится для игрушечных приложений, имеющих небольшой програмный код и

не предъявляющих жестких требований к скорости выполнения, но совершенно

непригодно для реальных практических разработок.

Такой процесс включения базы знаний в исходный код неэффективен, по-

тому что вся оболочка (управляющий код и все остальное) проходит интерп-

ретацию, хотя интерпретировать надо только базу правил, содержащую конк-

ретные знания.