Человеческое метапрограммирование

Ну, с учетом того что большинство тулов от JetBrains все же на java, есть основание заключить что N2 будет под jvm

> Prolog

Метапрограммирование в Prolog? Это как?

> Tcl
> homoiconicity

Разве?

С чего бы это VladD2, вендузятнегу, заявляться на ЛОР и поливать Nemerle?

Но так никто не делает

Так того, что это делать удобно никто и не обещал.

Убрал приставку «мета» за ненадобностью.

Ну очевидно, лда, что любое метарпограммирование является и программированием в том числе.

Вот есть в каком-нибудь компиляторе система типов для исходного языка, какое тут метапрограммирование?

Ну как какое? Еще раз, метапрограммирование - это взаимодействией с лексическим контекстом программы и изменение семантики программы на основании информации из этого контекста. Это как раз то, чем занимается тайпчекер, то есть реализация тайпчека - метапрограммирование с точки зрения языка, который мы чекаем.

В таком, что функции компилятора отвечающие за тайпчек никто не называет макросами, как и соответствующие системы типов - метапрограммированием.

Ну и что?

http://llvm.org/docs/TableGenFundamentals.html

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

Nemerle 2 (aka JetBrains N2) пока есть только в спеках.

Кода там уже больше чем спек. Говорю как человек, который этот код пишет. И спеки придумывает.

А вообще, какие пожелания?

Про JVM и натив уже слышал.

осторожно, у ТСа чакры от плохой кармы погнутся

А вообще, какие пожелания?

Добавить поддержку макросов со стороны рантайма и полноценную работу с тайпчекером (определение собственных семнатических правил, естественно, нужен будет прувер для доказательства корректности полученной системы, причем макросы должны взаимодействовать с прувером) вместе с опциональной безтиповой средой (можно сделать untyped nemerle поверх типизированного хост-языка), человеческую гигиену, гомоиконичность, фазы с «лексической башней», библиотеки первой необходимости для макросов и распространенных паттернов типа анафор и т.п. - чтобы все с гарантиями корректности и безопасно, офк, удобный протокол для реализации поддержки со стороны ИДЕ, полноценную модульность. Это то, без чего не обойтись - то есть те аспексты системы, профиты от которых используются повсеместно и отсутствие хоть одного из которых на порядки усложняет разработку.

AGDA 2

наиболее надежное решение

например?

Разве?

всё есть строка, в том числе - исходный код

ok, согласен.

Конкатенативные языки вроде Factor'а. http://factorcode.org/

Понятно. Хочется лисп но круче.

Ни лиспа ни немерла не будет. Н2 продукт совершенно другого типа.

Это не язык для написания конечного кода. Это язык для написания языков. Причем в отличие от всяких яков решение будет полностью интегрированным. Те там будет и парсер и типизатор и кодогенератор и всё что нужно для IDE.

Сейчас идет работа над парсером. С ним все ясно. Осталось только дописать.

Потом займемся типизатором.

Кроссплатформенность будет. Но не в первых релизах.

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

Вы уверены, что с немерлой не повторите той же ошибки?

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

Немерле ограничен .НЕТ. Лисп вообще динамически типизированный со всеми вытекающими.

Н2 будет работать принципиально иначе. В его случае не нужно переписывать свой язык в Н2. Более того в большинстве случаев это не будет иметь смысла. Ибо Н2 заточен на написание языков. И всё остальное он не будет уметь делать принципиально.

При этом Н2 будет позволять переписывать написанные на нем языки в любые другие языки. Так что это именно платформа для создания языков. И ничего кроме создания языков уметь не будет.

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

Ну ясно, очередной Coq изобретаете. Не интересно.

Ничего общего с Coq. Откуда ты это вообще взял?

А чем лучше TXL?

http://www.txl.ca/

Н2 заточен на написание языков. И всё остальное он не будет уметь делать принципиально. При этом Н2 будет позволять переписывать написанные на нем языки в любые другие языки.

Мде. «Вычеркиваем» (ц)

Мде. «Вычеркиваем» (ц)

Почему?

Потому что, даже если вы (если ты из команды Н2) и реализуете задуманное, полученный инструмент будет иметь высокий порог вхождения _и_ будет сложным в использовании. А вот ЯП общего назначения он не будет.

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

Причем эти языки можно будет спокойно расширять при помощи Н2.

Так что если тебе понадобится написать свой if или for то тебе придется написать всего несколько строк кода.

