[лисп] уже почти достал

>сегодня я буду генерить php/javascript/html, а завтра delphi/sql/tsql

<deadly_serious_стёб_моде>
http://www.softwaresecretweapons.com/jspwiki/lexyacc
</deadly_serious_стёб_моде>

Всё, капец. Я понял, что объём приведённых ссылок превосходит мои возможности по их чтению. И что тут все слишком умные для меня.
Однако,
> если уж на то пОшло, то curly braces тоже не удобны (не удобнее round braces), и рулят только на программерской раскладке Дворака, где их можно нажимать без кнопки Shift. А рулят [] или `', которые нажимаются без шифта.

Меня больше напрягает ЧТЕНИЕ, чем печать. Всё же редко за день кодер пишет столько кода, чтобы пальцы устали именно от этих шифтов.

Вот ещё о чём подумал, пока ехал в электричке. На самом деле, в лиспе для меня не хватает самой малости:

1. Иерархические пространства имён (на самом деле, есть, но не на всех реализациях).
2. Конфликт должен возникать не во время use-package, а во время read, как это имеет место быть в SQL. Не
- Сегодня мы будем говорить о моржах и устрицах
- package system error: И у моржей, и у устриц есть глаза. Уточните, что вы будете понимать под словом "глаза" далее в сегодняшнем разговоре?

А

- Сегодня мы будем говорить о моржах и устрицах.
- Ок
- Их глаза
- read error: Извините, но я не понял, о каких глазах вы ведёте речь

Вторая дисциплина реализована в SQL и я считаю её более правильной.
Есть и третий вариант, with в Паскале, который не ругается, а берёт случайный из имеющихся вариантов. Но это плохо.

Что такое Y-комбинатор,я не знаю (и я уверен, что мне даже не нужно это знать). Я не ФП-шник.

3. Должна быть конструкция
#with-packages(package-names &body body)
Её можно сделать и в обычном лиспе.
4. Плохо, что в файле может быть только один defpackage.
5. Плохо, что case insensitive по умолчанию.

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

Посмотрел кое-что.
Slinks - явно не про то. Type inference - это хорошо и здорово, но когда это сделано центральной идеей языка, я этого не могу понять. На самом деле, в 50% достаточно программировать полиморфно, с типом
"t" - и всё будет отлично. В критичных по скорости местах не будет чрезмерной работой выписать все типы явно.

> "{;" -- шаблон visitor для обхода дерева
Вообще-то, это просто директива форматирования или правило парсера.

{ a; b; c } <=> ("{;" a b c)

При этом, всё очень просто и строится на принципе баланса скобок. При этом, ридер (даже парсером его не назвать) работает примерно за линейное время. Он легко пропустит { a; b; c,d }, но не пропустит
{ [ } ] . Этого вполне достаточно для начала. Правда, в некоторых случаях, конечно, нужны исключения. Например, для кода
'foo('+bar+')' - здесь наблюдается взаимная несбалансированность кавычек и круглых скобок. В принципе, эта проблема тоже решается, примерно вот так:

`(:string (funcall foo ("(," (:string-escape ,bar)))) . Во всяком случае, это в лиспе. Я пользуюсь таким генератором (сам написал) уже достаточно давно и не замечаю никаких шероховатостей. Я уже умею делать так, что
(funcall foo (:s c)) будет генериться в foo('c') или в foo["c"], в зависимости от настроек кодогенератора. Но теперь захотелось большего.

haxe понравился. Буду рассматривать как вариант. Правда, нужно выяснить насчёт масштабируемости. Конечно, тяжело после лиспа - у него всё настолько хорошо, что никто с ним не может выдержать сравнения...

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

Вот. Пожалуй, на сегодня всё.

>Что такое Y-комбинатор,я не знаю
>type inference - это хорошо и здорово, но когда это сделано центральной идеей языка, я этого не могу понять. На самом деле, в 50% достаточно программировать полиморфно, с типом
"t" - и всё будет отлично. В критичных по скорости местах не будет чрезмерной работой выписать все типы явно.

