Англійська для розробників Prolog

Prolog вимагає справді іншого способу опису того, що робить код: ви не описуєте кроки, ви описуєте факти і правила, і дозволяєте рушію шукати рішення. Команди, які не знають логічного програмування, часто досягають імперативного словника, який насправді не відповідає тому, що відбувається, і саме тут починається плутанина.

Ключовий словник

** Об’ єднання ** — основний механізм, за допомогою якого Prolog порівнює запит з фактами і правилами, прив’ язуючи змінні до значень, щоб обидві сторони стали ідентичними, що ближче до збігу з шаблоном з прив’ язкою, ніж до призначення або перевірки рівності. “Це не призначення — коли запит об’єднується з фактом, X прив’язується до alice як побічна реакція успішного об’єднання, і це прив’язування зберігається для решти поточної гілки пошуку.”

** Backtracking ** — автоматичний процес Prolog, який скасовує прив’ язки змінних і намагається знайти наступну альтернативу, коли мета зазнає невдачі або коли вимагається більше рішень, це вбудована стратегія пошуку рушія, а не щось, що автор програми повинен реалізувати.

• “Вам не потрібен цикл, щоб знайти кожного відповідного батька — просто запитайте запит ще раз, щоб отримати більше рішень, і зворотній пошук автоматично повторить спроби пошуку альтернативних фактів і правил, поки їх не залишиться жодних.” *

** Cut ( ! ) ** — оператор, який зобов’ язує Prolog до вибору, зробленого дотепер у поточній клаузі, обрізаючи точки зворотнього шляху, які інакше було б спробовано, використовується для керування швидкістю і поведінкою пошуку, але має погану славу за те, що робить правила важчими для розуміння, якщо їх використовувати занадто часто. “Додавання тут розрізу після першого відповідного випадку запобігає тому, щоб Prolog марнував час на пошук альтернатив, про які ми вже знаємо, що ми їх не хочемо — але будьте обережні, оскільки це також тихо змінює те, які рішення може дати цей предикат.”

** Предикат ** — фундаментальна одиниця логіки Prolog, назва плюс набір фактів і/ або правил, що визначають відношення, приблизно аналогічне функції, але описує відношення, яке можна запитати у декількох напрямках, а не обчислювати одним способом. “Це предикат не є « функцією, яка обчислює предка » — це відносина, отже ви можете задати запит на нього уперед, щоб знайти чиїсь предки, або узад, щоб знайти їхніх нащадків, використовуючи точно те саме визначення предиката. ”

** Припущення закритого світу ** — Типове правило розумового міркування Prolog, що все, що не можна довести з відомих фактів і правил, розглядається як хибне, а не невідоме, фундаментальне припущення, яке формує те, як заперечення і відсутні дані поводяться в мові. “Запит зазнав невдачі не тому, що ми довели факт хибним, а через припущення закритого світу — Prolog не міг отримати його з того, що він знає, тому він вважає його хибним за замовчуванням, що не те саме, що фактично спростувати його.”

Звичайні фрази

• Чи це вдалося через об’єднання, чи ми плутаємо це з простим перевіркою рівності? ”
• «Чи є відстеження назад знаходженням цього, або нам потрібно виразно запитати наступне рішення?»
• «Чи є тут розріз, і чи розуміємо ми точно, які гілки пошуку він обрізає?»
• Чи є це предикатом, який має бути запитаний в обох напрямках, або тільки в одному?»
• «Чи це не вдається, тому що це насправді хибно, або просто недоказувано за припущенням закритого світу?»

Приклади висловлювань

Пояснення результату запиту: “Змінна була прив’ язана до bob, тому що запит успішно об’ єднався з другим фактом у базі даних — якщо ми запитаємо інше рішення, зворотній пошук повторить спробу проти третього факту і, можливо, прив’ язає його до когось іншого.”

Обґрунтування скорочення перегляду коду: “Ми додали відрізок праворуч після підтвердження того, що вхід є чинним, особливо для того, щоб зупинити відстеження від повторення спроб перевірки при невдачі в іншому місці правила - без цього, неспоріднена невдача вниз по течії може призвести до того, що Prolog повторить спробу перевірки в заплутаний спосіб.”

Пояснення заперечення сюрпризу: “Це не доводить твердження хибним - за припущенням закритого світу, Prolog просто повідомляє, що не може отримати твердження з того, що він знає на даний момент. Якщо факт справді відсутній у базі даних, заперечення-як-неуспіх повідомить його як хибний, незважаючи на це.”

Професійні поради

