Создатель Qi сворачивает проект

> Так сразу бы и сказал, что тебе кодогенератор на перле нужен

Причем он может быть, как не удивительно, type-aware, знать приоритеты, ассоциативность, ...

Например, нам нужен новый оператор, обозначаемый (+), с приоритетом обычного плюса.

Перлом мы его заменяем a+b*c(+)d на a+b*c+_my_operator_plus+d, и шаблонами уже доделываем все остальное.

> Задача Луговского: напиши LALR парсер шаблонами С++. Решение на Лиспе можно найти в гугле.

peg-парсеров (а они имхо удобнее) шаблонами на с++ уже несколько штук, вот например http://spirit.sourceforge.net/, YARD, PEGTL.

> Задача Луговского: напиши LALR парсер шаблонами С++. Решение на Лиспе можно найти в гугле.

Если действительно LALR парсер шаблонами С++ сделать невозможно, то мне интересно знать причину, и еще -- решение на лиспе ничем не лучше bison-а, ибо статической проверки типов нет (и, хотя и спорно, синтаксис извратный -- общелисповский, а не удобный конкретный)

> Люди из мира opensource все чаще и чаще начинают "трезветь".

Мдя... Оказывается тут половина присутствующих пьяная, а половина трезвая. Одни пытаются протрезветь, других тянет напиться...

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

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

До сегодняшнего дня я даже не знал, что такое Qi. А тут такое.

>> Еще раз: Тьюринг-полнота гарантирует реализацию любого алгоритма.

>В случае ray-tracer-а -- да, его можно написать на плюсовых шаблонах

Нет, нельзя. Начнем с того что float-ов в шаблонах нет.

>Нет, нельзя. Начнем с того что float-ов в шаблонах нет.

Во многих ЦПУ их тоже нет,

>> Задача Луговского: напиши LALR парсер шаблонами С++. Решение на Лиспе можно найти в гугле.

>Если действительно LALR парсер шаблонами С++ сделать невозможно, то мне интересно знать причину,

Напиши-узнаешь.

>и еще -- решение на лиспе ничем не лучше bison-а, ибо статической проверки типов нет

Суть - статическая: граматика конвертируется в код.

>>Не катит Scala по сравнению с ML-подобными.

>Отсюда поподробнее.

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

>>Нет, нельзя. Начнем с того что float-ов в шаблонах нет.

>Во многих ЦПУ их тоже нет,

На ассемблере писать трейсер элементарно. Только вот язык шаблонов С++ это язык типа Unlambda.

>Еще раз: Тьюринг-полнота гарантирует реализацию любого алгоритма.

А вот и нет. Задача останова не решается на тьюринг-полных.

> Нет, нельзя. Начнем с того что float-ов в шаблонах нет.

А с фиксированной запятой никак не выйдет? Или числитель/знаменатель хранить.

>Это вообще о чем? Услышал слово "макрос" ?

Да :) А то что-же получается: месил профессор всех с г*ном, только из-за того, что в лиспе можно "быстро лабать макросы"? А как же высокие идеи метапрограммирования и прочей лабуды? Пустышка.

одним больше , одним меньше

boost::spirit не годится, тк не работает полностью в компайл-тайм

> А M$ Research и INRIA сейчас работают над F# и на GHC c Ocaml'ом немного подзабили.

Не боись. Ского грядет Scala да и нативные языки никуда не денутся. Под тот же Haskell сейчас библиотеки клепают без устали.
Вот здесь - http://lionet.livejournal.com/37311.html интересное видео. Заодно привет Биореактору с его джавой ;)
*****кусь*****
А вот что говорит Yaron Minsky, программист из финансовой компании Jane Street Capital, которая практически полностью работает на OCaml'е. У них принят тотальный код-ревью, потому что речь идёт об автоматической торговле на миллиарды долларов в день, отсюда необходимость выбора правильного языка:
Я думаю, большая часть того, почему мы в конце концов остановили свой выбор на этой технологии, заключается в том, что те, кто был ответственным за принятие решений были теми же людьми, которые читали код. И я думаю, что это всё меняет в вашей организации, если вы имеете людей, которые серьёзно относятся к коду не только как к способу достижения результата, но как к средству самовыражения. Как к способу записи того, что ты имеешь ввиду, способу коммуникации с другими людьми о том, как, на твой взгляд, работает система.
В какой-то момент мы серьёзно задумывались о переносе отдельных критических систем из программ на VB сидящих в электронных таблицах в приятную, прилично действующую программу на C#. И одной из тех вещей, которая убила этот проект была сложность чтения этого чёртового кода, о котором мы так пеклись.
Там было две вещи, которые убили этот проект. Одной была многословность, факт того что там было настолько много строчек кода для чтения. А второй была то, что люди находили объектно-ориентированный подход настолько сложным для восприятия.
И почему мы думаем что OCaml был хорош для чтения (что очень хорошо помогает обеспечению корректности программ)? Ключевые вещи: краткость и типы.
*****грызь*****
И касательно F# тоже интересное http://ocaml.janestreet.com/?q=node/61 :
F# is good but its GC is not made with FP in mind, so it can't handle the allocation rate of FP and calling .NET method just raise the scary "NULL" pointer exception again

