Lisp *

Как хорошо известно, макро в Лиспе — это особая функция, которая вычисляется в два этапа: на первом этапе происходит генерация некоей промежуточной формы, а на втором этапе эта форма выполняется в текущем контексте.

Важно отметить, что на первом этапе ядро Лиспа не вычисляет значения аргументов вызова.

Использование макро в гомоиконном Лиспе позволяет добавлять в Лисп новые «операторы» (именно поэтому знаменитый лиспер Пол Грэм назвал Лисп программируемым языком программирования).

Однако, у медали имеется и обратная сторона: если код содержит большое количество макро, то при интерпретации Лиспа будет тратиться значительное время на макрогенерацию.

Если честно, я давно планировал написать свой язык. Просто надоело на каждом проекте писать одинаковый бойлерплейт, ловить неожиданные ошибки в рантайме, натыкаться на компоненты аля LoanPreloanInterractNDFL6.2ReportViewComponent - и гадать - что имел ввиду художник...

В итоге получился язык "Марка" — штука статически-типозированная, но в которой типы живут во время выполнения, ошибки обрабатываются сами, а из REPL можно сразу дергать запросы и смотреть, что приходит на клиенте и сервере. Как давно мечтал.

Но раскидав исходники по знакомым, получил неутешительный фидбэк: читать трудно! Встал дурацкий вопрос: как это должно выглядеть в коде, чтобы было удобно? Я набросал 4 варианта синтаксиса — от LISP-стиля до почти Python - нотации. У каждого есть плюсы и минусы, и я уже неделю не могу выбрать.

Какой из вариантов читать было бы удобнее лично вам? Проголосуйте!

P.S. Если заинтересовал проект - уже сейчас доступна playground площадка для экспериментов http://marka-lang.ru/playground.php

Идеи аспектно-ориентированного программирования до сих пор широко используются в современных языках и фреймворках — достаточно вспомнить их роль в экосистеме Spring. Однако при всей практической востребованности сама парадигма остается как будто в тени. Чтобы немного это исправить, мы публикуем перевод текста Грегора Кизалеса и его коллег из Xerox PARC — первого полноценного манифеста АОП, представленного на конференции ECOOP ’97 и заложившего основы для дальнейших исследований в этой области.

Инкапсуляцию и наследование часто преподносят как две неотъемлемые опоры объектно-ориентированного программирования, однако на деле между ними существует глубокое внутреннее противоречие. Статья Алана Снайдера, опубликованная по итогам его выступления на OOPSLA’86, стала одним из первых программных текстов, вскрывших эту проблему на уровне языковых конструкций, и показала, как неаккуратно реализованное наследование способно разрушить инкапсуляцию, а вместе с ней — преимущества модульного проектирования. Работа во многом предопределила дальнейшие дискуссии о хрупком базовом классе, роли контрактов между классами и их потомками и о том, каким должен быть внешний интерфейс класса в условиях наследования.

Недавно попалось на глаза одно очень интересное видео с динамическими шкалами по популярности разных языков программирования по годам (вроде как, начиная с 1980х). Удивительно, сколько всего и как много придумало человечество. И как быстро меняются тренды, а еще - сколько всего уникального уходит в тень истории. Вот был такой Лисп. Принято считать, что Лисп - это что-то из учебников по истории программирования. Где-то между перфокартами и первыми компиляторами. Условный артефакт. Язык, которым пользовались бородатые профессора, пока не пришел Python и не навел порядок.

Только вот Python тоже унаследовал из Лиспа некоторую часть. Но не все. Самое радикальное так и не забрал.

В августе прошлого, 2025 года, я рассказал о создании собственной чёрно-белой темы для GNU Emacs. Почти год безсменно я её использую и не испытываю никаких проблем (скриншот позволяет в этом убедиться). Но рассказ будет не про это, а про то, как выглядит техника создания собственной темы для Emacs. Для тех, кто подумал, что будет также скучно и сложно, как и в рассказах про создание собственного пакета и режима для Emacs, да, это так, только не сложно.

Привет, Хабр и читатели!
Сегодня я попытаюсь сделать с вами диалект LISP.

Я думаю, что я достаточно хорошо понимаю как его сделать.

Мы реализуем там TCO, FEXPR функции и dynamic scoping.

Наверное, каждый программист, работавший с объектно-ориентированными языками, хотя бы раз слышал о законе Деметры. Многие знают его смысл, но мало кто читал оригинальный текст 1989 года, где закон был не только сформулирован, но и подробно обоснован. В этой статье авторы, Карл Либерхер и Иэн Холланд, рассказывают о проекте «Деметра», дают формулировки для разных языков и обсуждают, когда законом можно пренебречь.