http://en.wikipedia.org/wiki/Y-combinator

Уточнение насчёт ("{;" a b c) - на самом деле, это не ПРАВИЛО парсера, а всего лишь РЕЗУЛЬТАТ ЕГО РАБОТЫ.

Парсер определяется подобно syntax-table в емаксе. Для него нужно сказать:

1. Что является скобками. Для каждой открывающей скобки - что является её закрывающей.
2. Что является constituent character, т.е., из чего можно клеить идентификаторы. На самом деле, тут всё будет как в С.
3. Что является унарной, а что - бинарной операций. Унарный минус идёт лесом вместе с унарной звёздочкой в С.
4. Приоритеты операций.
5. Какие скобки позволяют взаимный небаланс. Например, '(' - это допустимо. <text>[</text> - это допустимо. { [ } ] - это недопустимо.
6. Везде, где есть потенциальные конфликты смыслов, грамматика требует ставить пробел, как это сделано в лиспе.
7. whitespace тоже иногда является значащим символом. Например, нужно парсить список

select a.*, b.name from a inner join b on a.id = b.id

При соответствующих приоритетах это парсится в

(" "
select
(" ," (dot a *) (dot b name))
from a inner join b on
(= (dot a id) (dot b id))
)

(если я ничего не путаю)
А дальше что-то типа (defmacro (" " select &body body) ...)

В общем, я не планирую задавать грамматику c правилами типа
if ( expr ) operator
Такого рода задачи делаются уже макросами, по-лисповски.

8. Всякого рода составные скобки типа (* *) , // , /* , #| либо вообще идут лесом, либо требуют пробелов вокруг, чтобы их можно было распознать. Хотя, возможно, что это неправильно, я ещё не додумал. Зато будут <тег>вот твоя шляпа</тег>.

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

>select a.*, b.name from a inner join b on a.id = b.id
>При соответствующих приоритетах это парсится в
>(" "
>select
>(" ," (dot a *) (dot b name))
>from a inner join b on
>(= (dot a id) (dot b id))
>)

тут вопросы, 1) а как генерируется это " ," и "{;", другим парсером? он выделяет токены? 2) для каких грамматик можно написать такой парсер на "аналоге reader macro", а для каких нельзя и нужен парсер с полноценной грамматикой? 3) неоднозначности в грамматике (вроде "требует ставить пробел") разруливаются человеком или автоматически, нормальным парсером?
то есть, когда имеет смысл писать отдельный парсер и сразу получить AST, а когда по-максимуму использовать стандартный лисповый reader и дальше мутить макрами.

Короче -- ты хочешь язык, по консистентности напоминающий лисп, но без его нечитаемого синтаксиса.

Опять же я согласен, что создатель DSL должен не писать свой парсер, а задать несколько (в основном непроцедурных) опций для него.

Что ты тут не сказал -- так это парсер вероятно д.б. линзой (это термин из aegis). Это значит, что код, распарсенный с одними опциями, можно было вывести из S-выражения в новый "изначальный вид" уже с другими опциями, оттдуа его распарсить и получить снова то же S-выражение.

Но конкретные попытки ограничить парсер выглядят жалко:

> 3. Что является унарной, а что - бинарной операций. Унарный минус идёт лесом вместе с унарной звёздочкой в С.

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

Собственно твои претензии к лиспу, если их оформить, я думаю будут заключаться именно в том, что у лиспа reader macro не создает линзу.

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

> 2. Конфликт должен возникать не во время use-package, а во время read, как это имеет место быть в SQL.

и в с++ так же (как в SQL) при множественном наследовании, и в других вменямых языках

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

В смысле, лисповой макрой описываются только локальные трансформации, или нет?

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

Вот это я совсем не понял, но интересно.