>>Еще раз: Тьюринг-полнота гарантирует реализацию любого алгоритма.

> А вот и нет. Задача останова не решается на тьюринг-полных.

А вот и да. Не существует алгоритма, решающего задачу останова.

эх, хорошо что это другой Qi, а не тот который загрузчик (氣) :3

Ты не знаешь контекста шутки. Так что, увы, мимо. Мне жаль, что я тебя расстроил.

> Задача останова не решается на тьюринг-полных.

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

>Там было две вещи, которые убили этот проект.

Хорошо что проект убили.

>А вот и нет. Задача останова не решается на тьюринг-полных.

общая задача распознавания грамматики нулевого типа по Хомскому - тоже. просто ты невнимательно читаешь: "гарантирует реализацию любого алгоритма" != "гарантирует решение любой задачи". алгоритм ~ эффективная процедура

> Суть - статическая: граматика конвертируется в код.

Пфф. Неспортивно. Ты мне сделай, чтоб оно и парсило компайл-тайм.

> она даже алгоритмически для общего случая вроде как не решена

Afair, доказано, что решения не существует.

Причем, доказательство есть в классических учебниках.

Это F# ML-подобный? В интерпрайзе не нужна элитарность ML-подобных, там работу делать надо. Расскажи Oracle-овцам, что они должны переписать Oracle на ML, Ocaml, Haskell, Nemerle, чтобы быть элитарными, они, возможно, рассмотрят варианты

> На ассемблере писать трейсер элементарно. Только вот язык шаблонов С++ это язык типа Unlambda

Согласен. И что дальше?

1. написать принципиально можно

2. написать полностью бессмыслено, даже в D

Если алгоритму на вход дается тупая строчка из исходников, то ее проще выковырить перлом и потом рейтресить -- можно сделать мемоизацию результата например -- как у нас в Д с мемоизацией? (хотя в с++0х ввели функции для вычислений времени компиляции). Шаблоны и метапрограммирование имеют смысл тогда, когда нужно много чего знать об исходнике, что знает компилятор, и/или много чего сообщать обратно в виде варнингов и ошибок.

>> Если действительно LALR парсер шаблонами С++ сделать невозможно, то мне интересно знать причину,

> Напиши-узнаешь.

Слишком накладно, к тому же у меня подозрение, что это можно сделать.

>> Суть - статическая: граматика конвертируется в код.

>Пфф. Неспортивно. Ты мне сделай, чтоб оно и парсило компайл-тайм.

Что может помешать парсить компайл-тайм если в макросах доступны функциии IO ?

> Что может помешать парсить компайл-тайм если в макросах доступны функциии IO ?

Так оно умеет парсить компайл-тайм, или нет? :D

> и еще -- решение на лиспе ничем не лучше bison-а, ибо статической проверки типов нет

> Суть - статическая: граматика конвертируется в код

в бизоне тоже самое: "Суть - статическая: граматика конвертируется в код", и чем тогда лисп выигрывает?

> As a professional friend of mine said ‘Free open source is free if your time is worth nothing.’ Unfortunately my time is worth something.

Человек просто стареет и начинает ценитиь свое время. Его у него остается все меньше и меньше... :(

> И чем можно заниматься в такой убогой стране как Индия?

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

> As a professional friend of mine said ‘Free open source is free if your time is worth nothing.’ Unfortunately my time is worth something.

Лузер.

Если ты делаешь никем не востребованную хрень, то действительно worth nothing. Если твоя хрень кем-то востребована, то пойди и возьми с него денег. Откуда, по его мнению, появляются фулл-тайм разрабы foss? И почему у них е-мейлы на redhat.com, sun.com, ibm.com, и так далее?

Жалобы такого рода адекватно звучали бы из уст fundamental science ученого, так как желающих хорошо инвестировать в проекты с невнятной отдачей через 50 лет - действительно хрен найдешь.

эх EPIC FAIL, жаль мужика.

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

Ну например есть список типов вида < <a b c> <a s d> <a u g> <b b c> <b s d> <c b c> <c s d> >.

1) Надо сгруппировать по первому элементу, то есть получить < <a <b c> <s d> <u g> > <b <b c> <s d> > <c <s d> > > . Если бы можно было завести хэштейбл вида head-tail задача былы бы тривиальна

2) Надо вывести их этого сгруппированного списка код вида(*) шаблоном с параметрами arg1 и arg2

switch (arg1) {
case a:
  if (strcmp (arg2, "b")) == 0) {
    c();
  } else if (strcmp (arg2, "s")) == 0) {
    d();
  } else if (strcmp (arg2, "u")) == 0) {
    g();
  } else {
    throw SomeError();
  }
  break;