Короче все будет строго проще, чем в немерле.

Вместе с ним будут поставляться языки общего назначения

языки

И, похоже, вы думаете, что это хорошо. Печаль.

Никому не нужны _языки_. Нужен один язык, который покрывает 80% задач и обладает средствами расширения, чтобы покрыть остальные 20%. Немерль1 был таким языком.

Никому не нужны _языки_. Нужен один язык, который покрывает 80% задач и обладает средствами расширения, чтобы покрыть остальные 20%. Немерль1 был таким языком.

Ох. Одним из поставляемых зыков будет немерль1. Но с макросами сделанными на Н2.

Ох. Одним из поставляемых зыков будет немерль1.

«Одним из» или «единственным юзабельным в качестве языка общего назначения»?

Но с макросами сделанными на Н2.

Имеется в виду «Н1 будет сделан макросами на Н2»?

А чем лучше TXL?

Посмотрел TXL . Он ужасен.

Расширяемого синтаксиса нет.

Типизатора нет.

Поддержки ИДЕ для создаваемых на нем ИДЕ нет.

Короче: Планета шелезяка. Воды нет. Полезных ископаемых нет. Населена роботами. (С)

Каждой задаче - свой язык. Что из языков делает попытка сделать их general_purpose прекрасно видно на примере перегруженного дерьма коим является всеми обожаемый cpp.

«Одним из» или «единственным юзабельным в качестве языка общего назначения»?

Ессно не единственным. Ибо создавать языки будет очень просто.

Имеется в виду «Н1 будет сделан макросами на Н2»?

Нет. Макросы для Н1 будут писаться на Н2. Ибо Н2 несравнимо лучше подходит для создания и расширения языков.

В остальном это будет тот же Н1.

Совершенно согласен. Именно по этому Н2 и делаю. Ибо на нем можно будет очень легко писать языки под задачу.

Каждой задаче - свой язык.

Привет, как погодка у вас в Вавилоне?

дерьма коим является всеми обожаемый cpp.

Лучше бы ты подумал, почему Си++ так широко используется.

Н2 будет работать принципиально иначе. В его случае не нужно переписывать свой язык в Н2. Более того в большинстве случаев это не будет иметь смысла. Ибо Н2 заточен на написание языков. И всё остальное он не будет уметь делать принципиально.

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

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

Именно так. По-этому выбор толкового хост-языка - очень важен.

Это не язык для написания конечного кода. Это язык для написания языков. Причем в отличие от всяких яков решение будет полностью интегрированным.

Racket уже давно есть. Чем немерле2 лучше?

Как обычно - раз racket, то сразу lisp, а раз лисп, то сразу надо переписать, потому что это же лисп, он старый и писан дураками, надо переписать лучше. а выйдет опять штука, которой максимум, что можно сделать - писать какие-то штуки в песочницу хабра за инвайты:/

То есть это обычная библиотека для парсинга?

Далеко не только парсинга. Хотя алгоритм парсинга сам по себе очень интересный.

Будет типизатор, который по простому описанию типизации будет строить алгоритм выводи типов который понимает перегрузку. Кто в теме тот знает насколько это сложно.

Будет кодогенератор с оптимизатором. Причем со сменными бекендами. Те один язык можно будет компилировать и в CLR и в JVM и в натив и в жабаскрипт. Причем если воспользоваться промежуточным языком из поставки, то это всё будет бесплатно.

И все это с полной поддержкой ИДЕ, отладчиком итп

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

Это очень серьезное заблуждение. Невозможно создать рантайм пригодный для всего.

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

Поэтому и получаются системы с крайне ограниченной областью применения. Именно поэтому лисп и находится там, где он есть.

Именно так. По-этому выбор толкового хост-языка - очень важен.

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

Racket уже давно есть. Чем немерле2 лучше?

Рацкет это очередной лисп. Со всеми его проблемами. И прибитым гвоздями рантаймом. Это просто инструменты разных типов. Всё равно, что сравнивать молоток с самосвалом.

Привет, как погодка у вас в Вавилоне?

Отлично. Работаем раз в 10-100 меньше чем вы для того чтобы получить то же результат.

Лучше бы ты подумал, почему Си++ так широко используется.

По глупости. Я когда маленький был мне С++ тоже нравился. Подрос, понял, что это ужОс ужОс.

Это очень серьезное заблуждение.

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

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

Нельзя реализовать _эффективно_, быть может. А просто реализовать - можно. Или приведи пример, что нельзя.

