Comments 150
У пролога есть одна довольно значимая проблема. Сделать на нем какой либо интерфейс взаимодействия с пользователем тот еще цирк. Как итог его неплохо бы использовать на манер lua т.е. исключительно как встраиваемый язык. Я с ним имел дело довольно таки давно, как с этим сейчас?
В разных реализациях языка есть свои средства — встроенные предикаты для взаимодействия с внешней средой.
Можно сделать и по другому — сделать на ПРОЛОГе бbблиотеку или DLL.
Можно сделать и по другому — сделать на ПРОЛОГе бbблиотеку или DLL.
Можно сделать и по другому — сделать на ПРОЛОГе бbблиотеку или DLL.
Опять же получается в лыжах на асфальте. В этом и проблема. А на чистом прологе писать ПО мягко говоря не очень. Это кстати в свое время сильно ограничивало использование как его так и лиспа.
ПРОЛОГ — язык специализированный — для задач обработки символьной информации и искусственного интеллекта.
Иии? Что толку от него если я им не могу воспользоваться, а средства ввода-вывода убоги до нельзя?
Разве Вы в своей работе пользуетесь только одним языком программирования?
Внимательно читаем первый коммент. Я указываю проблему Prolog это интеграция. Из-за этого его использование в том числе в полезных целях весьма затруднено.
Может быть Вы не смотрели профессиональный ПРОЛОГ? Не вижу проблем с интеграцией.
Я указываю проблему Prolog это интеграция.
Не занимался интеграцией с прологом, но первое, что приходит в голову — это передача итоговых данных по TCP на localhost. И это не единственный способ.
Во всех реализациях ПРОЛОГа большое внимание уделяется средствам интеграции, есть несколько вариантов.
Например, в ARITY/PROLOG есть просто встроенный Си, не говоря уже о том, что можно компилировать ПРОЛОГ в obj — файл, DLL или EXE.
Например, в ARITY/PROLOG есть просто встроенный Си, не говоря уже о том, что можно компилировать ПРОЛОГ в obj — файл, DLL или EXE.
Это довольно заморочно. И в случае встроенный C это выворачивание на изнанку. По мне хорошо именно бы сделать наоборот, когда у меня есть императивный язык который используется для GUI и прочих абстракций, а когда мне нужнен prolog то я его вызываю оттуда. Все можно компилировать пролог в ddl или exe это сложный путь.
Ну опять же tcp для пролога тоже не очень нативный метод :)
Метафорой отвечу: А как на языке мат алгебры можно ввод вывод писать???
Языки предназначены для описания ограниченной предметной области.
Языки предназначены для описания ограниченной предметной области.
Сделать на нем какой либо интерфейс взаимодействия с пользователем тот еще цирк.
Есть Visual Prolog. Например, button::defaultAction :- Name = idc_ancestordialog_personname:getText(). В логической парадигме программирования нет присвоения переменных и вызовов функций, поэтому концептуально это можно перевести как «defaultAction истинно, когда Name совпадает с тем, что ввёл пользователь в окошко». Потом в каком-то месте программы утверждается, что defaultAction истинно (напомню, вызовов функций нет), и Prolog начинает искать все Name, которые совпадают с тем, что ввёл пользователь. Для этого у пользователя просят ввести данные. После этого считается, что Name определён. В общем-то да, GUI в логической парадигме немного запутаннее, чем в функциональной или объектно-ориентированной, но тем не менее, вполне осуществим.
Как итог имеем отдельную прослойку которая по сути императивна :) Я по этому и говорю, что более правильно prolog бы в виде встраиваемого языка использовать аля lua. В этом случае такой проблемы как работа с GUI нет :)
Ну да, пролог не для GUI. В программе, написанной на языке логического программирования, решение задачи часто ищется посредством хорошо оптимизированного брутфорса. Изначально это задумывалось как перебор математических фактов с целью доказательства теорем. Можно создать обычную прикладную программу на прологе, и она будет гораздо гибче и понятнее, чем программа из любой другой парадигмы, но будет она очень тормознутой — ибо брутфорс. Можно написать на прологе и быструю программу, но тогда нужно будет не просто описывать известные факты о системе, а как бы направлять ход выполнения программы, по сути возвращаясь к императивному программированию. Логическое программирование тем и ценно, что программист, например, описывает что такое ток, проводочки и диоды, задаёт максимальное количество элементов на микросхеме, и просит программу собрать ему синхрофазотрон. Без шуток, этот очень оптимизированный брутфорс творит чудеса, и Ватсон свидетель чудес его!
Вот вы пишете про лексический и синтаксический анализ на прологе. В чем его преимущества по сравнению с тем же ANTLR, особенно с учетом такого не слишком понятного синтаксиса?
Для понимания синтаксиса написана ч.1. ( habrahabr.ru/post/274603 )
Существует множество всяких систем построения синтаксических анализаторов — сравнивать со всеми не имею возможности.
Цель была — показать естественность операций, связанных с парсингом, в ПРОЛОГе, поскольку грамматика непосредственно отображается в язык.
Существует множество всяких систем построения синтаксических анализаторов — сравнивать со всеми не имею возможности.
Цель была — показать естественность операций, связанных с парсингом, в ПРОЛОГе, поскольку грамматика непосредственно отображается в язык.
Вы правда считаете это понятным языком?
(возможно, правда, дело не в языке, а в том, как написаны примеры, спорить не буду)
(возможно, правда, дело не в языке, а в том, как написаны примеры, спорить не буду)
согласен, все примеры можно было бы прогнать через highlighter
См ч.1
Там нет ответа на этот вопрос, либо я его не нашел. Можете привести цитату?
Цель первой части — описать Пролог с процедурной точки зрения, чтобы нетрудно было понять этот язык «обычному» программисту.
То, что вы где-то описали Пролог с процедурной точки зрения, не отвечает на мой вопрос, является ли Пролог сам по себе понятным языком.
Я считаю, да — является понятным языком. А Вы не можете прочесть (а не просто просмотреть) ч.1 и сказать свое впечатление по понятности описания языка?
Я же так и сделал. Код в этой (второй) статье понятнее не становится. Повторюсь, дело может быть не в языке, а конкретно в ваших примерах.
А Вы не можете задать конкретный вопрос — что именно непонятно?
Да далеко не ходить:
Из этой строчки понятно, что предикат
Интереса ради можно сравнить:
lexr(S,R):- list_text(L,S), delb(L,L1),lexr1(L1,R),!.Из этой строчки понятно, что предикат
lexr/2 последовательно вызывает три предиката: list_text/2, delb/2, lexr1/2. Это все, что из нее понятно. А еще в ней, на самом деле, происходит последовательное присвоение (не уверен, что это правильный термин, правда) результатов предикатов для их использования в следующем предикате.Интереса ради можно сравнить:
let lexer input =
let rec lexer input =
//очень грубый пример, просто чтобы показать матчинг и рекурсию
match input with
| [] -> []
| [h; t] -> [term(h); lexer(t)]
input
|> String.ToCharArray
|> Seq.filter (fun c -> c != ' ')
|> lexer
Сорри, задумался. Не
[term(h); lexer(t)], а term(h) :: lexer(t) lexr(S,R):- list_text(L,S), delb(L,L1),lexr1(L1,R),!..
list_text(L,S) — встроенный предикат, преобразует строку всписок кодов символов.
delb(L,L1) — удаление пробелов, описан ниже.
lexr1(L1,R) — основной предикат лексического анализа — описан ниже по тексту.
У Вас примерно такой же код по объему, только Вам он привычен.
list_text(L,S) — встроенный предикат, преобразует строку всписок кодов символов.
delb(L,L1) — удаление пробелов, описан ниже.
lexr1(L1,R) — основной предикат лексического анализа — описан ниже по тексту.
У Вас примерно такой же код по объему, только Вам он привычен.
Вопрос не объема, а понятности. Вам приходится описывать свой код словами, хотя можно было бы сделать его самоочевидным для всех, кто знает синтаксис языка.
предикат lexr/2 последовательно вызывает три предиката: list_text/2, delb/2, lexr1/2.
Эта фраза не совсем корректна, в логической парадигме нет понятия «вызов функции» или вызова чего бы то ни было. Точно также нет присвоения переменных.
Согласен, имена предикатов в данном случае малоинформативные.
Эта фраза не совсем корректна, в логической парадигме нет понятия «вызов функции» или вызова чего бы то ни было. Точно также нет присвоения переменных.
Да, я понимаю это, но опыта правильно это выразить мне не хватает.
К сожалению, сути это не меняет. Современные языки позволяют многое из того, что показывает автор, записать понятнее и очевиднее.
Давайте сделаем так — Вы напишете эквивалентные программы на HASKELL, потом сравним.
А почему именно на Хаскеле, которого я еще и не знаю?
(впрочем, пустой вопрос, я не уверен, что есть смысл это на любом языке делать: у вас выше спросили про разницу с ANTLR, вы от ответа ушли)
(впрочем, пустой вопрос, я не уверен, что есть смысл это на любом языке делать: у вас выше спросили про разницу с ANTLR, вы от ответа ушли)
Разве Ваши примеры:
let lexer input =
let rec lexer input =
//очень грубый пример, просто чтобы показать матчинг и рекурсию
match input with
| [] -> []
| [h; t] -> [term(h); lexer(t)]
не на этом языке приводятся?
Если это другой язык — можно на нем написать.
let lexer input =
let rec lexer input =
//очень грубый пример, просто чтобы показать матчинг и рекурсию
match input with
| [] -> []
| [h; t] -> [term(h); lexer(t)]
не на этом языке приводятся?
Если это другой язык — можно на нем написать.
Это f#
не на этом языке приводятся?
Нет, не на этом.
Если это другой язык — можно на нем написать.
На самом деле, весь ваш «лексер» сводится к:
let lexer = String.toCharArray >> Seq.filter (fun c -> c != ' ') >> Rx.window (fun c -> c |> Char.IsDigit |> not)
Где
Rx.window — это вполне типовая операция над последовательностями, которая превращает последовательность в последовательность последовательностей, разделяемых по условию.Это называется фичи. В ПРОЛОГе тоже можно заготовить всякие такие стандартные предикаты и гордо ими козырять. Написать настраиваемый лексический анализатор, как стандартный предикат недолго.
Вот сегодня только напечатали заметку, что происходит с языками, которые бесконечно расширяют встроенными процедурами.
Вы напишите всю программу с синтаксическим анализом, деревом и вычислением значения. И без готовых фич.
Вот сегодня только напечатали заметку, что происходит с языками, которые бесконечно расширяют встроенными процедурами.
Вы напишите всю программу с синтаксическим анализом, деревом и вычислением значения. И без готовых фич.
Нет, это называется «компонуемость». Я беру стандартную функцию, отвечающую за фильтрацию элементов в последовательности, присоединяю ее к стандартной же функции, отвечающей за разбиение последовательности по условию — и получаю, внезапно, лексер. А теперь, внимание, вопрос: насколько сложно добиться такой же компонуемости (особенно в части передачи предикатов внутрь других предикатов) в прологе?
Что тут обсуждать? ПРОЛОГ — полиморфный язык. Если очень хочется, в основной части языка есть стандартная операция call X, где X — переменная, которой можно динамически присваивать значение — любой предикат, точнее, цель.
Я Вам стремлюсь показать природу языка, а ВЫ говорите о фичах. Пишите фичи сколько хотите, потом еще можете сказать, что у Вы создали новый язык программирования, лучше ПРОЛОГа.
Я Вам стремлюсь показать природу языка, а ВЫ говорите о фичах. Пишите фичи сколько хотите, потом еще можете сказать, что у Вы создали новый язык программирования, лучше ПРОЛОГа.
Я Вам стремлюсь показать природу языка
Пока что вам это плохо удается. FiresShadow это удалось намного лучше.
а ВЫ говорите о фичах
Я не знаю, что вы понимаете под словом «фича», но, похоже, совсем не то, что я.
firesshadow дал хорошее описание в стиле «смотри как бывает!». Моя цель — «смотри как ты можешь сделать!»
А под словом «фича» я понимаю специализированные процедуры, встраиваемые в язык.
А под словом «фича» я понимаю специализированные процедуры, встраиваемые в язык.
Моя цель — «смотри как ты можешь сделать!»
… как я уже говорил, ваше «смотри» показывает мне вещи, которые я могу сделать на другом языке как минимум проще, и, скорее всего, лучше.
А под словом «фича» я понимаю специализированные процедуры, встраиваемые в язык.
Вот только в моем примере не было ничего, подходящего под это определение.
У меня еще возник вопрос — интерес к символьным языкам у Вас чисто академический или он связан с работой? Если Вы практически такими задачами заняты, может лучше Ваши задачи обсудить, точнее, способы их решения.
У меня любой интерес к языкам программирования связан с работой: я на каждый из них смотрю с точки зрения «есть ли у меня задачи, которые он решит эффективнее, чем тот инструментарий, которым я уже пользуюсь». В случае ваших статей о прологе ответ скорее «нет»; более того, для задач парсинга и интерпретации входного потока, если у меня возникнет такая необходимость, я явно возьму что-то другое.
Что я могу ответить, если не знаком с этой системой? Да и какая разница — ведь таких систем генерации полезных программ множество.
Что я могу ответить, если не знаком с этой системой?
Сравните с другими современными распространенными системами парсинга, не суть. Просто без такого сравнения — как вы можете говорить, что пролог чем-то лучше?
Мой тезис в том, что все системы парсинга основаны на использовании заготовленных библиотек соответствующих процедур, т.е. это просто парсеры с параметрами. Пользователь задает параметры и наслаждается результатом. Суть, природу языка демонстрируем, а не спорим, какой инструмент разработки лучше. Я показываю двигатель, а Вы мне — автомобиль.
Мой тезис в том, что все системы парсинга основаны на использовании заготовленных библиотек соответствующих процедур, т.е. это просто парсеры с параметрами. Пользователь задает параметры и наслаждается результатом.
И чем это отличается от Пролога? Тем, что «параметры» описываются в DCG?
Понимаете, это все — инструменты. У меня есть информационная система, типичный LOB, ввод данных и отчетики. И мне надо добавить в нее построение отчетов на основе SQL-подобного языка. Соответственно, мне нужно распарсить входную строку до AST. Я могу взять пролог и встроить его к себе, а могу взять antlr/lex+yacc/younameit и встроить их к себе. Для решения этой задачи пролог — всего лишь один из инструментов, совершенно одинаковый в ряду прочих, и их сравнение полностью оправдано.
Суть, природу языка демонстрируем
Вы меня извините, но демонстрировать природу языка из логической парадигмы на функциональной (с определенным входом и выходом) задаче — не самая хорошая идея.
Может Вам это и не надо — у Вас есть привычный набор инструментов. Предложите что-нибудь конструктивное.
А Вы не хотите подумать об интеллектуализации системы? Например, дать полную свободу в заказе отчетов пользователю. Насколько я знаю, в большинстве корпораций в отчетную пору пользователям требуется помощь программистов.
Уже подумали, отсюда и возникла задача «построение отчетов на основе SQL-подобного языка». Выражение для построения отчета пишет пользователь.
А пользователь должен его выучить? И консультироваться с программистами? А если сделать так, чтобы пользователю не требовались консультации и обучение?
А пользователь должен его выучить?
Да.
А если сделать так, чтобы пользователю не требовались консультации и обучение?
В общем случае это невозможно — по крайней мере, в разумной перспективе развития этой системы (3-5 лет).
Экспертные системы давно придумали.
И что? Для того, чтобы они давали нужный пользователю результат, ему (пользователю) все равно нужно обучиться работать с такой системой.
Хотел посоветовать Вам глубже изучить идею ЭС, но думаю пока это будет бесполезно, т.к. прошло слишком много лет с появления этой идеи и ее сильно исказили.
Ну вот видите, а вы говорите — давно придумали. Придумать-то придумали, да исказили, потому и взять прямо сейчас нечего.
Вы хотите готовый инструмент. А что-то подобное самому сочинить?
Я предпочитаю тратить свое свободное время на что-нибудь другое. А бюджет в проекте на это, предсказуемо, никто не даст.
Мне кажется, вы неявно предполагаете, что основная проблема пользователя — это выучить SQL-подобный (или любой другой) язык программировния, чтобы генерировать отчёты и тому подобное. Это ведь тоже довольно старая мысль: давайте вместо Pascal/Java/etc. дадим пользователю нечто вроде русского языка или вообще графические блоки, он будет соединять их стрелочками, и наступит всеобщее счастье.
Да вот практика показывает, что основная проблема не в языке, а в программистском способе мышления, которым необходимо овладеть, чтобы рисовать правильные стрелочки, так что всё равно определённый тренинг здесь необходим.
Я уж не говорю о том, что пользователь сам может убраться в офисе и приготовить обед, но смысла в этом мало: у пользователя своя работа, у повара своя, а у программиста своя, и лучше каждому делать то, в чём он лучше всего разбирается, и сотрудничать на всеобщее благо. В конце концов, за фразой «требуется консультация с программистом» не скрывается никакой особенной трагедии: открыл скайп и проконсультировался, всего-то дел.
Да вот практика показывает, что основная проблема не в языке, а в программистском способе мышления, которым необходимо овладеть, чтобы рисовать правильные стрелочки, так что всё равно определённый тренинг здесь необходим.
Я уж не говорю о том, что пользователь сам может убраться в офисе и приготовить обед, но смысла в этом мало: у пользователя своя работа, у повара своя, а у программиста своя, и лучше каждому делать то, в чём он лучше всего разбирается, и сотрудничать на всеобщее благо. В конце концов, за фразой «требуется консультация с программистом» не скрывается никакой особенной трагедии: открыл скайп и проконсультировался, всего-то дел.
Основная проблема программистов — в алгоритмическом мышлении. Почему-то они думают, что пользователь должен мыслить алгоритмически. Нет, конечный пользователь знает свою работу и не должен быть каким-то слабым программистом на упрощенном языке интерфейса, который ему дает программист. Пользователь должен описать свою проблему, а вот превратить ее в программу — задача программиста. Пользователь должен описывать ЧТО ему требуется, а программисты дают ему такие средства, что пользователь должен дополнительно учиться описывать не свою задачу, а способ ее решения, последовательность действий через интерфейс, предоставленный ему программистом.
Между пользователем и собственно программистом вы забываете постановщиков задачи, проектировщиков, архитекторов. Это их дело — выяснить, что пользователю нужно, и переложить в ТЗ для программиста.
Не согласен.
Проблема в том, что пользователь действительно должен, но не может описать свою проблему с достаточным количеством деталей для её решения.
Вы по сути повторяете вот эту старую мысль: проблема именно в сложности языков вроде Java или Pascal или C, а вот если бы пользователю дали писать на условном русском языке или рисовать диаграммы, то сразу бы рожь заколосилась и наступило бы всеобщее счастье.
В реальности (по крайней мере, так я понимаю из литературы и личного опыта) язык — это уже самый распоследний бастион. Человек неподготовленный в принципе мыслит неформально. Он может сказать, например, что ему нужно определить существование заданной карточки вида «Имя Фамилия» в базе данных. А когда даёшь ему то, что требовалось, оказывается, что «Нефёдов» и «Нефедов» нужно рассматривать как одно и то же, или что одинаковы строки «Иван Иванов» и «Иван <четыре пробела> Иванов», или «Иван» и «иван» — короче говоря, масса тонкостей, о которых люди не думают.
И не стоит ожидать, что люди будут аккуратны и строги в постановке задач. Человек, по складу ума склонный а такого рода рассуждениям, без проблем освоит на базовом уровне любой существующий несложный язык программирования.
Проблема в том, что пользователь действительно должен, но не может описать свою проблему с достаточным количеством деталей для её решения.
Вы по сути повторяете вот эту старую мысль: проблема именно в сложности языков вроде Java или Pascal или C, а вот если бы пользователю дали писать на условном русском языке или рисовать диаграммы, то сразу бы рожь заколосилась и наступило бы всеобщее счастье.
В реальности (по крайней мере, так я понимаю из литературы и личного опыта) язык — это уже самый распоследний бастион. Человек неподготовленный в принципе мыслит неформально. Он может сказать, например, что ему нужно определить существование заданной карточки вида «Имя Фамилия» в базе данных. А когда даёшь ему то, что требовалось, оказывается, что «Нефёдов» и «Нефедов» нужно рассматривать как одно и то же, или что одинаковы строки «Иван Иванов» и «Иван <четыре пробела> Иванов», или «Иван» и «иван» — короче говоря, масса тонкостей, о которых люди не думают.
И не стоит ожидать, что люди будут аккуратны и строги в постановке задач. Человек, по складу ума склонный а такого рода рассуждениям, без проблем освоит на базовом уровне любой существующий несложный язык программирования.
Современные языки позволяют многое из того, что показывает автор, записать понятнее и очевиднее.
Просто потому что автор избрал не ту тактику :) Он вместо того, чтобы показать задачи, под кооторые Пролог «заточен», показывает решение привычных в императивной парадигме вещей. Но посколькку они императивны, то в Прологе выглядят плохо. Только и всего.
Тут немедленно возникает разумный вопрос: под какие же задачи пролог заточен?
На мой взгляд — проверка набора фактов. Это его основа. Вы можете сделать это императивно, но на Прологе это выглядит еще и понятно.
Тут немедленно возникает разумный вопрос: под какие же задачи пролог заточен?Вот этот комментарий частично отвечает на ваш вопрос. Пример автоматического доказательства теоремы можете посмотреть в этой статье, я тоже на эту тему писал.
В ПРОЛОГе точно также можно заготовить всякие типовые процедуры, а затем вызывать их в две строки.
ПРОЛОГ предназначен для работы с символьной информацией и для решения задач, требующих логического вывода.
Заготовить процедуры на все случаи жизни — это делает любой программист и не надо называть это «заточенностью.»
ПРОЛОГ предназначен для работы с символьной информацией и для решения задач, требующих логического вывода.
Заготовить процедуры на все случаи жизни — это делает любой программист и не надо называть это «заточенностью.»
Заготовленные процедуры здесь ни при чем. Пролог позволяет нам проверить набор фактов — это его задача, для этого язык создан. То, что мы можем, используя императивную сущность пролог-машины и отсечение, делать императивные вещи — отдельный разговор.
Вы можете написать на html/css (чисто декларативном языке) игру, которая будет интерактивной. Потому что браузер, интерпретирующий html и css, императивен внутри. Это не отменяет того, что html — язык разметки, он под это «заточен».
Вы можете написать на html/css (чисто декларативном языке) игру, которая будет интерактивной. Потому что браузер, интерпретирующий html и css, императивен внутри. Это не отменяет того, что html — язык разметки, он под это «заточен».
А еще в ней, на самом деле, происходит последовательное присвоение (не уверен, что это правильный термин, правда) результатов предикатов для их использования в следующем предикате
Это издержки императивности реализации. Правильный термин — подстановка ЕМНИП.
Зачем описывать Пролог с процедурной точки зрения, если у него совершенно другая вычислительная модель и он решает совершенно другие задачи? Тем более, что сам язык объективно мертв по очень простой причине — реализовать прологовскую модель вычислений (а точнее целое семейство алгоритмов родившихся из нее) под конкретную задачу на любом современном императивном/функциональном проще чем пытаться родить на прологе то для чего он не предназначен.
Во всех учебниках ПРОЛОГ описывается с двух точек зрения — декларативной парадигмы и процедурной.
Но декларативная (или логическая) семантика не полностью реализована в языке и только затуманивает понимание языка, если мы хотим на нем делать реальные программы.
Но декларативная (или логическая) семантика не полностью реализована в языке и только затуманивает понимание языка, если мы хотим на нем делать реальные программы.
Правильно. Но пролог ценен только своей декларативной частью. Все остальное — набор ужасных и устаревших костылей нужных как раз для того, чтобы на прологе можно было решать не только узкий набор задач. Вопрос остается тот же — зачем мучатся с прологовскими костылями, если ценная его часть элементарно реализуется под конкретную задачу в любом современном языке?
Если куски ПРОЛОГа вставляют в эти необъятные монстры — нагромождения бесконечного количества библиотек, называемые современными языками программирования, то чем тут гордиться?
Вам показывают суть парадигмы логического программирования, а стандартные процедуры есть в каждой реализации — можете на них посмотреть, если хочется.
Вам показывают суть парадигмы логического программирования, а стандартные процедуры есть в каждой реализации — можете на них посмотреть, если хочется.
Причем здесь стандартные процедуры?
Плохо понимаю причем тут нагромождения библиотек и как они связаны с языками программирования.
Суть мне показывать не надо, я когда-то изучал пролог, переизобрел его когда игрался с написанием парсера команд на «естественном языке», написал еще один логический движок для решения задачи планирования действий агентов (потому что типовой прологовский «решатель» задачу не решал в силу определенных ограничений). Тем более что вы почему-то показываете логическую парадигму на чисто функциональной задаче от чего у людей и взрывается мозг.
Плохо понимаю причем тут нагромождения библиотек и как они связаны с языками программирования.
Суть мне показывать не надо, я когда-то изучал пролог, переизобрел его когда игрался с написанием парсера команд на «естественном языке», написал еще один логический движок для решения задачи планирования действий агентов (потому что типовой прологовский «решатель» задачу не решал в силу определенных ограничений). Тем более что вы почему-то показываете логическую парадигму на чисто функциональной задаче от чего у людей и взрывается мозг.
Как-то вы себе противоречите. В комментах к первой части это же ваша реплика: «Пора уже понять, что процедурный подход в программировании — временное явление. Все модные языки — это сдача позиций перед неизбежностью декларативности символьных структур.»
И я как раз соглашусь с новым комментарием — в том и беда, что декларативность в Прологе только декларируется (каламбур-с), а на самом деле приходится всё равно размышлять над тем, как машинка под капотом все эти факты и правила будет обрабатывать. То есть скрытая императивность.
По мне так явное лучше скрытого. Явная императивность лучше скрытой императивности. Явную декларативность будем обсуждать тогда, когда она появится.
И я как раз соглашусь с новым комментарием — в том и беда, что декларативность в Прологе только декларируется (каламбур-с), а на самом деле приходится всё равно размышлять над тем, как машинка под капотом все эти факты и правила будет обрабатывать. То есть скрытая императивность.
По мне так явное лучше скрытого. Явная императивность лучше скрытой императивности. Явную декларативность будем обсуждать тогда, когда она появится.
То есть скрытая императивность.
В случае, если мы пишем что-то императивное и пользуемся императивностью самой Пролог-машины. Т.е. используем инструмент в чужой среде.
Я немного о другом. Декларативность — это когда (как нам пытаются объяснить книжки по декларативному программированию) мы описываем какие-то соотношения между элементами предметной области, а компьютер «сам» выводит ответы на интересующие нас запросы.
В действительности же чистой декларативности нет нигде, потому что две одинаковые (декларативно) программы могут в реальности вести себя совершенно по-разному. Это, собственно, во всех нормальных учебниках сообщается открытым текстом.
Вопрос в том, насколько такая декларативность лучше императивности. Для этого инструмента в принципе не существует «своей» среды, потому что если я просто буду представлять в голове соотношения между символами и записывать их в виде логических формул, ничего хорошего не выйдет: я именно что обязан думать о том, как все эти соотношения будет императивно обрабатывать компьютер. То есть я бы и рад не использовать инструмент в чужой среде, но меня заставляют.
В действительности же чистой декларативности нет нигде, потому что две одинаковые (декларативно) программы могут в реальности вести себя совершенно по-разному. Это, собственно, во всех нормальных учебниках сообщается открытым текстом.
Вопрос в том, насколько такая декларативность лучше императивности. Для этого инструмента в принципе не существует «своей» среды, потому что если я просто буду представлять в голове соотношения между символами и записывать их в виде логических формул, ничего хорошего не выйдет: я именно что обязан думать о том, как все эти соотношения будет императивно обрабатывать компьютер. То есть я бы и рад не использовать инструмент в чужой среде, но меня заставляют.
В действительности же чистой декларативности нет нигде, потому что две одинаковые (декларативно) программы могут в реальности вести себя совершенно по-разному
Нет, вы не о другом, а ровно о том же: декларативную программу выполняет императивная машина. Начиная от пролог-машины в данном случае и заканчивая собственно ЦП. Чисто декларативными с этой точки зрения можно условно назвать аналоговые компьютеры, в которых задается перемычками схема.
Нет, я всё-таки о другом. Мне абсолютно всё равно, какое оборудование выполняет мою программу, речь именно о том, что мне как программисту приходится об этом думать.
Если же вы хотите сказать, что декларативное программирование доступно на декларативной машине, императивное — на императивной, а макаронное — на макаронной, что ж, трудно не согласиться, но это же пустой разговор. Других машин в обозримом будущем не предвидится.
Если же вы хотите сказать, что декларативное программирование доступно на декларативной машине, императивное — на императивной, а макаронное — на макаронной, что ж, трудно не согласиться, но это же пустой разговор. Других машин в обозримом будущем не предвидится.
Обработка данных не происходит мгновенно. Между вводом данных и выводом результата всегда проходит какое-то время.
Обработка данных не происходит сама по себе. Для получения результата из входных данных нужно совершить некоторые действия.
Соответственно, некоторые действия будут выполнены раньше по времени, некоторые позже.
Описание может быть декларативным, выполнение — нет.
В аналоговых устройствах тоже есть задержка на распространение и преобразование сигнала. Если взять 2 рации, то звук из второй появится не одновременно с тем, как мы скажем что-то в первую. При проектировании устройств учитывается направление и движение тока.
Обработка данных не происходит сама по себе. Для получения результата из входных данных нужно совершить некоторые действия.
Соответственно, некоторые действия будут выполнены раньше по времени, некоторые позже.
Описание может быть декларативным, выполнение — нет.
В аналоговых устройствах тоже есть задержка на распространение и преобразование сигнала. Если взять 2 рации, то звук из второй появится не одновременно с тем, как мы скажем что-то в первую. При проектировании устройств учитывается направление и движение тока.
А дождь падает с неба на землю. К чему трюизмы?
Про распространение сигнала — вы немного уходите не в ту степь. Да, задержка есть, но это не сравнимо с итеративным подходом. Для выполнения двух действий на итеративной машине мы всегда сначала выполним одно, затем другое. То, что они могут занимать разное время — про это я не говорю. В аналоговой системе если вы подключите к источнику сигнала 2 одинаковых блока (не реальных, а идеалистичных), то сигнал до них дойдет одновременно и обрабатывать они его будут одновременно. Это не отменяет задержек, но я по-русски написал «условно». Можно было говорить о многоядерной системе и параллельных вычислениях, или просто комбинационных схемах.
Про распространение сигнала — вы немного уходите не в ту степь. Да, задержка есть, но это не сравнимо с итеративным подходом. Для выполнения двух действий на итеративной машине мы всегда сначала выполним одно, затем другое. То, что они могут занимать разное время — про это я не говорю. В аналоговой системе если вы подключите к источнику сигнала 2 одинаковых блока (не реальных, а идеалистичных), то сигнал до них дойдет одновременно и обрабатывать они его будут одновременно. Это не отменяет задержек, но я по-русски написал «условно». Можно было говорить о многоядерной системе и параллельных вычислениях, или просто комбинационных схемах.
Зачем эти спекуляции на тему декларативности? Если Вы внимательно прочитали текст — моя цель показать две вещи:
— в ПРОЛОГе нет ничего сверхсложного и всякий программист может его применять:
— есть задачи задачи, которые на ПРОЛОГе делать лучше, чем в императивном языке.
— в ПРОЛОГе нет ничего сверхсложного и всякий программист может его применять:
— есть задачи задачи, которые на ПРОЛОГе делать лучше, чем в императивном языке.
Я написал лозунг, тенденцию развития. Конечно, нынешний ПРОЛОГ не обеспечивает декларативность и его логическая семантика работает только на простых примерах.
Как раз я показываю его явную императивность.
То, что во все модные языки вставляют средства работы со списками, говорит о неизбежности декларативного подхода, а не то что сейчас он доступен.
Появление языка Хаскел демонстрирует стремление обеспечить хотя бы декларативность на уровне статического контроля типов.
Как раз я показываю его явную императивность.
То, что во все модные языки вставляют средства работы со списками, говорит о неизбежности декларативного подхода, а не то что сейчас он доступен.
Появление языка Хаскел демонстрирует стремление обеспечить хотя бы декларативность на уровне статического контроля типов.
По правде говоря, я не вижу тенденции. Как некий способ программирования — конечно, да, а откуда тенденция?
Также я не вижу связи между списками и декларативным подходом. Список — это просто структура данных, такая же как массив или стек. Что в ней декларативного?
Также я не вижу связи между списками и декларативным подходом. Список — это просто структура данных, такая же как массив или стек. Что в ней декларативного?
Тенденция, конечно не так заметна на отрезке за 10 лет, надо смотреть дальше. То что корпорации выбрасывают на рынок все новые и новые специализированные инструменты — это стремление решить принципиальные проблемы программирования экстенсивным путем.
По поводу декларативности списка — это конечно неявно, список — более абстрактное понятие, чем массив или файл, поскольку его размерность и структура не регламентируется, а рекурсивность понятия список тоже более абстрактная, чем массив.
Вряд ли Вы со мной согласитесь — это мои оценки.
По поводу декларативности списка — это конечно неявно, список — более абстрактное понятие, чем массив или файл, поскольку его размерность и структура не регламентируется, а рекурсивность понятия список тоже более абстрактная, чем массив.
Вряд ли Вы со мной согласитесь — это мои оценки.
Даже если я не соглашусь, мне интересно, как вы выводите эту тенденцию. Скажем, в C++ списки существуют со стандарта 1998 года официально, в Java примерно с того же времени. Специализированные инструменты тоже выбрасывались столько, сколько себя помню (ещё в вузе делали курсовики с помощью Silverrun — это CASE средство для разработки баз данных, тогда была особенно модная тема).
То, что во все модные языки вставляют средства работы со списками, говорит о неизбежности декларативного подхода
Нет, это говорит об удобстве функциональной парадигмы. Нет никакой связи между (функциональными) списками и декларативностью.
(не говоря уже о том, что неплохо бы подтвердить утверждение «во все модные языки вставляют средства работы со списками» — лично я ему не верю, например)
Он вполне понятен, но надо погрузиться в тему. Плюс там та же проблема что и с функциональными языками, придется вывернуть мышление.
Попробуйте почитать ч.1.
Конечно, еще лучше было бы с интерпретатором ПРОЛОГа сразу прогонять примеры.
Конечно, еще лучше было бы с интерпретатором ПРОЛОГа сразу прогонять примеры.
Мне то зачем? У нас целый курс в универе по нему был.
> В третьей части рассмотрим применение Пролога для построения одного типа интеллектуальных систем — экспертных систем.
Ждем описание методов редукции дерева решений.
Ждем описание методов редукции дерева решений.
А я хочу сказать Вам спасибо за Ваши статьи — они меня сподвигли начать изучать Prolog (что было в моём списке дел уже полгода). Читая руководство по языку никак не мог понять вообще о чём речь (какие-то предикаты, атомы, арность). Поискал в Google «Prolog tutorial» и уже смог сделать простейшую программу.
Язык очень интересный, на первый взгляд человека с плохой математической подготовкой напоминает навороченную булеву алгебру. Буду копать дальше, возможно, применю его где-то на практике.
P.S. Если вы пытаетесь писать код в интерпретаторе и всё время получаете «uncaught exception: error...», то сохраните ваш код в файл, а затем импортируйте его командой consult или вот так: [«1.pl»].
Насколько я понял, ошибка выскакивает (в GNU Prolog, yap и SWI Prolog) из-за того, что в интерпретаторе нельзя объявлять свои предикаты (что лично мне кажется неудобным маразмом).
Язык очень интересный, на первый взгляд человека с плохой математической подготовкой напоминает навороченную булеву алгебру. Буду копать дальше, возможно, применю его где-то на практике.
P.S. Если вы пытаетесь писать код в интерпретаторе и всё время получаете «uncaught exception: error...», то сохраните ваш код в файл, а затем импортируйте его командой consult или вот так: [«1.pl»].
Насколько я понял, ошибка выскакивает (в GNU Prolog, yap и SWI Prolog) из-за того, что в интерпретаторе нельзя объявлять свои предикаты (что лично мне кажется неудобным маразмом).
никак не мог понять вообще о чём речь (какие-то предикаты, атомы, арность
Ищите «дизъюнкт Хорна» и «метод резолюций».
напоминает навороченную булеву алгебру
Ну… какбэ это оно и есть. Точнее, можно так условно сказать.
Не надо ни Хорна ни дизъюнктов! Специально написал эти статьи, чтобы показать, как работать с ПРОЛОГом без всей этой математической терминологии. Она нужна теоретикам, программистам она никак не помогает!
Надо Хорна и метод резолюций. Без этого не понять, что это за язык и как он работает.
Вы же видите — это только порождает вопросы«на фига козе баян» зачем нужен Пролог. Если бы вы начали с теории, было бы ясно.
Глупость. Это элементарные понятия, и не зная их, в Пролог соваться незачем.
Специально написал эти статьи, чтобы показать, как работать с ПРОЛОГом без всей этой математической терминологии
Вы же видите — это только порождает вопросы
Она нужна теоретикам, программистам она никак не помогает!
Глупость. Это элементарные понятия, и не зная их, в Пролог соваться незачем.
Всякое утверждение должно быть обосновано. Свое утверждение о ненужности дизъюнктов и понятия клауз Хорна я обосновываю этой публикацией.
А Вы чем обосновываете свое утверждение? Тем что все учебники по ПРОЛОГу забиты этой терминологией, не так ли?
А Вы чем обосновываете свое утверждение? Тем что все учебники по ПРОЛОГу забиты этой терминологией, не так ли?
Свое утверждение о ненужности дизъюнктов и понятия клауз Хорна я обосновываю этой публикацией.
Нет, эта публикация не является обоснованием ненужности теории.
Ваша публикация показывает, как делать на Прологе императивные штуки. Только и всего. И сразу возникают вопросы — посмотрите сами — а зачем извращаться, если можно императивные вещи делать на императивном языке. Вы не разъясняете, чем крут язык, и насколько он прост, вы запутываете.
А Вы чем обосновываете свое утверждение? Тем что все учебники по ПРОЛОГу забиты этой терминологией, не так ли?
Нет. Тем, что понимая принцип резолюций и дизъюнктов Хорна, суть Пролога объясняется в 2 строчки. Без кучи статей.
Потом 1 пример решения простой задачи и человек все понял.
Мое утверждение основано на личном опыте разъяснения другим, что такое Пролог.
А в понимании языка эти две статьи Вам не помогли? Задайте конкретные вопросы.
В режиме интерпретации можно определять предикаты, загружая в память командой assert/1, но правильнее, конечно, записывать их в текстовый файл, потом делать reconsult.
В режиме интерпретации можно определять предикаты, загружая в память командой assert/1, но правильнее, конечно, записывать их в текстовый файл, потом делать reconsult.
В сто раз больше, чем обе статьи, сделает один крохотный пример решения логической задачи на Прологе. Когда нам в свое время читали курс по Прологу, после изучения мат. теории и одного примера решения логической головоломки, все было понятно.
Я перестал понимать Вашу статью вот в этом месте
И до сих пор не понимаю как [H|T] может быть связано с произвольным непустым списком. Я до списков ещё не дошёл.
Честно говоря, для меня кривая вхождения Вашей статьи оказалась слишком крутой.
Когда начал смотреть самые простые туториалы, то понял, что Prolog просто инопланетный ЯП для человека с традиционным бэкграундом. Здесь всё настолько по-другому, что я не могу сравнивать Prolog ни с одним ЯП, о которых я хоть что-то знаю (а это десятка 2, не меньше).
Попробую перечислить свои основные открытия на данный момент.
1) Если имя начинается с большой буквы, то это переменная, если с маленькой, то это атом. Такое жёсткое вмешательство в именование очень непривычно.
2) Точка обозначает конец правила
3) Если описываем комплексное правило, состоящее из нескольких предикатов, то разделение их запятой играет роль логического И, а точкой — логического ИЛИ.
4) Перемена мест параметров в факте имеет значение
а в третьем как [H|T] – произвольный непустой список.
И до сих пор не понимаю как [H|T] может быть связано с произвольным непустым списком. Я до списков ещё не дошёл.
Честно говоря, для меня кривая вхождения Вашей статьи оказалась слишком крутой.
Когда начал смотреть самые простые туториалы, то понял, что Prolog просто инопланетный ЯП для человека с традиционным бэкграундом. Здесь всё настолько по-другому, что я не могу сравнивать Prolog ни с одним ЯП, о которых я хоть что-то знаю (а это десятка 2, не меньше).
Попробую перечислить свои основные открытия на данный момент.
1) Если имя начинается с большой буквы, то это переменная, если с маленькой, то это атом. Такое жёсткое вмешательство в именование очень непривычно.
2) Точка обозначает конец правила
3) Если описываем комплексное правило, состоящее из нескольких предикатов, то разделение их запятой играет роль логического И, а точкой — логического ИЛИ.
4) Перемена мест параметров в факте имеет значение
В начале есть ключевая фраза: «Представьте программу, которая состоит только из вызовов процедур, а каждая процедура имеет несколько реализаций»
И до сих пор не понимаю как [H|T] может быть связано с произвольным непустым списком. Я до списков ещё не дошёл.
Это просто стандартное описание списка. Такой синтаксис. Если там [], то машина будет подставлять пустой список, если там [H|T] то непустой, разделяя голову H и остальное тело T. В ходе работы пролог машина будет пытаться подставлять (унифицировать) параметры. Такая запись говорит о том, что предикат применим для непустого списка, его можно подставить.
Например:
domains
list=integer* /* Тип элемента списка - integer*/
predicates
sum_list(integer, list)
sum_list(integer, integer, list)
clauses
sum_list(Summa, L) :- sum_list(Summa, 1, L). /* public */
sum_list(0, Nom_el, []). /* граничный случай*/
/* суммируем с нечетным элементом, иначе - отсечение */
sum_list(Summa, Nom_el, [H|T]) :- Nom_el mod 2 <> 0,
!,
Nom_el_sub = Nom_el + 1,
sum_list(PodSumma, Nom_el_sub, T),
Summa = PodSumma + H.
/* альтернатива - для четного элемента */
sum_list(Summa, Nom_el, [H|T]) :- Nom_el_sub = Nom_el + 1,
sum_list(Summa, Nom_el_sub, T).
goal
L=[2,4,3,1,7,2,4],
sum_list(S,L),
write("Summa = ",S).
Вот этот предикат:
sum_list(0, Nom_el, []).
Применим только если мы пытаемся в третий элемент подставить пустой список, при этом «результатом» будет 0, а вот этот:
/* суммируем с нечетным элементом, иначе — отсечение */
sum_list(Summa, Nom_el, [H|T]) :- Nom_el mod 2 <> 0,
!,
Nom_el_sub = Nom_el + 1,
sum_list(PodSumma, Nom_el_sub, T),
Summa = PodSumma + H
применим для любых непустых списков.
[H|T] — одно из ключевых выражений в языке ПРОЛОГ.
Дело в том, что в нем усложнены такие вещи как переменная и присваивание.
Вместо присваивания применяется унификация — аналог подстановки параметров при вызове процедуры.
В ПРОЛОГе Вы можете использовать вместо «обычной» переменной некую конструкцию из нескольких переменных, по сути — это паттерн, задающий ограничения на фактический параметр.
[H|T] — это две переменные, из которых первая — Н не имеет ограничений, а вторая -Т должна быть списком.
Если в режиме интерпретации Вы введете, например такое выражение:
[a,b,c,d] = [H|T]
то система выдаст:
H=a,
T=[b,c,d]
Применение [H|T] означает следующее:
— в данную позицию можно подставить только непустой список (содержащий не менее одного элемента);
— после выполнения унификации со списком H будет ссылаться на головной элемент подставленного списка, а T — на хвост этого списка.
Дело в том, что в нем усложнены такие вещи как переменная и присваивание.
Вместо присваивания применяется унификация — аналог подстановки параметров при вызове процедуры.
В ПРОЛОГе Вы можете использовать вместо «обычной» переменной некую конструкцию из нескольких переменных, по сути — это паттерн, задающий ограничения на фактический параметр.
[H|T] — это две переменные, из которых первая — Н не имеет ограничений, а вторая -Т должна быть списком.
Если в режиме интерпретации Вы введете, например такое выражение:
[a,b,c,d] = [H|T]
то система выдаст:
H=a,
T=[b,c,d]
Применение [H|T] означает следующее:
— в данную позицию можно подставить только непустой список (содержащий не менее одного элемента);
— после выполнения унификации со списком H будет ссылаться на головной элемент подставленного списка, а T — на хвост этого списка.
Пожалуйста, пишите ещё статьи про Пролог. Язык этот очень интересный (и нестандартный для программиста, который в работе чаще сталкивается с мейнстримными языками), и с этим связано неоднозначное отношение сообщества к вашим публикациям (и — особенно — комментариям).
Пишите ещё, многим такие вещи очень интересны!
Пишите ещё, многим такие вещи очень интересны!
Я буду продолжать. Следующая статья будет о применении ПРОЛОГа в искусственном интеллекте.
А Вы задавайте больше конкретных вопросов по тексту, пожалуйста.
Очень много любителей глобальных тем.
А Вы задавайте больше конкретных вопросов по тексту, пожалуйста.
Очень много любителей глобальных тем.
Это уже интереснее и куда ближе к «духу» Пролога. Жду с нетерпением.
Напишите, если не сложно конкретный сеанс работы. Как скачать, установить, скомпилировать, запустить простейшую программу уровня hello,world на prolog.
Sign up to leave a comment.
Парсинг на языке Prolog