> Всякого рода составные скобки типа (* *) , // , /* , #| либо вообще идут лесом, либо требуют пробелов вокруг, чтобы их можно было распознать. Хотя, возможно, что это неправильно, я ещё не додумал.

Могу подключиться к раздумьями

> Зато будут <тег>вот твоя шляпа</тег>

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

> Всякого рода составные скобки типа (* *) , // , /* , #| либо вообще идут лесом, либо требуют пробелов вокруг, чтобы их можно было распознать.

Есть достаточно простые алгоритмы проверки однозначности КС грамматики -- это все можно распознать.

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

Конечно, можно заставить пользователя есть кактус^W то есть использовать только предопределенные литералы, в том числе иерархические тэговые литералы.

> Ну, у меня есть. Очень важно иметь возможность изменить код без остановки работы. Почитай, как в NASA правили удалённо код на Лиспе на спутнике.

Ссылку пожалуста насчет НАСА, а насчет остановок -- 99% это терпит, но те случаи, когда это невозможно, все же интересны. Лисп здесь не уникальное решение, например можно для этого использовать кластеризованную БД, вокруг которой крутятся обычные программы на обычнейшем императивнейшем С.

s/aegis/augeas/

>> В лиспе интересно *только* оперерирование AST.

> Ты Лиспа не понял.

Объясни, но сильно сомневаюсь что сможешь -- на плюсах или на Д все остальное гораздо удобнее.

Макры _не_ задают преобразование в неподвижных точках.
Они задают семантику языка. Рефакторинг - да, но его можно делать и без комбинаторов. Если мы транслируем с языка на язык, то преобразование можно считать тождественным, только если мы транслируем с С на С или с PHP на PHP. Если транслируем с C на PHP, то транслятор содержит знания о семантических различиях.

Я не думаю, что реальные авторы компиляторов знают и пользуются комбинаторами и монадами. И вообще, с моей (уже давно сложившейся) точки зрения, чистое ФП и Хаскель - это секта. Хотя одной программой на Хаскеле я пользуюсь и признаю её достаточно толковой (это - darcs).

www_linux_org_ru, возможность не останавливать лисп - это чертовски удобно. Да, SQL является другим аналогом, применяемым в индустрии. Ну и в общем, операционная система со своими скриптами. Меняя скрипты, мы не перезапускаем операционную систему. И это круто.

> 2. Конфликт должен возникать не во время use-package, а во время read,
Кстати, конкретно эта проблема решается - можно подрулить use-package для себя. При этом твой код будет недоступен культурным лисперам, а ты сможешь использовать любые лисповые библиотеки. Для этого нужно подменить несколько функций системы пакетов.

> Собственно твои претензии к лиспу, если их оформить, я думаю будут заключаться именно в том, что у лиспа reader macro не создает линзу
Я бы так не сказал. Во-первых, в лиспе во многих случаях есть соответствие между read и print, т.е., во многих случаях

(equal x (read-from-string (princ-to-string x)))

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

Моя претензия к лиспу не в этом - я об этом достаточно подробно написал, они исходят из практики и ни к чему единственному не сводятся. Ну и отчасти это не претензии, а констатация непригодности для некоего класса задач.

> универсальной формой должно быть *не* S-выражение, а кое-что похожее, но отличающееся.
S-выражения (а точнее - консы) достаточно хороши в качестве внутреннего представления, почему же нет? Дальше вопрос - что напихать внутрь. Можно в голову списка пихать не строки, а какие-то более умные объекты.

> Есть достаточно простые алгоритмы проверки однозначности КС грамматики -- это все можно распознать
Пожалуй, я погорячился насчёт посылания всего лесом. Наверное, нужно сделать как-то так:

1. Взять синтаксис обычных языков, лексеры/парсеры где-то позаимствовать.
2. Задействовать <> для тэгов, а там, где в старой грамматике были < и >, заменять их тегами. Получится

