Lisp *

Библиотека функций к 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.

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

Итак, теперь наша система позволяет описывать классы с иерархиями множественного наследования и описывать обобщённые функции(generic function) и они придают динамику, придают жизнь создаваемым в системе объектам. Но так ли хороши описанные нами обобщённые функции? Да с точки зрения широко распространённых("классических") ООП систем, они полностью повторяют функциональность методов объектов. При вызове обобщённой функции, происходит диспетчеризация вызова и выбирается наиболее подходящий по типам аргументов метод обобщённой функции. НО в CLOS это НЕ ТАК!!! Да в простейшем случае это так, НО..! CLOS предоставляет более гибкий способ организации кода, когда выполняемый при вызове обобщённой функции код представляет собой не один метод, а целую группу методов. Причём создаётся эта группа динамически в момент вызова, в зависимости от текущих аргументов обобщённой функции(вернее их типов/классов). А в основе такой организации кода лежит спецификация методов обобщённой функции различными квалификаторами.

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

Готовя эту статью я интересовался, что там в других языках, что там за «дженерики»? Все языки разбирать не буду, но скажу одно: Generic function использующиеся в ЛИСПе и современные дженерики различаются как НЕБО и ЗЕМЛЯ. За дженерики в современных языках в основном ратуют строго типизированные языки, всем понятно, что писать кучу однотипного кода просто глупо. Не скажу точно, кто стоит у истоков современных «дженериков», но пожалуй одним из ранних их проявлений это ШАБЛОНЫ в С++. Почему все остальные языки типа явы и ей подобных, решили назвать свои шаблоны дженериками мне не понятно. (у меня есть язвительное замечание, что хотели как в лиспе, но получилось как всегда). Но дело в том что в ПОДОБНЫХ дженериках языки с динамической типизацией просто не нуждаются. Функция list работает с любыми типами данных, ШАБЛОНЫ не нужны! А в С++ именно контейнеры стали основной побудительной силой использования дженериков, это просто хранилища которые хранят значения, если Си мы можем обойтись (void *) и потом привести тип к нужному, то С++ решил пойти по типобезопасному пути, ну немного "потолстев" в коде. Ну а что же там у современных его последователей?

Рассмотрим Go. Пытаясь избавиться от типа, вводят обобщённую переменную T, но понимая, что сделать то с ней ничего нельзя(кроме как хранить и выдать обратно), пытаются как то её ТИПИЗИРОВАТЬ!!! Вводят КОНТРАКТ! А что делать когда в функции надо будет делать сложение? Надо будет к этому контракту добавить ещё контракт аддитиве? а умножение? или ещё что то? в любом случае код функции БЕДЕН! именно в силу того что мы не знаем что может прилететь нам в типе Т. Я вам расскажу, что такое НАСТОЯЩИЕ ДЖЕНЕРИКИ.

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

Введение.

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

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

С необходимостью введения в язык Script‑fu Объектно‑ориентированного стиля программирования я столкнулся на поздних этапах реализации языка функциональной геометрии. Когда в коде появились «свичи/переключатели» и возможность исполнения кода в зависимости от типа входящих данных. Сам то этот «переключатель» написать не сложно, но в развивающемся проекте, постоянно возникают новые типы, изменяются, от каких то приходится отказываться, а ещё есть вариант создания модульных систем, когда в одном варианте существует один набор типов, а вдругом другой, ну а в третьем третий и т. д. И код этого «переключателя» постоянно приходится переписывать, или прибегать к различным «хакам», модифицирующим код в зависимости от того или иного варианта загрузки.

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

Да. Спустя наверно 3 дня я решил сделать это. Долго конечно, но что тут поделаешь.

Также если нужно, можете посмотреть на первую статью об этом лиспе.

Кликбейтные заголовки, давайте признаемся, надоели всем. Сейчас они встречаются даже на Хабре. Программист Линус Ли, судя по всему, испытывал те же чувства и решил действовать по принципу «не можешь победить — доведи до крайности». В результате он создал Tabloid — полноценный язык программирования, где весь код пишется в стиле сенсационных заголовков.

Представьте язык, где вместо привычного function hello() вы пишете DISCOVER HOW TO HELLO WITH (англ. «узнайте, как сделать... с помощью»), а вместо return используете SHOCKING DEVELOPMENT! (англ. «шокирующее развитие событий»). А еще каждый листинг должен заканчиваться фразой PLEASE LIKE AND SUBSCRIBE.

Звучит как странная шутка? Да, но этот язык реально работает, имеет собственный интерпретатор и позволяет писать полноценные программы.

Всем привет! Сегодня мы с вами сделаем реализацию LISP'а. Конечно же не полного.

Возможно, когда то я доведу этот лисп до ума и напишу новую статью... Но не обещаю.

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

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

Для многих людей, занимающихся программированием, вызов функции воспринимается практически как синоним передачи управления с сохранением адреса возврата и выделением фрейма памяти в стеке. Это однако, не всегда верно и в практическом, и в теоретическом отношении. О семантике и прагматике вызова функций мы и поговорим в этой статье.

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