Поэтому и получаются системы с крайне ограниченной областью применения.

Ну можно привести пример «ограниченности»?

Рацкет это очередной лисп. Со всеми его проблемами.

Это с какими? Я вот знаю плюсы лиспа для разработки дслей - гомоиконичность, простой синтаксис, динамическая типизация. Какие же «проблемы», можно услышать?

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

Действительно - разных. Все, что можно будет делать в немерле2, уже сейчас можно делать в Racket (ведь для того чтобы генерить произвольный код на произвольном ЯП вообще ничего не надо, натурально, бери любой ЯП - да генери). Но то, что можно делать в Racket, никогда нельзя будет делать в немерле2 - ведь там нету «прибитого гвоздями рантайма», который бы обеспечивал выразительность :) Так что я бы сказал, что Racket - это бригада строителей с самосвалами, молотками, пилами и т.п., а немерле2 - набор отверток для детского конструктора.

Привет, как погодка у вас в Вавилоне?

Работаем раз в 10-100 меньше чем вы для того чтобы получить то же результат.

Ну ты-то ты не из Вавилона, а с Поля Чудес.

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

А я знаю, что для 100% задач достаточна статическая типизация и генерация кода во время компиляции.

Сколько я не просил любителей динамики показать мне задачу, для решения которой динамическая типизация давала бы преимущества так мне ничего и не показали. Ни одной задачи. Только решения. Причем в 100% случаев обоснование сводилось ко: Мне так хочется.

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

Ах, да, еще и дсли будут между собой внутренне несовместимы - ведь они транслируются в разные ЯП под разные рантаймы!

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

Нельзя реализовать _эффективно_, быть может. А просто реализовать - можно. Или приведи пример, что нельзя.

Просто нельзя. Например, продолжения и любой вид детерминированной финализации. Деструкторы С++, try/finally или любой другой по вкусу.

У тебя либо развалятся инварианты детерминированной финализации. Либо придется сильно обрезать продолжения.

Ну можно привести пример «ограниченности»?

Если нужна надежность, скорость работы, малое потребление памяти то лисп идет лесом. Ибо динамически типизирован.

А мне обычно они все 3 разом и нужны.

Так что на моих задачах лисп ну ваще никак. Немерле еще терпимо. Но всё равно буду слезать на Н2 когда он будет готов. Да я уже частично на него слез. Ибо он уже частично работает. И даже эта часть немало сил экономит.

Это с какими? Я вот знаю плюсы лиспа для разработки дслей - гомоиконичность, простой синтаксис, динамическая типизация. Какие же «проблемы», можно услышать?

Динамическая типизация это приговор. Сразу в морг.

Скобочки тоже ужасны. Но это относительно мелочи. Хотя именно из-за этого большинство людей и не воспринимает лисп.

Действительно - разных. Все, что можно будет делать в немерле2, уже сейчас можно делать в Racket

А еще это можно делать на машине Тьюринга. Вопрос в объёме работы.

А я знаю, что для 100% задач достаточна статическая типизация и генерация кода во время компиляции.

А я знаю, что для 100% задач достаточно тьюринг-полноты. Теоретики уже заебали своим теоертизированием о «достаточности». На практике «достаточность» никого не волнует - инструмент должен быть удобен, а не абстрактно «достаточен».

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

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

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

Могут - не значит будут.

Только у них рантайм один и прибит гвоздями.

Я не понимаю, как можно прибить рантайм к языку. Вот у меня есть некий язык программирования Х, каким образом и кто может мне запретить генерировать на этом языке код для хост-языка Y (Y - произволен)?

Просто нельзя. Например, продолжения и любой вид детерминированной финализации.

Можно, через cps-трансформацию. Так сделано в CL, например.

У тебя либо развалятся инварианты детерминированной финализации. Либо придется сильно обрезать продолжения.

Ничего не развалится и не обрежется. 2012 год на дворе, указанная проблема давно решена.

Если нужна надежность, скорость работы, малое потребление памяти

Так и надо было говорить: «цель - написание препроцессора для няшной сишки, никакие другие задачи решать не предполагается». И никаких проблем. но ты зачем-то влез со своим примитивным препроцессором в тред, где обсуждаются системы метапрограммирования, до которых твоему немерле2 как до луны пешком.

А еще это можно делать на машине Тьюринга. Вопрос в объёме работы.

Объем работы - такой же как и в случае немерле2 офк. Как максимум. Вообще говоря - значительно меньше.

