Конечно, промежуточные именования на шагах последовательного вычисления. И наступил очевидный прогресс, когда появился Фортран, который позволил нам просто писать выражения и вычислял их, не требуя от нас именовать все эти промежуточные результаты на языке ассемблера. Я не думаю, что выражение само по себе не логично — в конце концов это просто терм, — но я предпочел бы поднять функции до того же уровня, на котором находятся отношения, как это делал Фреге в первоначальном замысле исчисления предикатов. Я знаю азбучную истину, что функция — это просто специальный вид отношения. Но это можно повернуть в обратную сторону и с тем же успехом показать, что отношение — это просто специальный вид функции. На самом деле именно так на это смотрел Фреге. Для него отношение —это функция . И таким образом, вы представляете себе вычисление отношения точно так же, как вычисление любой другой функции. Отношение отличается просто множеством принимаемых им значений. Далее можно поставить вопрос. Он, конечно, должен быть частью этой обстановки, но мы не хотим перегружать его, как мне кажется, всеми этими посторонними обязанностями. Меня беспокоит и другое. До сих пор все системы логического программирования, с которыми мы имели дело, были маленькими. Что я под этим подразумеваю. Что произойдет, когда мы перейдем к более крупным системам, так что не сможем поместить все в оперативную память. И тогда перед нами встает проблема замедления доступа к предположениям, которая меня несколько беспокоит. Мне не ясно, как при переходе к очень большим системам мы собираемся получить ускорения, о которых говорится в проекте вычислительных систем пятого поколения, . Робинсон Сегодня системы логического программирования имеют скорости в липсах. Если мы собираемся повысить скорость до . Мне кажется, что если мы сможем остаться в оперативной памяти машины, то вполне можно надеяться, что мы это ускорение получим. Перейдя к параллельным вычислениям, мы, вероятно, получим выигрыш в сто раз. , мы, вероятно, умножим скорость еще на сто. Остальные десять раз можно надеяться получить, если мы будем более изобретательны, чем были до сих пор, в организации основных алгоритмов. Так что я думаю, что ускорение в . Но если нам надо получать наши дизъюнкты из дисковой памяти, то перед нами встает проблема, как достичь этого ускорения. Или как еще мы должны хранить терабайты информации. Я задаю себе вопрос, оправдывается ли ваше большое доверие к этой идее. Существует, как вы знаете, некоторый риск в том, чтобы сделать эту идею центральной. Я думаю, вероятность того, что эксперимент будет успешным, очень велика. Но есть и некоторые опасности. В подходящий момент я еще скажу об этом. И наконец беспокойство общего характера — что произойдет с логическим программированием как с чисто абстрактной идеей, когда люди разделаются с ним. Мы должны стараться направлять это развитие в начинающемся сейчас десятилетии, чтобы к концу его иметь такое понятие системы логического программирования, которым мы могли бы гордиться, которое было бы элегантным, мощным, простым и действительно обладало всеми достоинствами, каковыми логическое программирование как идея, по. Будем надеяться, что, добиваясь практического успеха логического программирования в больших масштабах, мы не пожертвуем этой элегантностью и красотой. Меня нервирует, когда я читаю статьи или слышу дискуссии, в которых логи . Возможно, я напрасно беспокоюсь. Наконец, так как я очень люблю Лисп, как и многие другие люди, я надеюсь, что Лисп, эта красивая вещь, не исчезнет. Я не настолько фанатичный сторонник логического программирования, чтобы желать Лиспу поражения и полного вытеснения чем. Как я говорил раньше, правильная линия для них обоих состоит в том, чтобы стать тем, чем они стараются быть, а именно системой утвердительного программирования. Так что я хочу, чтобы Лисп выжил. Это красивая и мощная идея. Так что не будем разрушать Лисп, обеспечивая успех логическому программированию. Нам представляется удивительно благоприятная возможность хорошо поработать над парадигмой логического программирования. Посмотрим, что делал с Лиспом Питер Ландин в начале . Он ясно показал то, что, как это ни удивительно, не вполне осознавал Маккарти, изобретая Лисп, а именно что Лисп — это по существу ламбда. Он объяснил это с помощью изумительно элегантной абстрактной машины — ЭЕСО. Я думаю, что эта работа Ландина чрезвычайно важная и красивая. Если вы посмотрите на работу современных исследователей в области функционального программирования, таких, как Дэвид Тернер и Питер Хендерсон. Я думаю, что важно стремиться к красоте и элегантности в этих поисках, связанных с приложениями математики. В действительности, если это красиво, то вы не сможете уйти далеко по неверному пути. Мы не хотим, чтобы логическое программирование плодило . Это было бы ужасно. Одной из неудачных особенностей программирования в области искусственного интеллекта за последние пятнадцать или двадцать лет была тенденция создавать эффективные, но уродливые системы. Давайте попытаемся избежать этого. Робинсон Примером удобной возможности повысить элегантность является унификация. Я верю, и многие другие тоже, что унификация — очень сильная идея, которая может объяснить ряд других идей, возникающих в информатике, очень хорошо, просто и правильно. Я думаю, что это основной механизм для всех процессов передачи параметров как при вызовах функций, так и при их активации. Так это выглядит в Прологе и в процедурной интерпретации Ковальского. Но этот механизм никогда фактически не испытывался, насколько мне известно, в контексте функционального программирования. В Алголе, Паскале, Лиспе и так далее передача параметра соответствует одностороннему совмещению . Фактический параметр при таком сопоставлении не изменяется, изменяется только формальный параметр. Он должен совпасть с фактическим параметром, и после этого выполняется тело процедуры. Теперь у нас есть шанс посмотреть, что произойдет с функциональным программированием, когда мы обобщим механизм передачи параметров, превратив его в двусторонний обмен информацией.