LINUX.ORG.RU

вопрос по sicp


3

5

Глава 4.4.1 Логическое программирование, дедуктивный поиск информации.

Я правильно понимаю что sql это пример яп для логического программирования?

Что еще можно почитать по типу sicp но желательно без привязки к конкретному яп?

★★★★★

Ответ на: комментарий от unt1tled

что не так в жабном ООП?

Основная идея ООП, основанном на посылке сообщений - объект сам решает, как обработать сообщение. С точки зрения языка не должно быть «правильных» и «неправильных» сообщений. Если принять такой взгляд, ООП - механизм работающий за счет late binding. В языках со static binding, идея, что все зависит от объекта и его состояния не работает.

Мы уже знаем, что ООП на сообщениях - всего лишь первая попытка реализации ad hoc полиморфизма. Да и само слово ООП вызывает нарекания. Есть ad hoc полиморфизм и нет никакого ООП.

komputikisto
()
Ответ на: комментарий от loz

В примере скобки плохо расставлены, или так должно быть?

Похоже на то, что аргументы либо передаются в виде thunk'ов либо просто так в виде AST (или текста). Я тут не вижу передачи отдельно окружения как в Kernel. Если в виде thunk'ов - то вполне нормально, можно и так. Если же эти аргументы - просто AST или текст, то тут проблема.

komputikisto
()
Ответ на: комментарий от loz

Кроме thunk'ов и явной передачи окружения есть еще одна схема, реализованная в tcl. Но для того, чтобы она работала, нужно чтобы функции имели явно выделенные фреймы. В коде ниже uplevel вычисляет код в относительно внешнего по отношению к текущей функции фрейму.

proc do {body while condition} {
    if {$while ne {while}} {
        error "invalid argument \"$while\": must be while"
    }
    uplevel 1 $body
    uplevel 1 [list while $condition $body]
}

Так какая из трех схем реализована в REBOL?

komputikisto
()
Ответ на: комментарий от komputikisto

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

Отправка сообщения вызовом метода есть гут,не?

«правильные/неправильные»? Щито? Нет метода - нет сообщения. static binding, да. Состояние объекта стабильно. Все работает. Программист все знает.

Есть ad hoc полиморфизм и нет никакого ООП.

эммм

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

Отправка сообщения вызовом метода есть гут,не?

Если ты не программировал на Smalltalk, Ruby, Python, то твое непонимание вполне объяснимо. Оно может быть компенсировано при помощи RTFM-подхода.

Итак, я не собираюсь пересказывать Blue Book. Замечу лишь, что отправка сообщения != вызов метода.

Нет метода - нет сообщения.

И вот внезапно все фичи ООП сводятся к нулю. Прежде чем спорить с кем-то на темы теории языков программирования, имей в виду, что упоминание Java не придает веса твоим словам, а скорее говорит о твоей осведомленности в области языков программирования.

komputikisto
()
Ответ на: комментарий от komputikisto

В примере скобки плохо расставлены, или так должно быть?

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

Так какая из трех схем реализована в REBOL?

Это так-называемый блок,

Blocks are groups of values and words.

Это как цитируемый список в лиспе, похоже на ast. А в чем проблема с ast и чем оно отличается от thunk?

loz ★★★★★
()
Ответ на: комментарий от loz

А в чем проблема с ast и чем оно отличается от thunk?