template <less>typename T<greater> class List

3. Склеивать языки между собой тегами или настраиваемыми ключевыми словами. Например, можно сделать, как в shell:
<<endmarker
Это
мой
текст
endmarker

Логично, чтобы тэги содержали название языка.
<L.lisp>
(+ 2 <L.C>scanf(...)</>)
</>

В этом случае мы получим, как минимум, формат для представления в одном файле текста на разных языках. Далее можно в каждый язык ввести понятия квазицитирования - для каждого языка в своей грамматике. Для С-подобных языков просто вводим quote и unquote во всех видах (функция или оператор). Далее всё происходит по вычислительной модели лиспа, т.е., проходят обычные этапы read/compile/load. Естественно, пока мы не умеем непосредственно исполнять С-шный код, то пользователь не должен писать на верхнем уровне
<L.C>printf("%d",4)</>
а может писать только
<L.lisp>(print (+ 2 2))</>
чтобы получить свой C-код, он должен будет написать соответствующую лисп инфраструктуру (или мы должны ему написать).

Всё это вместе решает первую часть задачи - генерацию кода.

Для чтения кода нужно сделать так, чтобы каждый парсер выдавал s-выражения (или что-то ещё) единообразного вида.

И, пожалуй, нужен как минимум один вид read-macro: переименования. 
Например, в какой-то программе используется слово unquote. 
Тогда нужно сделать что-то типа
with_renames([unquote -> my_unquote]) {
  quasiquote(unquote(my_unquote(arg))); // unquote - ф-я пользователя, 
  // my_unquote - конструкция квазицитирования. 
}

Хотя не факт, что это - read-macro. Похоже, что это - просто macro. 

(вот кстати, уже болезненный вопрос, как быть с дефисом? With-renames
 легче читается, чем withRenames, и легче пишется, чем with_renames). 

>но в начальной точке он сильно уступает быдлоязыкам (таким, как JavaScript)

И вовсе он не быдло; хороший язык, где удачно совмещены ООП и функциональное программирование. Кстати, референсная реализация ECMAScript4 (которая лежит на ecmascript.org)написана на лиспе, и, возможно, тебе стоит её покрутить.

>Они задают семантику языка

ок, сохраняющее семантику и задающее эквивалентную трансформацию исходного кода. В этом смысле и макры и рефакторинг делают одну и ту же задачу

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

транслятор содержит, но транслируемая программа-то содержит одинаковую семантику при реализации на разных языках, "разные языки" -- просто разный синтаксис с той же семантикой. Да и в пределах одного языка можно например, записать одну и ту же (семантически) программу через goto, if..else, do..while, паттерн какой-нибудь, конечный автомат. Логически структура та же самая, способ реализации (синтаксис) разный. Если транслятор -- это модель, то транслируемая программа -- спецификация модели, с точки зрения семантики этой конкретной программы язык не важен.

> Логично, чтобы тэги содержали название языка.

посмотрите REBOL и "диалекты" в нём: http://en.wikipedia.org/wiki/REBOL#Examples

> Далее всё происходит по вычислительной модели лиспа

напоминает Qi http://www.lambdassociates.org/studies/study01.htm

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

> Кстати, референсная реализация ECMAScript4 (которая лежит на ecmascript.org)написана на лиспе, и, возможно, тебе стоит её покрутить.

ДА, ВОТ ЭТО МЕГА КРУТО! Спасибо большое! Хотя, наверное, там он сделан как слабенький интерпретатор, но в общем, есть с чего начать.

> В этом смысле и макры и рефакторинг делают одну и ту же задачу Если мы - господь Бог и можем выгрузить семантику из мозга программера в виде s-выражений или xml, то тогда да. В противном случае - нет. Та же семантика, но выраженная на другом языке - она уже не "та же". Той же она становится, если где-то (у Бога) есть "наиболее общий знаменатель", с которым мы можем сверить любой текст на любом языке. В реальности мы этого не можем сделать, поэтому зачем об этом думать?