Динамическая типизация это приговор. Сразу в морг.

Наоборот, приговор - статическая типизация. Это сразу означает, что макросистема абсолютно неязабельна.

Ничего общего с Coq.

Тогда тем более не нужно. Потому как Coq - единственная на данный момент хоть немного приличная платформа для декларативного создания языков. Ну ладно, не совсем единтсвенная - есть еще Maude и K-framework. При этом оно говно редкостное и воняет.

Откуда ты это вообще взял?

А оно мне надо, в сортах говна разбираться?

Просто нельзя. Например, продолжения и любой вид детерминированной финализации. Деструкторы С++, try/finally или любой другой по вкусу.

У тебя либо развалятся инварианты детерминированной финализации. Либо придется сильно обрезать продолжения.

dynamic-wind? Не, не слышал.

Естественно Ada.

JetBrains со своим MPS уже пытались выпендриться. И чем все закончилось? Пшиком и позорнейшим Kotlin-ом. Идете по их стопам? Ну что ж, туда вам и дорога. Во всяком случае это лучше, чем если бы вы (команда Н2) ширялись и лампочки в подъездах били бы. Просто не пытайтесь выставить свое нелепое хобби как что-то значимое.

А я знаю, что для 100% задач достаточно тьюринг-полноты. Теоретики уже заебали своим теоертизированием о «достаточности». На практике «достаточность» никого не волнует - инструмент должен быть удобен, а не абстрактно «достаточен».

А я и говорю про удобство. Максимум что могут динамисты это отжать десяток процентов кода. И то не всегда.

Берем вот такой код. https://github.com/rampelstinskin/ParserGenerator/blob/8d02b02b76ed08ab9f71a5...

Он статически типизирован. Что может убрать динамическая типизация? А ничего. Ни буквы.

Динамическая типизация дает уже тот профит над статической, что не надо писать типы и сражаться с тайпчекером.

Хватит сказки рассказывать. Вывод типов выводит чуть менее чем все типы. И ни какой войны нет. Особенно если у нас не язык общего назначения, а ДСЛ с системой типов созданной под этот ДСЛ.

По-этому это апологетам статики надо доказывать преимущества статики - если наличие таковых не доказано, то динамика выигрывает по умолчанию.

Надежность. Скорость работы. Малое потребление памяти. Так что динамика проигрывает по умолчанию.

И макросы для динамически типизированного языка писать _намного_ проще, быстрее и удобнее, чем для статически типизированного.

Это твоя вера. Я с ней не согласен.

Я не понимаю, как можно прибить рантайм к языку. Вот у меня есть некий язык программирования Х, каким образом и кто может мне запретить генерировать на этом языке код для хост-языка Y (Y - произволен)?

Да никто. Просто ты проделаешь на пару порядков больше работы чем на Н2.

Ничего не развалится и не обрежется. 2012 год на дворе, указанная проблема давно решена.

Ты даже не понял где проблема. Она не в том чтобы код переписать, а в том, чтобы сохранить инварианты. А это никаким CPS преобразованием не сделать. Ибо после того как детерминированная финализация закроет файл продолжение может вернуть управление в ту точку в который файл как бы еще открыт. И всё. Приехали. Инварианты программы нарушены. Пошло неопределенное поведение. Здравствуй худшая сторона С/С++.

Так и надо было говорить: «цель - написание препроцессора для няшной сишки, никакие другие задачи решать не предполагается». И никаких проблем. но ты зачем-то влез со своим примитивным препроцессором в тред, где обсуждаются системы метапрограммирования, до которых твоему немерле2 как до луны пешком.

Ты просто не понимаешь и даже не пытаешься понять что такое Н2. Про парадокс блаба слышал? http://en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)#Blub

Не волнуйся. Как работают макросы лиспа я знаю.

Никому не нужны _языки_. Нужен один язык, который покрывает 80% задач и обладает средствами расширения, чтобы покрыть остальные 20%. Немерль1 был таким языком.

Неверно. Язык-то может и покрывать 80% задач - но только для своей платформы. А перенеси его, например, в embedded, на микроконтроллеры - и он и одного процента не покроет. Так что языков нужно много и разных. И нужны удобные средства для быстрого и безболезненного написания компиляторов. Но таких средств, кроме (с очень большой натяжкой) Coq сейчас нет.

ASM Z80 Sinclair Reasech LTD.
Вот там было нормальное программирование.