Зачем, собственно, нужно невычисленные аргументы передавать в функции? Это один из способов реализации определенных программистом специальных операторов (если использовать терминологию Lisp). Так вот, специальные операторы могут в определенных случаях вычислить эти аргументы. И тут возникает проблема - относительно какого окружения их вычислять? Есть два варианта:

  1. текущее окружение
  2. внешнее окружение (то, что было перед вызовом fexpr'а)

Первый вариант не катит, т.к. аргументы функций и специальных операторов обычно вычисляются во внешнем окружении. Первый вариант работает только в dynamic scope (с некоторыми оговорками).

Как можно внешнее окружение получить внутри fexpr'а?

  1. передать в качестве дополнительного аргумента
  2. обернуть каждый переданный AST в thunk (замыкание без аргументов)
  3. реализовать оператор похожий на uplevel из tcl

Kernel, 3-Lisp реализуют первый вариант. В Io есть еще fexpr'ы, но я не знаю по какому пути там пошли. Если в REBOL нельзя из fexpr'а получить доступ каким-то образом к внешнему окружению, то на все, что можно на них определить - quote.

komputikisto
()
Ответ на: комментарий от komputikisto

И правда, я никогда не кодил на руби/смолток/питоне. В ООП писал только на яве и плюсах. Передачи сообщений в многопоточных приложениях делал на аде.

Можно ссылку на мануал, где об этих сообщениях рассказывают?

unt1tled ★★★★
()
Ответ на: комментарий от unt1tled

Различия между вызовом метода и отправкой сообщения - часть фольклора. В Smalltalk это имплицитное знание.

Обсуждение на stackoverflow

Лучше попробуй поучить какой-нибудь язык с динамической типизацией, например, Ruby. Предлагать Smalltalk не буду, т.к. это очень далеко от мейнстрима.

Передачи сообщений в многопоточных приложениях делал на аде.

Ради интереса на Аде писал или работа была такая?

komputikisto
()
Ответ на: комментарий от komputikisto

Ради интереса на Аде писал или работа была такая?

Писал когда-то в универе. Курс был по параллелизьму. В рабочей жизни аду никогда не встречал.

unt1tled ★★★★
()
Последнее исправление: unt1tled (всего исправлений: 1)
Ответ на: комментарий от komputikisto

Зачем, собственно, нужно невычисленные аргументы передавать в функции?

А зачем вобще передавать аргументы в функции? Чтобы они что-то с ними сделали же. Код можно сохранить, обработать, передать куда-то, мало ли что с ним можно сделать.

специальных операторов

Что еще за специальные операторы?

И тут возникает проблема - относительно какого окружения их вычислять?

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

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

Не кактит т.к. обычно так не делают? Это вобще аргумент?

Как можно внешнее окружение получить внутри fexpr'а?

Как можно внешнее окружение получить внутри fexpr'a, созданного на одном компе, а выполняемого на другом, с другой осью, железом и версией компилятора/интерпретатора и библиотек?

loz ★★★★★
()
Ответ на: комментарий от loz

Как можно внешнее окружение получить внутри fexpr'a

Окружение — ассоциативный список, отображающий имена переменных на значения. Кода создается функция, она захватывает текущее окружение (это называется «замыкание»). Если передать функцию на другой комп, то она это окружение потащит за собой.

Что еще за специальные операторы?

В Лиспе так называют абстрагированные от синтаксиса управляющие конструкции. Например, if - специальный оператор.

(if условие true-ветка false-ветка)

Это вобще аргумент?

Аргумент! Если первая вещь эмулирует вторую, то вторая должна вести себя как первая. Fexpr'ы эмулируют специальные операторы, соответственно, они должны вычислять аргументы в том же окружении, что и специальные операторы.

На самом деле, знакомство с Лисп даст тебе в руки инструмент для анализа любых концепций программирования. Ты сможешь лучше понять тот же REBOL, если он тебя все еще будет занимать, когда ты осознаешь Лисп.

komputikisto
()
Ответ на: комментарий от komputikisto

Окружение — ассоциативный список, отображающий имена переменных на значения

Внутри блока неизвестно что у тебя имя переменной, т.к. это может быть твой личный dsl, поэтому не понятно какое окружение нужно захватывать.

Например, if - специальный оператор.

А в реболе if - функция, принимающая блоки кода в качестве ветвей:

>> help either
USAGE:
    EITHER condition true-block false-block 

DESCRIPTION:
     If condition is TRUE, evaluates the first block, else evaluates the second.
     EITHER is a native value.

ARGUMENTS:
     condition -- (Type: any)
     true-block -- (Type: block)
     false-block -- (Type: block)

Fexpr'ы эмулируют специальные операторы

Учитывая выше про if, в чем отличие специального оператора от функции работающей с кодом?

loz ★★★★★
()
Ответ на: комментарий от loz

в чем отличие специального оператора от функции работающей с кодом?

Нет отличий. Просто в Лиспе до определенного момента не было понятно, как такие функции делать (fexpr'ы). Лисп же старше REBOL'а! Так вот, специальные операторы - это такие же функции, работающие с кодом, просто встроенные. В Лиспе, который поддерживает fexpr'ы категория специальных операторов исчезает.

Внутри блока неизвестно что у тебя имя переменной

Ты не понял что есть замыкание. При формировании замыкания не учитывается множество свободных переменных тела функции (блока). Более того, в работе «A Lisp through the Looking Glass» предлагается идея активного замыкания. Активные замыкания инкапсулируют весь контекст, который нужен для вычисления этого куска кода из любого места. Активные замыкания захватывают не только текущее окружение, но и текущий язык. Интересно, захватывают ли язык (грамматику и вычислитель) блоки REBOL. Я сильно сомневаюсь, что это так.

komputikisto
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.