Те, кто советует мне тот или иной язык, извините, если пытаюсь отфутболить. Языков слишком много. Если пытаться подобрать нужный среди существующих, это можно просто урыться в сети. Конкретно, по реболу. Ну, то, что closed-source - это ещё ладно. Но вот что не понравилось. http://www.rebol.net/cookbook/recipes/0040.html PHP ИМХО красивее. Недаром PHP вынес Perl - ведь он, по сути, построен на технологии квазицитирования. Perl говорит "print", а PHP говорит, какие и куда нужно вставить переменные части страницы. То, что предлагаю я, вполне позволяет программировать в стиле PHP. REBOL аналогичен перлу. Жду контрпримеров.

Теперь про QI.

Я не считаю, что haskell - это хорошо. Мне он не нравится вообще, самой своей идеей. Ocaml мне тоже нравится не особо, хотя его скорость впечатляет. Есть люди, которые ценят строгую типизацию, я не отношусь к их числу и я уже об этом отписал несколько выше: в критичных местах типы можно написать и вручную, а в остальных всё и так будет хорошо. Кроме того, даже в обычном лиспе с типизацией всё не так плохо - можно писать программы, где типизировано практически всё, при этом, часть работы по вычислению типов всё же делает компилятор.

Qi декларирует свои цели как язык для веб-программирования и для GUI, но все конкретные примеры относятся к доказательству теорем и теории типов. Я считаю, для доказательства теорем просто ещё не хватает быстродействия современных машин. Когда оно вырастет хотя бы ещё раз в сто, то будет о чём говорить.

В любом случае, мне интересен пример, как генерить javascript из Qi.

ECMAScript написан не на лиспе, а на ml. У меня есть один знакомый окамлщик, я его уже порадовал этим фактом :)

> REBOL аналогичен перлу. Жду контрпримеров.

долго сейчас искать, но где-то был пример с несколькими DSL на реболе в одной программе (те же layout ит HTML). Фактически, он в этом смысле похож на TCL: то, что в квадратных скобках, относится к отдельной команде, возможно, другого диалекта с другим DSL. А слово перед квадратными скобками задаёт нужный диалект. Как в том примере с <Lisp.L>(..) <C.L>(..), хотя для примера пойдёт любая двуязычная программа (в смысле, один исходник, который можно откомпилировать С, паскалем и фортраном, например -- конструкции чужого языка вынесены в этом в комментарии)

Блин, говорил же себе, не советовать не проверив самому :(

Более детально изучил haXe. У него есть та часть, которая вызывает интересь. Именно - межплатформненая реализация многих основных вещей,

см. http://haxe.org/api

Это очень хорошо (хотя вообще-то, если реализовывать её с лиспа, то нужно учитывать keyword arguments). Но он не имеет правильного МП. Заношу его в избранное. Может быть, можно сделать правильный язык из него.

Кстати, кто-то писал про "один .so на одно выражение". В GCL примерно так и есть. Он транслирует лисп в C, вызывает компилятор С, делает so и прикомпоновывает к образу.

хары фигней страдать, берешь яву и идешь на нормальную работу или пишешь что-то свое с другими программистами (которые не понимают и не хотят ничего типа лиспа, кемла, форта и хаскела)

Нет такого языка - лисп, нет рынка, нет специалистов, "нет" это в общем, они может и есть но это "есть" на столько мало, что мона сказать НЕТ!

Просто решай задачи, имей нормальный интересный проект ;)

все говно, и си++ и лисп, и ява, просто надо выбрать что-то и кайфовать думая что ты сделал все что мох. ))))))))))))))))

> все говно, и си++ и лисп, и ява, просто надо выбрать что-то и кайфовать думая что ты сделал все что мох.

Не подходит.