case b:
  if (strcmp (arg2, "b")) == 0) {
    c();
  } else if (strcmp (arg2, "s")) == 0) {
    d();
  } else {
    throw SomeError();
  }
  break;
case c:
  if (strcmp (arg2, "b")) == 0) {
    c();
  } else {
    throw SomeError();
  }
  break;
default:
  throw SomeError();
}

3) Сделать обработку типа def: в случае попадания его в голову подсписка помещать его в кейс default оператора switch вместо кидания исключения, в случает попадания во вторую позицию - в кейс else.

> boost::spirit не годится, тк не работает полностью в компайл-тайм

PEGTL похоже работает... а откуда дровишки насчет boost::spirit?

The PEGTL uses compile-time polymorphism (i.e. templates; rather than run-time polymorphism, i.e. interface classes and virtual functions), where grammars are created by instantiation of class templates. Until an appropriate extension is written, it might not be well suited to applications that need to create and/or change grammars at run-time.

> А вот что говорит Yaron Minsky, программист из финансовой компании Jane Street Capital

ч0рт, ну неужели кроме Jane St и группы в Citrix никто не пишет на Ocaml? :/

>> и еще -- решение на лиспе ничем не лучше bison-а, ибо статической проверки типов нет

>> Суть - статическая: граматика конвертируется в код

>в бизоне тоже самое: "Суть - статическая: граматика конвертируется в код", и чем тогда лисп выигрывает?

Ну на этот случай есть Вторая задача Луговского: написать С++ на С++. Компилятор Си без плюсов в байткод абстрактной стековой машины есть в любом серьезном учебнике по yacc.

очень многа буков...

придумать можно много, но нафига это практически нужно?

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

>> boost::spirit не годится, тк не работает полностью в компайл-тайм

> а откуда дровишки насчет boost::spirit

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

Изначально же Absurd просил не "напиши построитель парсеров шаблонами C++" (нечто, что создает парсер компайл-тайм, это как раз spirit), а "напиши парсер шаблонами C++" (нечто, что парсит компайл-тайм).

Скорее всего, я неверно истолковал просьбу Absurd-а. Предлагаю забить :)

> Ну на этот случай есть Вторая задача Луговского: написать С++ на С++.

man gcc :D

>придумать можно много, но нафига это практически нужно?

Это кусок макроса для создания парсера, например: сначала switch по типу токена, затем проверка содержимого токена.

> Ну на этот случай есть Вторая задача Луговского: написать С++ на С++. Компилятор Си без плюсов в байткод абстрактной стековой машины есть в любом серьезном учебнике по yacc.

Детская игрушка, которую называют "лисп на лиспе", не имеет никакого отношения к реальному лиспу с рестартами, исключениями, континуейшенами, eval-when и прочей довольно низкоуровневой фигней. Попробуй *его* написать на лиспе... сомневаюсь что выйдет красиво.

Хотя да, с++ на с++ тоже хреново выйдет.

>> Ну на этот случай есть Вторая задача Луговского: написать С++ на С++. Компилятор Си без плюсов в байткод абстрактной стековой машины есть в любом серьезном учебнике по yacc.

>Детская игрушка, которую называют "лисп на лиспе", не имеет никакого отношения к реальному лиспу с рестартами, исключениями, континуейшенами, eval-when и прочей довольно низкоуровневой фигней.

Речь пока идет о Си на Си vs Си++ на Си++. Ну можно PyPy еще взять, например.

> Речь пока идет о Си на Си vs Си++ на Си++.

Да, c++ - сложный язык, и за пару дней даже парсилку для него не написать. Ни на c++, ни на лиспе, ни на брейнфаке. И даже yacc и bison-ом не спасут. А нахрена вообще это надо? И причем тут шаблоны?

> Речь пока идет о Си на Си vs Си++ на Си++. Ну можно PyPy еще взять, например.

Думаю, brainfuck на brainfuck будет еще короче. И что?

зачем переписывать-то? то, что уже написано пусть работает, а новые вещи можно писать, без особых проблем.

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

>> Речь пока идет о Си на Си vs Си++ на Си++.

>Да, c++ - сложный язык, и за пару дней даже парсилку для него не написать.

Ну это на самом деле важно. Для чего ведь написали PyPy? Чтобы непринужденно экспериментировать с реализациями разных фич языка Python. А для С++ даже Майкрософт не осилила нормальных комплишенов вплоть до ~седьмой версии VC. В шестой вижуал студии все это хозяйство постоянно отваливалось превращая VC++ в gedit. На CDT ушло лет десять.

Оне не лузер, он - дауншифтер. :)

Тут смесь всего -- и осознания ненужности содеянного и старческое брюзжание. А лузер или нет -- я не знаю. Если человек заработал себе на пенсию (пусть даже и) в Индии, так и не такой уж он и лузер... В Индии тепло и дешево, почему бы там и не жить на пенсии... :)

> Откуда, по его мнению, появляются фулл-тайм разрабы foss? И почему у них е-мейлы на redhat.com, sun.com, ibm.com, и так далее?

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