История изменений

2. Поддержка eDSL средами программирования.

по п.2 общелисп не подходит. Была статья про Racket, в котором есть для этого специальный чемоданчик костылей. Может быть, подошло бы подмножество.

3. Крайне желательна консистентность eDSL, чтобы не получить вавилонского столпотворения.

п.3 - это свойство не языка, а людей, которые его продвигают. По сути дела, должна быть диктатура комитета. По той простой причине, что разные dsl конфликтуют, в лиспе я этого насмотрелся. Именно идея кастового общества, где одни пишут dsl-и, а другие ими пользуются, и была одной из основных в «Яре».

От компилятора требуется поддержка всех сред в рантайме и максимальная интероперабельность между ними (речь о GC, *malloc, refcounter, …).

в мире лиспа и такое было сделано, кто-то когда-то comp.lang.lisp мне об этом рассказывал. Сейчас я иду к тому, чтобы сделать rc+gc в Обероне, но вот болтовня на форумах отвлекает. Но это накладывает ограничения на реализацию тех же контейнеров и ввода-вывода. Например, в лиспе read выделяет память на куче. Даже в подсчёт ссылок то, что можно прочитать read-ом, уже не запихать.

5. От компилятора требуется поддержка всех доступных систем валидации/верификации кода.

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

6. Куски компилятора в рантайме по моему желанию, а не навязанные и целиком, как в образе лисп-машины

В лиспе компилятор можно выкинуть.

Он сможет сделать мне partial specialization моего кода (видимо да, если он оптимизирующий компилятор)? А закинуть в рантайм этот его кусок, который делает partial specialization, я смогу?

В SBCL есть примерно 3 вида макросов внутри компилятора, которые раскрываются на разных этапах компиляции. def-ir1-transform - это один из них. В т.ч. они отвечают за оптимизации при наличии конкретных типов. Но так-то многое там в твоих руках.

2. Поддержка eDSL средами программирования. по п.2 общелисп не подходит.

Была статья про Racket, в котором есть для этого специальный чемоданчик костылей. Может быть, подошло бы подмножество.

3. Крайне желательна консистентность eDSL, чтобы не получить вавилонского столпотворения.

п.3 - это свойство не языка, а людей, которые его продвигают. По сути дела, должна быть диктатура комитета. По той простой причине, что разные dsl конфликтуют, в лиспе я этого насмотрелся. Именно идея кастового общества, где одни пишут dsl-и, а другие ими пользуются, и была одной из основных в «Яре».

От компилятора требуется поддержка всех сред в рантайме и максимальная интероперабельность между ними (речь о GC, *malloc, refcounter, …).

в мире лиспа и такое было сделано, кто-то когда-то comp.lang.lisp мне об этом рассказывал. Сейчас я иду к тому, чтобы сделать rc+gc в Обероне, но вот болтовня на форумах отвлекает. Но это накладывает ограничения на реализацию тех же контейнеров и ввода-вывода. Например, в лиспе read выделяет память на куче. Даже в подсчёт ссылок то, что можно прочитать read-ом, уже не запихать.

5. От компилятора требуется поддержка всех доступных систем валидации/верификации кода.

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

6. Куски компилятора в рантайме по моему желанию, а не навязанные и целиком, как в образе лисп-машины

В лиспе компилятор можно выкинуть.

Он сможет сделать мне partial specialization моего кода (видимо да, если он оптимизирующий компилятор)? А закинуть в рантайм этот его кусок, который делает partial specialization, я смогу?

В SBCL есть примерно 3 вида макросов внутри компилятора, которые раскрываются на разных этапах компиляции. def-ir1-transform - это один из них. В т.ч. они отвечают за оптимизации при наличии конкретных типов. Но так-то многое там в твоих руках.

2. Поддержка eDSL средами программирования. по п.2 общелисп не подходит. Была статья про Racket, в котором есть для этого специальный чемоданчик костылей.

3. Крайне желательна консистентность eDSL, чтобы не получить вавилонского столпотворения.

п.3 - это свойство не языка, а людей, которые его продвигают. По сути дела, должна быть диктатура комитета. По той простой причине, что разные dsl конфликтуют, в лиспе я этого насмотрелся. Именно идея кастового общества, где одни пишут dsl-и, а другие ими пользуются, и была одной из основных в «Яре».

От компилятора требуется поддержка всех сред в рантайме и максимальная интероперабельность между ними (речь о GC, *malloc, refcounter, …).

в мире лиспа и такое было сделано, кто-то когда-то comp.lang.lisp мне об этом рассказывал. Сейчас я иду к тому, чтобы сделать rc+gc в Обероне, но вот болтовня на форумах отвлекает. Но это накладывает ограничения на реализацию тех же контейнеров и ввода-вывода. Например, в лиспе read выделяет память на куче. Даже в подсчёт ссылок то, что можно прочитать read-ом, уже не запихать.

5. От компилятора требуется поддержка всех доступных систем валидации/верификации кода.

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

6. Куски компилятора в рантайме по моему желанию, а не навязанные и целиком, как в образе лисп-машины

В лиспе компилятор можно выкинуть.

Он сможет сделать мне partial specialization моего кода (видимо да, если он оптимизирующий компилятор)? А закинуть в рантайм этот его кусок, который делает partial specialization, я смогу?

В SBCL есть примерно 3 вида макросов внутри компилятора, которые раскрываются на разных этапах компиляции. def-ir1-transform - это один из них. В т.ч. они отвечают за оптимизации при наличии конкретных типов. Но так-то многое там в твоих руках.