• Описувати ** unification ** як шаблон- збіг- з- прив’ язкою, а не призначення — це обрамлення насправді допомагає колегі, що працюють з імперативними мовами, зрозуміти, чому одна і та ж змінна може бути прив’ язана по- різному у різних спробах зворотнього зв’ язку.
• Поясніть backtracking явно, коли предикат може повернути декілька рішень — це вбудована стратегія пошуку Prolog, а не петля, яку написав програміст, і це розрізнення має значення при зневадженні несподіваних додаткових або відсутніх рішень.
• Використовуйте ** cut ** обережно і документуйте саме ті точки зворотнього шляху, які воно обрізає — cut змінює те, що предикат може довести, а не лише його ефективність, і недокументований cut є однією з найскладніших речей, які можна безпечно перефрактурувати пізніше.
• Дизайн ** передбачає ** бути справді реляційним, де це практично, запитувати в більш ніж одному напрямку - це одна з реальних переваг Prolog над імперативним кодом, і втрати цього, закодувавши один напрямок запиту, марнує перевагу мови.
• Будь чітким, коли результат залежить від припущення закритого світу, особливо в таких областях, як бази знань, де «недоказане» і «хибне» мають дуже різне значення в реальному світі — їх об’єднання є поширеним джерелом неправильних висновків.

Практичні вправи

1. Пояснити різницю між об’ єднанням і звичайним призначенням змінних.
2. Описує дії, які виконує функція зворотнього прослуховування, коли запит Prolog запитує додаткові рішення.
3. Напишіть речення, у якому пояснюється, чому недокументований розріз може ускладнити безпечне перефакторизування предиката.

На практиці: Навігація нюансів — поза технічним жаргоном

Основні концепції Prolog — об’єднання, зворотне просування, і ! (різання) — є необхідними для розуміння його сили. Однак, ефективне спілкування про ці ідеї в професійному середовищі розвитку вимагає більше, ніж просто знати термінологію; це про вираження * чому * щось робиться, і як це впливає на більшу систему. Нерідні носії англійської часто знаходять цей зсув особливо викликаючим, де тонкі нюанси у фразування можуть драматично змінити значення і сприйняту компетентність. Давайте розглянемо деякі сценарії, які підкреслюють це.

Розглянемо коментар перегляду коду. Молодший розробник пише: « Об’ єднання успішно ». Хоча це технічно правильно, але в цьому немає контексту. Ефективнішою відповіддю може бути: «Об’єднання вдалося, але отриманий термін не повністю задовольняє предикат. Розгляньте можливість додавання пункту, який би обробляв цей конкретний випадок, щоб уникнути потенційних помилок під час виконання.» Зауважте додавання « consider » — звичайного пом’ якшувача, який використовується у зворотному зв’ язку — і розглядайте цю проблему як можливість для вдосконалення, а не як пряму критику. Аналогічно, Slack повідомлення потребують ретельної конструкції. Замість простого повідомлення « Потрібна зворотна перевірка », спробуйте: « Я помітив, що тут відбувається зворотна перевірка; це свідчить про те, що ми, можливо, досліджуємо гілки не потрібен. Чи можемо ми вдосконалити правило, щоб зменшити простір пошуку?» Це пояснення запрошує до співпраці і демонструє розуміння, яке виходить за рамки простого розпізнавання технічного терміну.

Описи PR також вимагають більш високого рівня точності. Розробник міг би написати: « Виправлено проблему об’ єднання ». Знову ж таки, це не повне повідомлення. Краще було б сказати: « Впроваджено нове положення для обробки сценаріїв об’ єднання країв, визначених під час тестування, запобігання потенційним помилкам під час виконання, пов’ язаним з неправильним прив’ язуванням змінних і поліпшенням надійності системи. » Це підкреслює * чому * було внесено зміну — вирішення певної проблеми — і підкреслює позитивний результат (надійність). Словниковий запас, що оточує декларативне програмування, особливо системи, засновані на правилах, часто вимагає ретельного розгляду. Використання фраз, таких як «мінімізація зворотного відстеження», «оптимізація інстанціонування предикатів» або «використання декларативного дизайну» демонструє розуміння принципов в грі, а не просто повторення визначення. Це про передачу намірів і раціональності - демонструючи, що ви критично думаєте про саму логіку.

Ось невеличкий фрагмент коду Prolog, який демонструє об’ єднання:

% Define a predicate that checks if x is equal to y
equal(X, Y) :- X = Y.

% Example usage (unification will attempt to match these variables)
?- equal(X, 5).

Цей простий приклад показує, як працює механізм об’єднання Prolog — спроба знайти значення для X і Y, які задовольняють предикат equal. Ключовим тут є не тільки знання синтаксису; це розуміння * як * система активно шукає рішення, засноване на декларативному правилі.