Можно сделать хороший язык.

А остальные пусть молятся Божественной Яве, Божественному Лиспу или (ммм... че-то не встречал молящихся Божественным Плюсам).

>> Собственно твои претензии к лиспу, если их оформить, я думаю будут заключаться именно в том, что у лиспа reader macro не создает линзу

> Я бы так не сказал. Во-первых, в лиспе во многих случаях есть соответствие между read и print, т.е., во многих случаях

> (equal x (read-from-string (princ-to-string x)))

Я говорил о том, чтобы это было *всегда* верно и в случае кастомизованного синтаксиса.

> В других случаях это может быть не нужно, если read macro вызывается ради побочного эффекта.

Тогда у тебя м.б. проблемы. Как ты будешь транслитовать свою прогу с одного диалекта на другой диалект?

> Моя претензия к лиспу не в этом - я об этом достаточно подробно написал, они исходят из практики и ни к чему единственному не сводятся.

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

1. Ты будешь делать свой парсер-линзу?

2. Ты его сделаешь для себя или будешь продавать или распостранять нахаляву с открытыми исходниками?

Интерграцию можно делать не только в емаксом, из грамматики вполне реально генерить синтаксические файлы допустим для K-develop. (я тут не собираюсь весте флейм емакс против K-develop)

>> Собственно твои претензии к лиспу, если их оформить, я думаю будут заключаться именно в том, что у лиспа reader macro не создает линзу

> Я бы так не сказал. Во-первых, в лиспе во многих случаях есть соответствие между read и print, т.е., во многих случаях

> (equal x (read-from-string (princ-to-string x)))

Да, я говорил о том, чтобы это было *всегда* верно и в случае кастомизованного синтаксиса.

Но augeas еще умеет и обратное, т.е. в его "S-выражении" хранятся комментарии, и распечатав S-выражение в выбранном синтаксисе, мы имеем те же комментарии на тех же местах. Количество пробелов -- не помню, но их тоже можно приравнять к комментариям, и при распечатке получать вообще идентичный исходник.

Еще один момент -- если твой парсер будет не линзой... то надо подумать... но видимо он вообще мне будет не интересен, и думаю сообщества тебе не видать.

Объясню, почему я так думаю: постоянно будет требоваться транслировать программу с диалекта на диалект, по причине

1. развития самого диалекта

2. переноса этой проги в другую предметную область, где юзается другой диалект

3. у кого-то м.б. другое эстетическое чувство, привычка или стандарт кодирования в команде -- например, отступы вместо скобок.

> Есть люди, которые ценят строгую типизацию, я не отношусь к их числу и я уже об этом отписал несколько выше: в критичных местах типы можно написать и вручную, а в остальных всё и так будет хорошо.

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

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

оверхеде == о дополнительных трудозатратах

> Он транслирует лисп в C, вызывает компилятор С, делает so и прикомпоновывает к образу.

Это для того, чтобы было можно не вылезая из отладчика, поменять отлаживаемый код?

Надо подумать о полезности такой фичи в отладке.

_____________________________________________________

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

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

> А остальные пусть молятся Божественной Яве, Божественному Лиспу или (ммм... че-то ?>не встречал молящихся Божественным Плюсам).

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

Хороший язык делают многие, например Пол Грехем, или там кто еще.. Появляются какие-то поделки котоорые никому не нужны, или вы готовы отдать лет 10 своей жизни на проект с непонятной перспективой?

удачи.

Решать реальные задачи, вот что приносит счастье, а такие неудачники как Вирт только и знают, что языком чесать и выдумывать суперязыки и технологии, которые потом другие успешно применяют для СВОЕГО уже языка.

Можно до пенсии искать серебряную пулю. Универсального языка нет и не будет, опуститесь нна землю. си++ хотел быть таким, ну и что поулчилось у него?

Всем привет!

> Это для того, чтобы было можно не вылезая из отладчика, поменять отлаживаемый код?

