LINUX.ORG.RU

Ищу соавтора! Реализация Lisp.

 


5

8

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

https://drive.google.com/file/d/0B13ti3tFkQZlSkFPV3NuMHR4eGc/view?usp=sharing

Пока исходников нет в общем доступе, т.к. я активно работаю над ними и мне тяжело будет поддерживать к ним доступ в инете. Ищу соавтора для допиливания реализации и/или написания книги по семантике Лиспа. Желательно из Санкт-Петербурга. Обращайтесь вконтакте: http://vk.com/maliculo

Еще хочу прорекламировать свою публичную лекцию в cs club по Лиспу: http://compsciclub.ru/node/2767

Пока исходников нет в общем доступе, т.к. я активно работаю над ними и мне тяжело будет поддерживать к ним доступ в инете.

В чём проблема залить на github\bitbucket? git push делается за десяток секунд всего.

Norgat ★★★★★
()

Показательно, что у автора во вконтаче первые же фотки - со странными велосипедами :3

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

Да, увлекался раньше Эсперанто. Языки программирования - это часть лингвистического поля человечества, поэтому языки человеческого общения меня тоже интересуют. Сейчас эсперанто забросил по личным причинам.

komputikisto
() автор топика

в вузе читаю спецкурс по семантике языков программирования.

Из филантропических соображений стоило бы заниматься этой работой со стдентами. Серьезно, многие корифеи, вроде Дийкстры, работали над своими идеями и проектами со студентами, это очень полезно для молодежи. Ну и аспиранты само собой.

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

Очень жаль, что не из СПб. Я поясню, почему ищу соавтора из моего города. Я далеко ушел от мейнстримных вещей типа Scheme, основные мои исследования вертятся вокруг проблем рефлексии в Лиспе (мало народу вообще понимает 3-Lisp, например). Для того, чтобы ввести в курс дела нужно личное общение. Если бы у меня было больше печатного материала, то бы согласился на сотрудничество по инету. А времени у меня мало, возможно.

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

В моем вузике нет студентов, которых интересовала бы наука. И я не кандидат наук, чтобы руководить аспирантами. Кроме того, когда работал Дейкстра, времена другие были.

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

Ну по скайпу можно.

(мало народу вообще понимает 3-Lisp, например). Для того, чтобы ввести в курс дела нужно личное общение. Если бы у меня было больше печатного материала

ты нас тут за быдло неграмотное держишь, чтоли?) Чтобы своим печатным материалом, как большевики капиталом крестьян просвещать.

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

Я не мыслю такими категориями. Разные люди специализируются на различных вещах, поэтому я не ставлю свое образование выше твоего. И я не писал, что мало народу вообще понимает Лисп, я писал - «мало народу вообще понимает 3-Lisp». Диалект такой, отличающийся крайней интроспекцией. Погугли работы Brian Cantwell Smith.

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

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

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

Подойдет человек из СПб, который умеет программировать на Common Lisp или Scheme и знает про замыкания и продолжения. Все остальное я объясню.

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

Как я понимаю ты имеешь в виду концепции, которые не реализуемы на Scheme в виде библиотечных функций/макросов? Например, невозможно реализовать на Scheme отладчик в виде библиотечной функции. Макросы - не самый удачный интерфейс для создания новых специальных форм, т.к. макорсы не являются объектами первого класса. Соответственно, Scheme лишь частично поддерживает поведенческую рефлексию. Список довольно большой...

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

а ты не пробовал просто завести блог и писать туда? мы бы ходили читать... Ну или хотя бы в /development писать, тут это вызовет живое обсуждение

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

На ЛОРе обсуждение лиспа - это лиспосрач. Мне это как-то неинтересно. Вот выше уже пытались перевести разговор ad hominem. Когда заинтересовался Лиспом, почитал немного ваши обсуждения... Я не разделяю евангелизм здешних лисперов. Для меня лисп - инструмент исследования семантики, я не пропагандирую его как general-purpose programming language.

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

Для того, чтобы ввести в курс дела нужно личное общение.

