nedoPC.org

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

К примеру прологовские факты легко ложатся на Hope:
dec student : string -> bool;
--- student("Коля") <= true;
--- student("Петя") <= true;
--- student("Вася") <= true;
или даже так:
data student == Kolya ++ Petya ++ Vasya;

А вот процедуры унификации и откатов придётся запрограммировать, т.к. в функциональщине ничего подобного нету...

Вобщем я готов отказаться от проекта Funny в пользу Hopelog-a. Всё равно к синтаксису Hope я уже привык...

Хотелось бы заполучить компилятор в байт-код и простой интерпретатор этого байткода - соответственно надо иметь чёткое описание форматов и интерфейсов - чтобы интерпретатор мог быть написан на любом языке за разумное время. Также предполагается наличие совместимости бинарных сборок старых версий с новыми - типа как в Java.

Интересно, а чем, кроме синтаксиса, будет отличаться Hopelog от Prolog? Наличием функций? Можно объяснить на примере синтаксиса Prolog-а?

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

из мыслей про байт-код - это просто сериализованные структуры будут - тегированный поток блоков - если старая реализация получает поток с новыми блоками, то она может отработать нормально - если например вычисления до нового блока так и не дошли (например if(a) then old_block else new_block и a получился true)

может быть в памяти прямо по этой сериализации и вычисляться - без десериализации дерева объектов

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

примерный формат блоков - заголовок:
0) 'H' - сигнатура (3 байта "HL1")
1) 'L'
2) '1'
3) T - таг блока (1 байт)
4) SZ - размер блока (4 байта)
5)
6)
7)
далее идёт сам блок данных

все данные выровнены на 4 байта (32 бита)

блоки могут быть вложенными (например если таг >= 0x80, то блок представляет из себя контейнер для других блоков)

внутренности блоков могут ссылаться на далее идущие блоки путём использования смещений в байтах (ссылка - ref)

Примерный набор тегов:

0x00 - ref (ссылка) - 4 байта : смещение
0x01 - atom (атом) - 4 байта : уникальный идентификатор атома
0x02 - char (символ) - 1 байт : код символа, далее 3 байта нулей
0x03 - num (целое число со знаком) - 4 байта : значение числа
0x04 - real (число с плавающей точкой) - 8 байт : значение числа

0x10 - vector (вектор, состоящий из однотипных элементов) - 1 байт : тип, 3 байта : количество элементов, далее элементы
0x11 - list (список) - 4 байта : ссылка на голову, 4 байта : ссылка на хвост

0x80 - program (программа) - далее идут другие тегированные блоки
0x81 - module (модуль) - далее идут другие тегированные блоки

и т.д.

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

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

Так строгая типизация и интерфейсы к другим языкам/из других языков уже были в Turbo Prolog, затем перешли в PDC Prolog, а ныне в Visual Prolog (на котором кстати много пришлось программировать).

Пролог сам по себе покрывает только очень узкий класс последовательно-переборных задач, особенно в виде "Visual Prolog", который уже является чем-то иным нежели просто прологом (например стандартные прологовские программы на нём не пойдут - их придётся переписывать) - и кстати это "проприетарная" софтина, которая даёт ей попользоваться бесплатно только для ознакомления или для личного использования, а моя цель - GPL софтина для всех

P.S. Я турбо-прлогом пользовался активно когда в институте учился в середине 90-х - русифицировал его Help, курсовые писал на нём (для себя и для других - самый крупный был в 1300 строк), лабы делал и т.д. Потом (уже в аспирантуре) перешёл на Amzi!, а затем (уже в Америке) - чисто для себя на gprolog...

Visual Prolog'ом нас пичкали в институте, как и Amzi! прологом.
А вот для себя пользовался SWI и GNU прологами.
Сейчас потихоньку колдую над своим диалектом - "нечеткий" пролог, на основе исчисления истинностей.

я в SWI ещё ни разу не ходил - он лучше/хуже чем gprolog?



а это уже интересно - есть где почитать?

P.S. я тут некоторое время назад ломал голову над троичным прологом

В принципе все такое же, но, в отличии от gprolog в SWI есть человеческий API для GUI.


У меня сканы книг Дюбуа и Прада по нечеткой логике, советующим системам, потом книжки японцев по применению и исследованию нечеткой логики. В электронном виде книги, к сожалению, не искал - еще в институтское время заказывал их по почте. Ну и фундаментальные труды того же Заде.

Решил для начала попробовать сделать интерпретатор гибрида Hope+Prolog на языке JavaScript - входными данными для интерпретатора будут не текст программы или байт-код, а некая иерархическая структура в виде родной для джава-скрипта JSON-нотации. На верхнем уровне это будет массив, состоящий из объектов, описывающих определения типов данных и функции языка Hope, которые внутри будут также представлять из себя иерархические структуры вложенных объектов.

Возможная структура объекта:

{
"T":M, // где M - тип объекта
"O":тело-объекта // может быть null, число, массив, объект
}

Возможные значения типа:
0 - nothing
1 - use (подключение модуля): массив строк
2 - library (список атомов, использованных в коде): массив строк
3 - data (определение нового типа данных): массив объектов
4 - call (вызов функции): массив объектов
5 - dec (определение функции): объект с полями A (число) и D (массив объектов)
6 - special (специальные команды): строка
7 - lambda (определение безымянной функции): массив из двух элементов
8 - if/then/else: массив из трёх элементов
9 - let/in и where (а также letrec и whererec): массив из трёх элементов
10 - type (тип): число - идентификатор атома
11 - cons (простой конструктор): идентификатор атома
12 - cons(...) (сложный конструктор): объект с полями A (число) и O (объект)
13 - tuple (набор элементов): массив объектов
14 - num (число): число
15 - char (буква): число - код символа

Попробуем скомпилировать пример отсюда: http://www.soi.city.ac.uk/~ross/Hope/ho ... ode18.html



может быть сконвертирован вот в такой JSON:



команду 6-special можно использовать например для указания версии языка {"T":6,O:"hopelog=1.0"} или для отделения публичной части модуля от приватной {"T":6,O:"private"}