LINUX.ORG.RU

Ворос по раскрытию макросов

 


2

5

Допустим, я пишу новый, «более лучший лисп»(ТМ). Хочу реализовать простенькую макросистему. Мой экспандер анализирует исходник, находит макровызовы, раскрывает их, а дальше возникает вопрос. Что если код, в который раскрывается макрос, содержит еще один макровызов? Его нельзя раскрыть на данном этапе, поскольку еще нет разрешения имен. Значит, мне надо заэвалить все, а раскрывать когда? Скорей всего, когда данный вызов потребуется. Заэвалил, запускаю снова экспандер. вроде норм. Но что если результат 2 вызова требуется уже при первом выполнении? Заставлять пользователя явно указывать, в какой фазе раскрывать каждый макрос, или как?

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

Лексический скоп серьезно ограничивает выразительные возможности языка, делая его более «безопасным». В конечном итоге, он ведет к «классической» (в плохом смысле) модели ООП, принятой в таких языках как JAVA. С жестко структурированной иерархией. BDSM. И с небольшим сахарком, становиться достоянием быдло-энтерпрайза, где он, действительно, более чем уместен. ИЧСХ, Стилл, как раз таки, один из дезигнеров этого говна.

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

В конечном итоге, он ведет к «классической» (в плохом смысле) модели ООП

Не смотря на то, что некоторые считают, что замыкания и ООП - суть одно, это не так. ООП о полиморфизме. Исторически так сложилось, что ad hoc полиморфизм смогли открыть впервые в модели посылки сообщений (Smalltalk). Сейчас уже известен лучший механизм ad hoc полиморфизма - generic функции CLOS. Хотя Лисперы уже как 20 лет знают решение проблемы с ООП, это опять наталкивается на ту же историю, что с проблемой funarg. Забавно наблюдать, как мультиметоды адаптируются вне Лиспа. Например, в Perl 6 сочетает одновременно ООП в стиле Smallatk и в стиле CLOS.

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

Не смотря на то, что некоторые считают, что замыкания и ООП - суть одно, это не так.

Во первых, не ООП, а быдляцкое недоООП. Во вторых — кто этого не понимает, или спорит с этим — тот дебил. И в третих, к сведению, основа смолтоковских объектов — это лисповские fexpr'ы

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

основа смолтоковских объектов — это лисповские fexpr'ы

Что? Пример кода в студию! Фэкспры были в Smalltalk-72, но в Smalltalk-80 ничего подобного нет. Сейчас именно последний понимается под Смолтоком.

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

Что?

Не позорься, почитай Кея. Тебе говорят не о фекспрах в языке, а о том, что фекспры — семантическая основа объектной системы. Ты лекции по лиспу читаешь, а лисп не знаешь них*я

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

В Smalltak я разбираюсь. Так вот, нет там фекспров. Изначально были, и про это, видимо, ты прочитал у Alan Kay. В Smalltak-80 управляющие конструкции реализованы в виде методов, которым передаются замыкания (блоки - в терминологии Smalltalk).

Я вообще принципиально не пишу о темах, в которых на разбираюсь. Когда я что-то тут пишу, то это результат серьезной проработки вопроса. Вот я не разбираюсь в компиляции, например, и не буду раздавать советы как написать компилятор Лиспа.

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

фекспры — семантическая основа объектной системы

Это как это? Похоже на бред. Семантическая основа Smalltak - диспетчеризация по одному аргументу.

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

Не смотря на то, что некоторые считают, что замыкания и ООП - суть одно, это не так. ООП о полиморфизме.

ООП об инкапсуляции.

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

Лексический скоп серьезно ограничивает выразительные возможности языка

А как в вашем «всё есть текст»-лиспе без лексического скопа написать такую функцию:

(define (generator x)
  (let ((i x))
    (lambda ()
      (set i (+ i 1))
      i)))

(define a (generator 1))
(define b (generator 1))

> (a)
2
> (a)
3
> (b)
2
> (a)
4

?

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