Я бы всё же посоветовал немного освоить Common Lisp в практическом проекте. Тогда станет понятно. Пример: я немного участвовал в проекте symbolicweb (кстати, возможность участия в нём открыта для всех). У меня было запущено (в одном образе лиспа): - сам лисп (время запуска 10 секунд) - веб-сервер hunchentoot - DSL генерации html cl-who - система symbolicweb (время загрузки около 7 секунд) - мои примеры Всё это занимает порядка 200 мб хипа.

Что, я должен после каждого изменения всё это перезапускать? И терять все значения присвоенных мной в образе переменных? Извините... Вместо этого, я меняю только свой пример и через 0.18 секунды могу его тестировать на том же самом сервере. Я считаю, что это нормально и что это должно быть только так, и никак иначе. То, что в других проектах приходится зачастую работать по-другому - это плохо.

> Но augeas еще умеет и обратное, т.е. в его "S-выражении" хранятся комментарии, и распечатав S-выражение в выбранном синтаксисе, мы имеем те же комментарии на тех же местах. Количество пробелов -- не помню, но их тоже можно приравнять к комментариям, и при распечатке получать вообще идентичный исходник.

Постараюсь на него посмотреть.

> Да, я говорил о том, чтобы это было *всегда* верно и в случае кастомизованного синтаксиса.

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

> > В других случаях это может быть не нужно, если read macro вызывается ради побочного эффекта.

> Тогда у тебя м.б. проблемы. Как ты будешь транслитовать свою прогу с одного диалекта на другой диалект?

Я говорил о лиспе, а не о гипотетическом новом языке. Проект будет, ессно, делаться open-source. Тем не менее, я буду делать его для себя. И важно, что я буду делать его в ограниченные сроки. Каждый день должна появляться новая полезная фича, которая будет сразу использована в деле. И таких дней должно быть не более 30 (иначе проект потеряет цельность).

> Строгая типизация нужна не только и не столько для скорости, сколько для правильности программы

Меня эта проблема не парит.

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

Шаблоны не нужны - они являются частным случаем макросов. type inference нужен, но он сложен и стоит времени компиляции. Впрочем, я не против него. Программа, полиморфная по умолчанию, выражает более общие алгоритмы и поэтому её легче развивать. Способность программы меняться в рантайме трудно совместима с оптимизацией хранения и доступа, достигаемой при статической типизации. Вот четыре причины не пользоваться обязательной статической типизацией. Вопрос решается просто - программа в целом полиморфна, а нужные фрагменты строго типизированы. Это - случай лиспа.

> Я бы всё же посоветовал немного освоить Common Lisp в практическом проекте. Тогда станет понятно.

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

Кроме того, у нас пошла очень интересная дискуссия насчет типизации.

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

ЕМНИП в сорсах bc есть парсер, с которого можно начать, а так же в доке к бизону. Но вообще парсеров пруд пруди.

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

ОК.

> Шаблоны не нужны - они являются частным случаем макросов... Программа, полиморфная по умолчанию, выражает более общие алгоритмы и поэтому её легче развивать.

Шаблоны -- это не только макросы, сколько именно реализация полиморфизма (вместе с вирт. функциями).

Впрочем, чисто синтаксически реализация шаблонов в плюсах далеко не идеал.

>type inference нужен, но он сложен и стоит времени компиляции.

local type inference не стоит ничего, и смотрится намного безопаснее глобального.

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

Вот это самый интересный (и неясный пока мне до конца) вопрос. Я считаю, что хранение и доступ следует отделить от типизации.

> Проект будет, ессно, делаться open-source. Тем не менее, я буду делать его для себя.

Я думаю что в варианте "программа в целом полиморфна, а нужные фрагменты строго типизированы" ты вполне проживешь без коммьюнити, так что можно и для себя :-)