Запиши подкаст, если печатать нет времени. Это позволит постепенно подтянуть нужных людей. А как сейчас твое предложение больше похоже на запись в секту :(

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

Например, невозможно реализовать на Scheme отладчик в виде библиотечной функции.

Почему?

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

Являются. Сколько можно уже повторять эту утку?

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

Отладчик написать невозможно, т.к. Scheme предоставляет программисту интерфейс к континуациям в виде функций. Иначе говоря, Scheme реифицирует продолжения замыканиями. Замыкания - черный ящик, они абстрагируют стек от его конкретного представления. Для отладчика необходимо иметь доступ именно к стеку, а не к продолжению-функции. Например, в Smalltalk отладчик - пользовательская функция, т.к. thisContext захватывает стек, который является объектом в Smalltalk. Некоторые авторы предлагают представить континуации абстрактным типом данных, над которым доступны операции: continuation-capture (аналог call-cc, но передает в функцию-получатель объект, а не функцию), continuation-graft (хвостовой аналог вызова континуации, его невозможно реализовать в функциональном интерфейсе), next-continuation (для итерации по фреймам стека), extend-continuatin (оборачивает пользовательскую функцию в континуацию). Вот тут можно подробнее почитать:

http://axisofeval.blogspot.ru/2012/08/an-alternative-api-for-continuations.html

По поводу макросов я отвечать не буду. Это не утка, а очевидные вещи. В некотором роде, конечно, макросы - объекты первого класса, т.к. они являются функциями трансформации AST в AST, но имеется в виду совсем не это.

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

Это в каком? ИТМО?

Нет, не ИТМО. Я там учился когда-то, но работаю в другом месте. Мой вузик - довольно смешная контора. И, кстати, скажу я вам что ИТМО - заведение понты которого сильно расходятся с реальностью.

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

Для отладчика необходимо иметь доступ именно к стеку, а не к продолжению-функции.

И в чем проблема-то?

В некотором роде, конечно, макросы - объекты первого класса

Что значит «в некотором роде»? В любом роде.

но имеется в виду совсем не это.

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

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

Везде где можно использовать ф-ю - можно использова макрос.

(map and '(#t #t #f) '(#t #f #t))

Только не говори мне, что Scheme is doing it wrong.

ilammy ★★★
()

Почему столько любителей сделать ещё один никому не нужный лисп, но нет никого чтобы сделать ещё один APL (что было бы несоизмеримо полезнее)?

quantum-troll ★★★★★
()
Ответ на: комментарий от Kostafey

Я разрабатываю диалект, в котором нет встроенных специальных форм вообще. Все специальные формы - это объекты, которые определяются на основе функций в стандартной библиотеке. Поэтому, возможны такие выражения:

((if t quote cdr) '(a b c))
-> '(a b c)
((if nil quote cdr) '(a b c))
-> (b c)

Это похоже на fexpr из языка Kernel, но я использую более мощную идею, чем fexpr'ы Более того, в этом диалекте реализована полная рефлексия, т.е. минимальное отличие встроенного поведения от определенного программистом (все можно будет переопределить в рантайме). Все это приводит к тому, что компиляция никак не увеличит скорость работы, а скорее всего уменьшит. Поэтому, предполагается только интерпретатор. Т.к. все специальные формы вынесены в библиотеку, набор встроенного поведения минимален, что позволяет написать компактный и быстрый интерпретатор. Сейчас я пишу прототипы на Common Lisp. Когда он будет полностью завершен и устаканится ядро языка, то интерпретатор будет переписан на Си.

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

А как с назначением? Язык общего назначения? Встраиваемый? Или просто потому что это здорово и молодежно т.е. без практического выхода just for fun & диссертация (возможно).

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

Не знаю никакого Дениса. У меня вообще нет знакомых в Лисперской тусовке.

У тебя лавсан во френдах во вконтакте.

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

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

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

У тебя лавсан во френдах во вконтакте.

Понято. Пока лично с ним не знаком. Не получилось с ним законтачить, хотя он тоже пишет свой Lisp.

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

А мне нравится, что в ех-СССР наконец-то появляются проекты без особого практического смысла на ближние перспективы, так по-западному, знаешь ли. Правда, ТС успел продемонстрировать в треде слегка неадекватное «таких, как я - единицы», но лисперы все такие)

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

Мне представляется такая архитектура: RISC процессор выполняет вот такой компактный рефлективный интерпретатор, который полностью помещается в кэше. Никакой страничной адресации, никаких делений на пользовательский режим и режим ядра и т.п. Процессор поддерживает только два типа данных - числа фиксированной разрядности и cons-ячейки. Все остальное определяется стандартной библиотекой. Но это мечты...

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

Было бы интересней, если бы Интел выкатил FPGA на одном кристалле с ядрами, с доступом к пайплайну и с диапазоном опкодов, зарезервированных для логики на FPGA. Ну или хотя бы пользовательский микрокод чтобы можно было писать.

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

FPGA на одном кристалле с ядрами, с доступом к пайплайну и с диапазоном опкодов, зарезервированных для логики на FPGA

Это разве что на RISC-V будет.

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

Я в железе мало что понимаю, поэтому могу ошибаться, но я не вижу, зачем нужен блок управления памятью. Сборку мусора и кэширование будет делать интерпретатор. Интерпретатор написан на байт-коде, который реализуется RISC процессором. Программы пользователя к процессору вообще доступа не будут иметь. Интерпретатор предоставляет единое пространство объектов программам не в зависимости от места нахождения объекта (прототипы - Genera и Squeak). Сеть -> жесткий диск -> оперативная память -> кэш процессора - это все техники кэширования. Программы пользователя к этому не имеют никакого отношения. Добавляем новый процессор - в системе регистрируется новый интерпретатор, где бы он не находился. Более того, если на одном интерпретаторе запустить еще один (метациклически) он тоже появляется в системе как новая вычислительная единица. Этакий синтез подходов Genera, Squeak и Plan9.

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

Я в железе мало что понимаю

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

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

Процессор поддерживает только два типа данных - числа фиксированной разрядности и cons-ячейки. Все остальное определяется стандартной библиотекой. Но это мечты...

Сейчас же FPGA доступны, можно наверное замутить аппаратный прототип такого лисп-процессора.

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

Сейчас же FPGA доступны, можно наверное замутить аппаратный прототип такого лисп-процессора.

Обычный программист, до этого не имевший ничего общего с RTL, будет чувствовать, что попал в параллельную Вселенную.

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

Мы по-разному понимаем Lisp-машины и говорим о различных вещах. Делать Лисп-процессор как в CADR-машине вовсе не обязательно. Честно говоря я даже не знаю, как они вообще были устроены (ты наверно лучше меня знаешь). Я тоже думаю - что Lisp в железе не нужен. Важнее идеи которые были воплощены в Genera на уровне софта. В том же направлении мыслили создатели Squeak и, в меньшей степени, Plan9. Любой язык программирования - это своя экосистема. Она может взаимодействовать с подлежащей операционной системой, а может отгородиться от нее пересоздавая подсистемы характерные для ОС самостоятельно. Язык программирования со своей файловой системой (если она вообще нужна) и т.п. может быть запущен под управлением ОС, а может работать на чистом железе. Нативная реализация тут нужна только затем, чтобы устранить overhead. Создание Lisp машины возможно только таким путем - создать хороший, минимальный интерпретатор Лиспа, затем на его основе создать экосистему, которая выполнялась бы под управлением другой ОС, но не зависела бы от нее. Обеспечить переносимость системы вплоть до запуска на чистом железе. Дальше оптимизировать железо под систему, чтобы не было никакого overhead.

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

И J вполне живой

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

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

Я только за! Разработка новых языков - дело хорошее. Наука о языках программирования только зарождается, ей нужно больше материала. Единственное, мне кажется, разработчики нового языка должны серьезно отнестись к предыдущему опыту человечества. Гвидо, например, стал разрабатывать язык вообще не понимая что такое замыкание. Сколько обсуждений проблемы funarg было в 70-х, тем не менее Гвидо ничего не знал об этом. Нам не нужен еще один Паскаль пусть даже со сборщиком мусора. Вот APL - достойная тема исследования.

Объявляю, что если есть люди из Санкт-Петербурга, которые хотят создать язык программирования, но не знают с чего начать, то обращайтесь, я готов помочь.

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

Только не говори мне, что Scheme is doing it wrong.

И в чем проблема? Все прекрасно работает. Конечно, ты должен использовать не and, а вытащить значение из компайлтайма специальным макросом, так же как в коммон лиспе ты при передаче фунарга вытаскивашеь значение при помощи #'

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

Я разрабатываю диалект, в котором нет встроенных специальных форм вообще. Все специальные формы - это объекты, которые определяются на основе функций в стандартной библиотеке. Поэтому, возможны такие выражения:

Лямбда-исчисление уже давным-давно придумали. Ну а конкретно твой пример можно написать на любой схеме.

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