Часть 1. DWG. Как побочный кейс стал основным

Путешествие в кроличью нору автоматизации процессов может привести к занятным результатам. Казалось бы, тривиальная задача часто оказывается не таким уж и простым в реализации кейсом. Особенно без поддержки со стороны вендора.

АрдуЛисп – это революционное решение для олимпиадной и соревновательной образовательной робототехнике, основанное на использовании блочного языка программирования и скриптового языка программирования – ЛИСП.

Все известные решения в области образовательной робототехники в мировой практике имеют возрастной порог...

Одна из самых эзотерических тем в программировании и computer science это продолжения (continuations), ограниченные продолжения (delimited continuations) и continuation-passing style. Я попытаюсь раскрыть эту тему понятным для обычного программиста языком. Предполагается, что обычный программист знаком с понятиями функции/подпрограммы, фрейма вызова (stack frame), а также имеет базовое знания языка Scheme, хотя бы на уровне первых глав SICP.

Библиотека функций к Script-fu

В предыдущей статье мы рассмотрели имеющиеся в GIMP возможности векторной графики. Здесь мы рассмотрим как эти возможности использовать при построении графических примитивов — Фигур. Для построения абстракций фигур мы уже написали несколько классов: Фигуры рисуемых по контуру Кистью и Карандашом, Фигур заполняемых определённым цветом, Комбинированных Фигур, Фигур использующих Изображения и Фигур использующих Текст. Здесь я продемонстрирую, как легко и непринуждённо мы можем встроить новые абстракции в существующую иерархию классов. А заодно рассмотрим как вся эта иерархия классов может использоваться в языке функциональной геометрии, рассмотренном в предыдущем цикле статей.

Библиотека функций к Script-fu

Когда то, очень давно, считалось что графические редакторы делятся на растровые и векторные. К векторным относились Coreldraw Adobe Illustrator Inkscape и работали они не с отдельными пикселами изображений, а с элементами называемыми векторами, которые можно превращать, с помощью манипуляций в дуги различной формы, называемыми кривыми Безье. К растровым же относились Photoshop Paint и тот же GIMP. В этих редакторах отсутствовала какая либо геометрия и изображения представляли собой наборы отдельных точек - пикселов. Но время не стоит на месте и элементы растрового редактирования проникали в редакторы, которые считались векторными и наоборот, элементы векторных редакторов переносились в растровые графические редакторы. Примером тому является GIMP.

Представление о том, что GIMP то растровый графический редактор давно уже устарело. Текстовый слой, да и вся работа со шрифтами в GIMPе это работа с векторными объектами представляющими собой кривые Безье. Таким образом целые текстовые слои в GIMP представляют собой векторные объекты. По мимо отдельных текстовых слоёв, в каждом изображении GIMP можно создавать отдельные строки и вектора. Вот с ними мы сегодня и разберёмся.

Библиотека функций к Script-fu

Вы любите рефакторинг? Ну вот и я приблизительно так же. Основное правило хорошего программиста, такое: «Работает, НЕ ТРОГАЙ!». Но иногда, в редкие минуты помутнения/вдохновения, возникает желание, или я бы даже сказал зуд, в одном месте, и мы садимся за рабочее место, берём в руки клавиатуру и начинаем «творить шедевры» с чистого листа.