www_linux_org_ru, по-моему, ты думаешь, что кроме тебя у меня не найдётся на свете других попутчиков? Уже второй раз ты пишешь, что "если ты не сделаешь так, как я говорю, то у тебя не будет комьюнити". Это просто смешно... Я хотел отметить это ещё прошлый раз, но решил для первого раза промолчать.

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

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

Насчёт augeas - да, это примерно то, что надо. Правда, я посмотрел на язык описания схем и не понял его (я не понимаю ml, хотя пытался ему научиться пару раз). В общем, это не важно.

В последнем варианте предлагается такой сценарий создания языка: 1. выделяем минимальное подмножество лиспа для хранения дерева лексем и реализации квазицитирования. 2. пишем/находим сначала самые простые лексеры. Они не будут знать грамматику языков, а будут просто собирать по уровням вложенности скобок (даже без приоритета операций). Может быть, понадобятся усилия для правильной конфигурации (разного рода инклюды могут понадобиться). 3. интегрируем квазицитирование в каждый из рассматриваемых языков способом, специфическим для этого языка. Для html это будут новые теги, для js - псевдофункции. Макрорасширители действуют над деревьями лексем.

Это - уже законченный продукт, имеющий практическую пользу и в чем-то превосходящий m4. Делаем сайт, пиаримся везде.

Далее, делаем "exclude" и научаемся совмещать несколько языков в одном файле.

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

Либо развивать библиотеки препроцессора.

Либо заниматься интеграцией препроцессора в интерпретируемые языки (например, переопределить function в javascript)

Либо усложнять модель вычислений (например, ввести partial evaluation с целью оптимизации порождаемого кода).

minifying. Скрытие сорсов.

Либо общая платформа, подобная хахе.

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

> но он сложен и стоит времени компиляции.

Он совсем не сложен (если это Хиндли-Милнер). Он даже проще чем type propagation в каком либо plain C.

Ну ладно, может быть, и не сложен. Лично я вряд ли буду вкладывать в это какие-то усилия. Если он вдруг сам как-то появится, то пусть будет.

> www_linux_org_ru, по-моему, ты думаешь, что кроме тебя у меня не найдётся на свете других попутчиков?

Не думаю. Все сложнее.

> Уже второй раз ты пишешь, что "если ты не сделаешь так, как я говорю, то у тебя не будет комьюнити".

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

Вот это например: Я думаю что в варианте "программа в целом полиморфна, а нужные фрагменты строго типизированы" ты вполне проживешь без коммьюнити, так что можно и для себя

следует читать так:

Я думаю что в варианте "программа в целом полиморфна, а нужные фрагменты строго типизированы" ты вполне проживешь без того большого коммьюнити, которое требуется для поддержания на плаву аналогичного проекта с полной строгой типизацией в объеме С++0х; кроме того, написание парсеров-не-линз настолько щас автоматизироно (и по сути просто), что можно их делать "для себя".

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

Сам по себе такой чисто динамический вариант den-а 73 будет вписываться в mainstream программированя для web - там сейчас чисто динамические языки, и действительно будет там гораздо более полезной вещью, чем M4.

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

(подумав, я решил, что и для строгой типизации коммьюнити не настолько важно, как мне казалось раньше)

> Он совсем не сложен (если это Хиндли-Милнер). Он даже проще чем type propagation в каком либо plain C.

Ну так кинь ссылочку на его хорошее объяснение или даже на standalone реализацию (не в составе компилятора).

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

> Либо усложнять модель вычислений (например, ввести partial evaluation с целью оптимизации порождаемого кода).

Да, для веб-программирования это явно напрашивается.

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

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

javascript не страдает от отсутствия пользователей? А есть ли у них выбор? Может, они могут эмбеддить в html какой-то другой язык?

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

________________________________________________

Везде в этой дисскусси, там, где я говорил "строгая" или "статическая" типизация я имел в виду "строгая статическая типизация".

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