Системы подпрограмм для языка функциональной геометрии я писал три раза: сначала в функциональном стиле(и в этом то месте и возник пресловутый «свитчинг по типам», потом в стиле примитивных объектов, который не имел наследования, но я придумав хак с шаблонным использованием кода, значительно сократил его дублирование и теперь, когда я разработал развитую ООП систему, во многом повторяющую функциональность CLOS. И это событие прекрасная причина, чтобы переработать старый ООП код, в новой ОО системе. Чем мы с вами здесь и займёмся.

Библиотека функций к Script-fu

Как я ранее уже говорил, обобщённые функции нашей системы производят диспетчеризацию вызовов методов основываясь на типах входящих аргументов. Пока меня устраивала ситуация, что диспетчеризация производится только для классов. Все остальные типы данных не учитывались при диспетчеризации методов. В реально же CLOS возможна диспетчеризация по примитивным типам данных. И вообще для работы обобщённых функций классы не требуются. Можно ли как то реализовать подобное поведение в нашей системе? Решению данного вопроса и посвящена эта статья.

Библиотека функций к Script-fu

В принципе реализация представленная в файле obj4.scm и описанная ранее, меня вполне устраивала. Я реализовал там всё что хотел от объектной системы: определения классов и обобщённых функций, множественное наследование, статические поля класса. Но вот какое-то маленькое зёрнышко сомнения, мешало мене оставить этот проект. А всё ли я сделал для ускорения работы системы? И дело даже не в том, что какие то нехорошие люди из проекта GIMPа обрезали возможность для Script-fu загружать расширения, что не даёт возможности быстро рассчитать хеш-код символов(а то и вовсе заменить хеш-таблицы сишной реализацией). Нет. Для себя я спокойно перекомпилирую Script-fu и буду пользоваться всеми преимуществами предоставляемыми настоящей tinyscheme. Но что же можно сделать ещё, чтобы улучшить скорость работы ОО системы? А может и не только скорость.

Библиотека функций к Script-fu

После написания объектной системы для Script‑fu я задумался над примерами, на которых хорошо бы было проверить эту систему. Я прошерстил уйму литературы, но хороших примеров использующих все возможности ООП в литературе встречается крайне мало. Ну что толку реализовывать класс List в Лиспе? А класс Stack? Примерами подобных классов пестрят книжки по Си++. Всё было не интересно, но вот я встретил книжку «Теория вычислений для программистов» Тома Стюарта, и вот примеры из неё, написанные на Ruby, показались мне интересными. Да в Ruby нет множественного наследования, но есть возможность создавать миксины, что несколько сглаживает этот недостаток. И вот делая примеры из этой, безусловно замечательной(с точки зрения теории вычислений), книжки я заметил, что мой код получается более длинный чем код Ruby. И это происходит не только из за наличия операторов в Руби. Сами определения классов и методов в Руби получаются компактнее, и требуют меньше кода. Сможем ли мы что нибудь сделать, чтобы «догнать» Руби в «краткости» кода?!

Библиотека функций к Script-fu

Итак, мы разработали практически полнофункциональную ООП систему для языка tinyscheme, так же работающую в script-fu GIMP. Но гложет меня одна мысль, реализовать поля общие для всех объектов класса. В разных языках они называются по разному, но смысл один, некие значения которые общие для всех объектов одного класса. В принципе как я уже указывал, такие поля реализуются как глобальные переменные, но реализация их в виде подсистемы ООП облегчит управление этими полями и использование их в обобщённых функциях. Тут есть тонкий момент: обобщённая функция может работать не только с объявленными типами параметров, но и с их наследниками. Если мы используем общие поля для класса в виде какой то глобальной переменной, то с этими полями могут работать не только объекты объявленных в параметрах классов, но и их потомки. И по идее методы обобщённой функции должны работать с типами соответствующим типам входных аргументов, а не просто типам объявленных параметров. А работа с глобальной переменной не будет различать одних потомков объявленных параметров метода от других. Во всяком случае такая персонализация работы будет затруднена и должна будет выполняться в ручную.

Библиотека функций к Script-fu

Написание кода на Лисп это тестирование, я не знаю(это не значит что их нет, просто я их действительно не знаю) ни одного языка программирования в котором цикл: написание код - проверка(тестирование) был бы таким коротким. Кстати в Script-fu я работаю через буфер обмена, это не удобно! Там есть возможность работать из Емакс, через сервер Scrip-fu, но я эту возможность не использую(приятно видеть консоль), а с обычной схемой или лиспом, работа в передаче кода заключается в нажатии пары клавиш. Лисперы не пишут многостраничные листинги кода, а затем его тестируют, они пишут функцию, выполняют его в интерпретаторе и сразу тестируют. Всё это благодаря наличию в системе REPL. И всё таки не смотря на это настаёт момент, когда требуются отдельные тесты, которые удобно запустить и проверить консистентное состояние программной системы, а то в процессе такого интенсивного создания-тестирования программы всё равно можно что либо опустить, и какая нибудь функциональность да отвалится.

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

В конце лета 1955 года в колледже Дартмут под руководством доцента кафедры математики Джона МакКарти состоялся семинар, посвященный вопросам искусственного интеллекта. Результатом этого семинара стал запрос на проведение исследовательского проекта.

Целью исследования стала проверка гипотезы, что все детали обучения или любые другие особенности интеллекта [человека] в принципе могут быть описаны так, что станет возможно создать машину для их моделирования.

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