Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 17.09.07 13:24
Оценка: :))) :))) :))) :))) :))) :))) :))) :))
Имею желание разработать язык следующего, за С++, поколения, являющегося его идейным потомком и его же убийцей.
Идейную наследственность вижу в кардинальном усилении метапрограммной составляющей. Одновременное, с этим, кардинальное удаление С рудиментов должно породить язык необычайной выразительной мощи.
Ищу единомышленников, которые помогут мне в моих грандиозных планах
Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'
от любви до ненависти...
Re[2]: Разработка языка-убийцы С++
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.09.07 14:48
Оценка: 21 (1) +4 :))) :))) :)))
Здравствуйте, konsoletyper, Вы писали:

K>Боюсь, ты опоздал. Есть Ruby, Nemerle, Template Haskell, Scheme, D и т.д. Зачем тебе ещё один?


Очевидно, у них у всех есть фатальный недостаток.
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re: Разработка языка-убийцы С++
От: WolfHound  
Дата: 17.09.07 16:38
Оценка: 2 (2) +4 -1 :)
Здравствуйте, Cpphater, Вы писали:

C>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

С++ очень плохо подходит для разработки компиляторов.
И вобще ИМХО язык нужно писать на самом себе.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Разработка языка-убийцы С++
От: Awaken Украина  
Дата: 17.09.07 14:07
Оценка: +2 -1 :)))
C>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

назови его VladD2++
Re: Разработка языка-убийцы С++
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 17.09.07 13:45
Оценка: +2 :)))
Здравствуйте, Cpphater, Вы писали:

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




Заимей его до смерти. Не дай ему шансов.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[5]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 17.09.07 16:43
Оценка: +1 -3 :)
Здравствуйте, Cpphater, Вы писали:

C>Ни один из них не является идейным потомком С++. Одни подслащают жизнь в отдельных областях, другие делают кодирование безопасным, третьи вообще чисто функциональные. Ни один из них не может рассматриваться как революционный шаг вперёд. Ни один из них не эффетивен как С. Продолжение будет следовать...


Ну, C++ в таком случае тоже не был революционным. Типа, ООП придумали не в нём (МП — тоже). И по поводу идейности непонятно. Если под идеей C++ подразумевается высокая эффективность при сохранении достаточно высокого уровня, то тут масса последователей: Java, C#, Nemerle, OCaml. Если под идеей подразумевается сложность написания программ — тогда тебе прямая дорога к branfuck. Если сложность изучения — то Perl. Если трахи с метапрораммными наворотами — то прямая дорога к Haskell без Template.
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re: О языках-убийцах
От: x-code  
Дата: 22.09.07 11:17
Оценка: 1 (1) +2 -1
Здравствуйте, Cpphater, Вы писали:

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

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

Не вижу смысла придерживаться идеологии С++. Меня в последнее время очень заинтересовала функциональная парадигма, но не "чисто функциональная" (которая, ИМХО, скорее применима для математиков и ученых в прикладных пакетах типа матлаба), а комбинированная, реализованная в Scala и Nemerle. Ну и макросы Немерле — самая мощная метапрограммная система из всех, какие я знаю.

В С++ есть недостатки, мне этот язык нравится из-за того, что при всех его возможностях в нем остается низкоуровневость. Java и C# годятся для офисных программ, но не для настоящего системного программирования. И пусть говорят, что JIT-компиляция круче обычной... Она не круче, она просто другая. И любой язык-убийца должен поддерживать оба типа компиляции, причем желательно — одновременно в одном проекте.

Все разработчики новых языков не учитывают одной простой вещи: для того, чтобы реальные программисты стали писать на новом языке программы, красоты и выразительности самого языка недостаточно. Нужно, чтобы этот язык как можно более гладко интегрировался в существующий процесс разработки. В идеале, программист скачивает инсталляшку некоего языка "X", запускает ее — и вуаля, в Visual Studio (или в любой другой распространенной IDE) появлялись пункты "Add new "X" file to project", в MSDN — подробнейшая справка по языку "X" (желательно еще и переведенная на родной язык разработчика!) и пара учебников с примерами, при компиляции компилятор файлы *.cpp компилирует С++-овским компилятором, а файлы "X" — новым "X"-овсым, линкер корректно линкует разные объектники в один exe-шник... Нужно чтобы в файлах нового языка можно было свободно использовать все без исключения библиотеки того же С/С++, чтобы с новым языком работал отладчик, подсветка синтаксиса, автокомплит...

Вот если все эти условия будут выполнены, тогда и появится язык-убийца.
Re[2]: Разработка языка-убийцы С++
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 17.09.07 14:21
Оценка: :))) :)
Здравствуйте, Awaken, Вы писали:

C>>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'


A>назови его VladD2++


Это лишнее. По моему — Язык-убийца Тани — вполне нормально
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[2]: первый шаг убийцы
От: Smal Россия  
Дата: 20.09.07 06:23
Оценка: +1 :))
Здравствуйте, Cpphater, Вы писали:

C>Развёрнута SVN по адресу: http://tools.assembla.com/svn/Tany

C>а также Track по адресу: http://tools.assembla.com/Tany , правда он пока что пуст

Люблю я этих программистов. Любой проект начинают с кода .
А потом где-то через год родят концепцию, опишут архитектуру и т.п.
С уважением, Александр
Re: Разработка языка-убийцы С++
От: artkarma  
Дата: 19.10.07 09:18
Оценка: :)))
Убей ещё и PL\SQL — заипал он меня
Re: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 17.09.07 14:16
Оценка: :))
Здравствуйте, Cpphater, Вы писали:

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

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

Боюсь, ты опоздал. Есть Ruby, Nemerle, Template Haskell, Scheme, D и т.д. Зачем тебе ещё один?
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[4]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 17.09.07 16:15
Оценка: +1 -1
Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, AndrewVK, Вы писали:


K>>>Боюсь, ты опоздал. Есть Ruby, Nemerle, Template Haskell, Scheme, D и т.д. Зачем тебе ещё один?


AVK>>Очевидно, у них у всех есть фатальный недостаток.

КД>Я, я знаю какой Ну спросите, спросите меня
Спрашиваем, но сами тоже ответим
Ни один из них не является идейным потомком С++. Одни подслащают жизнь в отдельных областях, другие делают кодирование безопасным, третьи вообще чисто функциональные. Ни один из них не может рассматриваться как революционный шаг вперёд. Ни один из них не эффетивен как С. Продолжение будет следовать...
от любви до ненависти...
Re[5]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 09.11.07 10:23
Оценка: +2
Здравствуйте, vdimas, Вы писали:

V>А для программы компилятора они зачем???

Нет ничего лучше для работы с AST.

V>Табличные LL(k) рулят. И не переубедишь.

И куда они рулят?

V>Для автоматного подхода к лексеру и парсеру имеющихся хватает с головой.

Кроме того что программу нужно пошенковать на токены для компиляции нужно сделать еще очень много чего.
Скажем в томже AST есть куча тупого кода который прекрасно генерится по структуре этого самого AST.

V>Ну приплыли. И кому же это сборщик понадобился? Лексеру или парсеру? Или древовидным, монотонно растущим словарям?

V>Если программе-компилятору нужен сборщик мусора, то это какой-то наколенно-склёпанный компилятор.
Скажи это разработчикам немерле.
Только сначала повтори компилятор немерле на С++.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 17.09.07 18:22
Оценка: 1 (1)
Здравствуйте, c-smile, Вы писали:

WH>>С++ очень плохо подходит для разработки компиляторов.

CS>Чё так?
Ни алгебраических типов.
Ни сравнения с образцом.
Ни нормальных макросов.
Ни сборщика мусора.
...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Разработка языка-убийцы С++
От: Smal Россия  
Дата: 20.09.07 06:19
Оценка: 1 (1)
Здравствуйте, Glagolev, Вы писали:

G>Здравствуйте, WolfHound, Вы писали:


WH>>Здравствуйте, Cpphater, Вы писали:


C>>>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

WH>>С++ очень плохо подходит для разработки компиляторов.
WH>>И вобще ИМХО язык нужно писать на самом себе.

G>ага, прям сразу на самом себе

Ничего смешного. Когда Вирт Паскаль придумывал (с Мейером, кажется), они сначала
написали код компилятора на Паскале, а потом отправили своего ассистента в 2-х недельный отпуск,
чтобы он там в машинные коды все перевел вручную.
С уважением, Александр
Re[8]: Разработка языка-убийцы С++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 19.10.07 05:04
Оценка: 1 (1)
Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, _Obelisk_, Вы писали:


_O_>>Я писал вывод типов, семантический анализаторы, трансформации AST-ов в иное представление и др.


K>И как, всё было просто, или прошлось опираться на костыли?


Зависело от задач.

K>Вот и я про то же. Но если их не юзать, то паттерн матчинг мало поможет, и ФЯ почти не даст выигрыша перед ИЯ без паттерн-матчинга.


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

K>А чем он круче кроме скорости и error handling?


Наличие языка для описания AST-а (на самом деле не только AST-а но и других, подобных структур), наличие языка для написания трансформаций AST-а (с pattern matching-ом), наличие языка для описания attribute evaluators для AST-ов. Возможность генерации парсеров с множеством точек входа. Генерит хорошую информацию о конфликтах в грамматике. Для AST-ов генерятся механизмы сериализации/десериализации и визуализации AST-а. Есть примочка, автоматически выводящая спецификацию для сканнера из грамматики.
Есть библиотека со всякими полезными штуками для решения сопутствующих задач возникающих при создании компиляторов (хэширование строк, управление памятью и др)
Хорошая документация и примеры. Плюс поддержка со стороны разработчиков. Но, к сожаленью, тул платный (есть какая-то бесплатная версия, но сильно убогая)

_O_>>- должна быть нормальная система восстановления после ошибок и репорт о синтаксических и лексических ошибках


K>Это вообще проблема нерешённая. Всякие Cocktail просто предоставляют хорошую эвристику. Тонны кода тут ничего не решают.


Главное, что тот же Cocktail берет заботу об этом на себя и решает ее на хорошем уровне.

_O_>>- парсер должен уметь парсить файлы в формате UTF-8 и UTF-16

K>И это проблема?

Нет, но надеюсь, ты не забыл, что в тексте программы могут присутствовать символы в виде \u01d7 \u01e0 и т.д ? Сканер должен такое поддерживать.

K>Может и не требуешь, но компилятор — это далеко не только парсер. То, что ты назвал, как правило реализуется дольше и сложнее, чем парсер/лексер. И в данном случае сопоставление с образцом, сборщик мусора и т.д. являются неплохим подпорьем.


Задачи из области разработки компиляторов возникают отнюдь не только при разработки компиляторов. У нас они возникают при создании генераторов из формальных моделей, импорта и трансформации программ (source-to-source transformations), создании таких фич как IntelliSense, поддержка рефакторинга и т.п
Собственно сейчас околокомпиляторных задач гораздо больше, чем потребности в разработки именно новых компиляторов.

K>Ни одного. Исключительно в самообразовательных целях. Возможно, мне ещё придётся писать парсер для коммерческого проекта. Так же планирую написать компилятор ML-образного языка для диплома, на OCaml. За парсер боюсь меньше всего, т.к. это штука простая. Вот разобраться в суперкомбинаторах и G-машине — это посерьёзнее будет... Зато я уже успел написать два генератора парсеров (один на Nemerle, можно найти в соотв. форуме). Кстати, если его доработать (вообще, серьёзно доработать), то можно запросто покрыть названные тобой пункты гораздо меньшим числом строк, чем 9К. Кстати, это всё благодаря тому, что в своём генераторе я ориентировался на преимущества, предоставляемые ФЯ.


То, что сам написал пару генераторов, это похвально
Только еще раз повторю — 9К — это с выводом типов, разрешением имен и таблицей символов. Собственно парсер со сканнером там где-то 2700 занимают.

А твой генератор парсеров какие парсеры генерит ? LL, LR(k), LALR(k) ? Детектит ли он конфликты в грамматике и какую информацию выдает ? Предоставляет ли средства для динамического резолвинга конфликтов ? Содержит ли какой-нибудь язык для описания AST-ов ? Имеются ли возможности для задания правил вычисления атрибутов в AST-е ?
Сделать в самообразовательных целях генератор парсеров не трудно. А вот сделать из этого продукт и довести до ума — тяжело. Я верю, что всегда можно сделать тул круче уже существующих. К сожаленью, это происходит редко. Плюс того же Cocktail-я в том, что это интегрированная система тулов, в которых каждый тул с каждым легко соеденить. Проектирование такой архитектуры требует времени (Cocktail с 1988-го года развивается)

Когда я учился в универе, мне казалось, что все можно написать за пару ночей (и ведь действительно писалось!) Потом реализм наступил.

P.S.
Хочешь задачку, полезную для общества ? — Подумай надо созданием UML Virtual Machine. Т.е. над машиной, которая могла бы интерпретировать UML-модели (только бери последнюю версию стандарта, где action semantics есть). Это позволит симулировать модели без необходимости кодогенерации исполняемого приложения. А симуляция моделей — вещь нужная всяким военным, аэрокосмическим, телекоммуникационным компаниям (правда западным, не нашим).



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[12]: Разработка языка-убийцы С++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 19.10.07 18:41
Оценка: 1 (1)
Здравствуйте, konsoletyper, Вы писали:

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


K>Любой — это какой?

Любой, общего назначения. Просто специализированные языки на то и специализированные, чтоб облегчать реализацию специальных задач.

_O_>>Я на С++ такое делал. C#/Java работу сильно не облегчат.


K>Сомневаюсь.


А я нет Но пусть все останутся при своем мнении.

K>Ну дык, для литералов тип заранее неизвестен. А идентификаторы как? Там обязательна аннотация типов? Тогда вывод типов не такой и сложный. Даже в языках с необязательной аннотацией типов используется достаточно простой алгоритм, основанный на унификации, но только в случае системы типов Хиндли-Милнера. А вот если берём другую систему типов (Nemerle) или расширяем её (Haskell) получаются жуткие навороты...


Тип литералов известен в таких языках, как С++, C#, Java и др. 1 — это целое, 2.3 — вещественное и т.д.

В SDL алгебраическая система типов. Проблема заключается в том, что тип выражения зависит от всего контекста. Т.е. для выражения "a = b + 1" строится множество все видимых в данном месте объектов с именами 'a', 'b', '=', '+', '1'. Дальше это множество редуцируется, если остались единственные объекты для имен 'a', 'b', '=', '+', '1', то они и выбираются. В результате может получиться, что тип '1' будет определяться типом 'b'.
Что мне в такой системе не нравится, так это то, что выражение '1 + 1' выдает ошибку, т.к. существует несколько типов с литералом '1'.
Я делал кодогенератор из модели, в которой используется С++-образная система типов, в этот SDL. Извратные правила с выводом типов и правила видимости доставляли хлопот. С тех пор не люблю алгебраической подход к описанию типов.

_O_>>У тебя генератор поддерживает задание каких-либо condition-ов на правила в грамматике для динамического резолвинга подобных конфликтов ?


K>Нет. А разве для первого случая возможно что-то определённое сказать, не сделав семантического анализа? Как в данном случае поступают?


Ну оставить на этап семантического анализа можно, только в некоторых случаях можно определить тип конструкции на уровне парсера ( скажем, binary expression "(T) / 10" не является преобразованием типа). Для тех случаев, когда можно, делаются предикаты, проверяющие условия. Соотв. правила в спецификации для парсера будут иметь condition-ы, использующие эти предикаты. Там есть еще какие-то фичи, я глубоко не копался

K>Для меня это общие слова. Можно ссылочку или конкретную ситуацию описать? А то я не догоняю...


Есть, например, задача source-to-source transformation из языка А в язык Б. Как делать будем ? Очевидно, что лучше трансформировать одно абстрактное синтаксическое дерево в другое. Затем просто обойти дерево и pretty-printing-ом сгенерить программу на языке Б.
Наличия языка описания AST-ов упрощяет такую деятельность. При описании AST-а мы можем сконцентриоваться именно на самом AST-е и переложить всю рутину на плечи генератора AST-а.
Например, AST для expression-ов из С# выглядит в виде спецификации для Cocktail-я так

expression      = <
  noexpr        = .
  expression_c      = [bpos: tPosition] [epos: tPosition] <
    qualified_symbol    = [ident: tWIdent] <
      noname        = .
      ident     = .
      alias_ident   = .
      qualification = [pos: tPosition] qualified_symbol .
      generic_symbol    = type_arg_list <
    generic_ident   = .
    generic_member  = [pos: tPosition] qualified_symbol .
      > .
    > .
    aggregate_expr  = expression_list .
    anonymous_expr  = parameter_list: decl_list statement_list .
    assign_expr     = lval: expression_c rval: expression_c
              [Operator: toperator] [pos: tPosition] .
    as_expr     = expression: expression_c type .
    base_expr       = .
    binary_expr     = lop: expression_c rop: expression_c
              [Operator: toperator] [pos: tPosition] .
    call_expr       = expression: expression_c expression_list .
    cast_expr       = type expression: expression_c .
    checked_expr    = expression: expression_c .
    conditional_expr    = condition: expression_c true_expr: expression_c
              false_expr: expression_c .
    default_expr    = type .
    is_expr     = expression: expression_c type .
    member_access_expr  = [ident: tWIdent] [pos: tPosition] type_arg_list <
      ptr_member_expr   = expression: expression_c .
      select_expr   = expression: expression_c .
      type_member_expr  = type .
    > .
    new_array_expr  = type expression .
    new_expr        = type expression_list .
    null_expr       = .
    parentheses_expr    = expression: expression_c .
    sizeof_expr     = type .
    stackalloc_expr = type expression .
    subscript_expr  = base: expression_c expression_list .
    this_expr       = .
    typeof_expr     = type .
    unary_expr      = expression: expression_c
              [Operator: toperator] [pos: tPosition] .
    unchecked_expr  = expression: expression_c .
    literal     = <
      bool_literal  = [value: rbool] .
      sr_literal    = [value: tWStringRef] <
    int_literal = [int_value: us_long] .
    real_literal    = .
    char_literal    = .
    string_literal  = .
      > .
    > .
  > .
> .


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

FUNCTION TranslateExpression (expression) {Cu2Expression*}

noexpr(...) :- RETURN 0;.

this : qualified_symbol(...) :- RETURN TranslateIdentExpr(this); .

this : aggregate_expr(expression_list := expression_list) :-
    result : {Cu2ListExpr*};
    {
        result = new Cu2ListExpr;
        TranslateExpressionList(expression_list,result);
    };
    RETURN result;
    .

this : anonymous_expr(parameter_list := parameter_list, statement_list := statement_list) :-
    result : {Cu2DelegateImplExpr*};
    {
        result = new Cu2DelegateImplExpr;
        Cu2Operation* pOperation = new Cu2Operation;
        result->m_cslOperation.Set(pOperation);
        TranslateDeclarationList(parameter_list,this,pOperation);
        UnsetAndPushProp(TranslateValueAsExpr);
        TranslateStatementList(statement_list,this,MakeActionContext(pOperation));
        PopContextProp();
    };
    RETURN result;
    .

this : assign_expr(lval := lval, rval := rval, Operator := Operator) :-
    RETURN 
        {           
            MakeBinaryExpr(TranslateExpression(lval),
                           COperatorsMapper\::MapOperator(Operator,true), 
                           TranslateExpression(rval)
                           )
        };
    .    

this : as_expr(expression := expression, type := type) :-
    RETURN MakeAsExpr(TranslateExpression(expression), TranslateType(type));
    .    

this : base_expr (...) :- 
    RETURN {new Cu2BaseExpr() };
    .

и т.д (не могу все показывать, ибо (c) )


Конструкция вида

this : assign_expr(lval := lval, rval := rval, Operator := Operator) :-


задает паттерн, который срабатывает, если expression-ом ему соотвествует.

K>Читал в красном драконе. А при чём тут это?


Ну Cocktail содержит спец. средство для генерации attribute eveluator-ов. У нас на нем весь name resolution & type checking для языка TTCN-3 построен.

K>У меня тоже времени на разработку собственных идей не хватает. Работа


Ух, понимаю.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[6]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 12.11.07 09:17
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

WH>Нет ничего лучше для работы с AST.


А прямое обращение к типизированным данным чем хуже?


V>>Ну приплыли. И кому же это сборщик понадобился? Лексеру или парсеру? Или древовидным, монотонно растущим словарям?

V>>Если программе-компилятору нужен сборщик мусора, то это какой-то наколенно-склёпанный компилятор.
WH>Скажи это разработчикам немерле.
WH>Только сначала повтори компилятор немерле на С++.

Немерле разработан ради работы в составе платформы. Я всё-равно не услышал, зачем конкретно в программе-компиляторе постоянно выделять и затем уничтожать временные куски памяти? Сдаётся мне, что компилятор должен только выделять память, а освобождать в конце своей работы.
Re[3]: Разработка языка-убийцы С++
От: lexis_t  
Дата: 22.11.07 10:27
Оценка: 1 (1)
Если представить, что каждая функция — это специальный класс, а при вызове функции на стеке создается объект с типом функция-класс...
Таким образом появляется возможность адресовать переменные, лежащие выше по стеку, если имеется указатель на кадр стека и конкретный тип (то есть класс-функция).
Фактически для компилятора ничего не поменяется, в стеке будут лежать все те же локальные переменные (упакованные в класс), но при обработке исключительной ситуации будет теоретическая возможность добраться до их значений (до раскручивания стека) и даже исправить! А потом восстановить прежнюю точку выполнения и продолжить как ни в чем не бывало!
Re[2]: Разработка языка-убийцы С++
От: dr.Chaos Россия Украшения HandMade
Дата: 17.09.07 14:49
Оценка: :)
Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Cpphater, Вы писали:


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

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

K>Боюсь, ты опоздал. Есть Ruby, Nemerle, Template Haskell, Scheme, D и т.д. Зачем тебе ещё один?


И че все убийцы?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[3]: Разработка языка-убийцы С++
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 17.09.07 15:01
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

K>>Боюсь, ты опоздал. Есть Ruby, Nemerle, Template Haskell, Scheme, D и т.д. Зачем тебе ещё один?


AVK>Очевидно, у них у всех есть фатальный недостаток.

Я, я знаю какой Ну спросите, спросите меня
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[2]: Разработка языка-убийцы С++
От: Glagolev Россия  
Дата: 17.09.07 17:35
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Cpphater, Вы писали:


C>>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

WH>С++ очень плохо подходит для разработки компиляторов.
WH>И вобще ИМХО язык нужно писать на самом себе.

ага, прям сразу на самом себе
Re[3]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 17.09.07 17:45
Оценка: +1
Здравствуйте, Glagolev, Вы писали:

G>ага, прям сразу на самом себе

Ну например компилятор Java написан на Java...
И вобще это весьма распространенная практика.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Разработка языка-убийцы С++
От: c-smile Канада http://terrainformatica.com
Дата: 17.09.07 17:53
Оценка: :)
Здравствуйте, Cpphater, Вы писали:

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

C>Идейную наследственность вижу в кардинальном усилении метапрограммной составляющей. Одновременное, с этим, кардинальное удаление С рудиментов должно породить язык необычайной выразительной мощи.
C>Ищу единомышленников, которые помогут мне в моих грандиозных планах
C>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

А чем D конкретно не устраивает в качестве могильщика?
Чем могильщица Таня будет принципиально лучше?
Re[3]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 17.09.07 19:23
Оценка: -1
Здравствуйте, Cpphater, Вы писали:

C>Обобщая различные концепты С++,

Чего простите?
C>я пришел к выводу, что язык должен иметь "микроядерную" архитектуру.
Что такое микроядерная архитектура ядра? Lisp?
C>Микроядро будет относительно простым и написанным на С++.
Никокого С++. Язык нужно писать на самом себе.
См http://nemerle.org/svn/nemerle/trunk
C>На нём, но в терминах языка будут вводиться имплементации таких понятий как пространства имён, классов, функций и их взаимосвязей.
Те каждый раз писать свой язык?
C>Собственно микропрограммы могут писаться по-разному, соответственно порождая разные диалекты Tany.
Кошмар. Сказку про Вавилонскую башню помнишь?
Кстати одна из главных проблем С++ это куча диалектов.
Но С++ уже большой и хоть с трудом но это переживает. А вот твой язык сдохнет сразу.
C>Например TanyJ, TanyC, Tany# которые могут рассматриваться как метапрограммные надстройки над Java, C++, C#. Но меня в первую очередь интересует создание TanyC как замена С++. Результатои работы компилятора Tany, для первых версий компилятора, будет код на С/C++ (для TanyJ был бы Java).
Смотри R# http://rsdn.ru/projects/rsharp/article/rsharp_mag.xml
Проект умер... ибо тупик.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Разработка языка-убийцы С++
От: Коваленко Дмитрий Россия http://www.ibprovider.com
Дата: 17.09.07 20:45
Оценка: :)
Здравствуйте, Cpphater, Вы писали:

Слушай, Cpphater, ты бы что ли пустые строки вставлял между своими и чужими мыслями. Будет проще читать... А то я так совсем передумаю быть твоим единомышленником.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[4]: Разработка языка-убийцы С++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.10.07 07:42
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, c-smile, Вы писали:


WH>>>С++ очень плохо подходит для разработки компиляторов.

CS>>Чё так?
WH>Ни алгебраических типов.
WH>Ни сравнения с образцом.
WH>Ни нормальных макросов.
WH>Ни сборщика мусора.
WH>...

При разработки трансляторов лучше пользоваться генераторами кода. Удобней, проще, надежней.
Для C/C++ есть море, проверенных временем, тулзовин, генеращих парсреры, лексеры, асты, и т.д. Там есть и сопоставление с образцом и удобный способ описания астов, грамматик, трансформаций астов, вычисления атрибутов в астах и т.д.

Скажем, у нас есть полный парсер C# 2.0, с поддержкой препроцессора (его конструкции представлены в АСТе), полным разрешением имен, таблицей символов, построением АСТа, в котором находится даже комменты, возможностью парсинга файлов в формате UTF-8/UTF-16/ASCII. Парсер сделан с использованием средства Cocktail (генерит код на С). Объем всех исходников всего около 9000 строк (учитывая пустые строки и комментарии). Работает быстро, памяти жрет мало, расширять/дополнять удобно, выдаются исчерпывающие сообщения об синтаксических ошибках.

Тоже самое для MSIL-а — где-то 2700 строк.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[5]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 18.10.07 15:39
Оценка: +1
Здравствуйте, _Obelisk_, Вы писали:

WH>>Ни алгебраических типов.

WH>>Ни сравнения с образцом.
WH>>Ни нормальных макросов.
WH>>Ни сборщика мусора.
WH>>...

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

_O_>Для C/C++ есть море, проверенных временем, тулзовин, генеращих парсреры, лексеры, асты, и т.д. Там есть и сопоставление с образцом и удобный способ описания астов, грамматик, трансформаций астов, вычисления атрибутов в астах и т.д.

Гы... И ты думаешь, всего этого достаточно? И ты думаешь, что при лексическом анализе паттерн матчинг сильно помогает? А ты не задумывался, что нужно ещё сделать проверку (вывод) типов, перевести AST в промежуточное представление (а может быть, и в несколько промежуточных представлений — например, сначала в лямбду а затем в комбинаторы), сгенерить код? Не говоря конечно об оптимизациях.

_O_>Скажем, у нас есть полный парсер C# 2.0, с поддержкой препроцессора (его конструкции представлены в АСТе), полным разрешением имен, таблицей символов, построением АСТа, в котором находится даже комменты, возможностью парсинга файлов в формате UTF-8/UTF-16/ASCII. Парсер сделан с использованием средства Cocktail (генерит код на С). Объем всех исходников всего около 9000 строк (учитывая пустые строки и комментарии). Работает быстро, памяти жрет мало, расширять/дополнять удобно, выдаются исчерпывающие сообщения об синтаксических ошибках.


Ну и? Он только парсить умеет? Тогда что-то много 9000 строк. Ты что ли учёл сгенерированны код? Я бы в 2-3К строк уложился, будь у меня правильный генератор (из нах — 0.5К — только одна грамматика). А то все эти генераторы страдают похожестью на yacc.

_O_>Тоже самое для MSIL-а — где-то 2700 строк.


И это повод для гордости?
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[13]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 19.10.07 20:05
Оценка: +1
Здравствуйте, _Obelisk_, Вы писали:

K>>Любой — это какой?

_O_>Любой, общего назначения. Просто специализированные языки на то и специализированные, чтоб облегчать реализацию специальных задач.

Я знаю это. Ты про какие именно языки говоришь?

K>>Для меня это общие слова. Можно ссылочку или конкретную ситуацию описать? А то я не догоняю...


_O_>Есть, например, задача source-to-source transformation из языка А в язык Б. Как делать будем ? Очевидно, что лучше трансформировать одно абстрактное синтаксическое дерево в другое. Затем просто обойти дерево и pretty-printing-ом сгенерить программу на языке Б.

_O_>Наличия языка описания AST-ов упрощяет такую деятельность. При описании AST-а мы можем сконцентриоваться именно на самом AST-е и переложить всю рутину на плечи генератора AST-а.

[код поскипан]

Вот что-то я смотрел на фрагменты кода. В первом увидел что-то вроде алгебраических типов. Во втором — паттерн-матчинг. И не проще ли было бы описать AST языков с помощью type из OCaml, а преобразование — обычная функция, использующая паттерн-матичнг? Или я опять чего-то не догоняю?
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[15]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 20.10.07 07:28
Оценка: +1
Здравствуйте, _Obelisk_, Вы писали:

_O_>Т.е. я спокойно смешиваю формальную спецификацию на Cocktail-е, с вызовом С++-ых функций.

_O_>Не думаю, что OCaml мне это позволит. Правда я его не знаю

Ещё как позволяет. Ну конечно, в одном месте писать сразу на OCaml и на C++ никто не позволит. Но можно из OCaml вызывать функции из С-ных библиотек (по-моему, можно и обратное, но я точно не знаю). В случае с Nemerle или Scala всё ещё, так как .NET и JVM позволяют бесшорвную интеграцию кода на разных ЯП. Так что вполне возможно написать парсер на OCaml, а потом "сшить" полученный код с кодом на C++. Замечу, что OCaml может компилить программу в native-код.

_O_>Проблема с ФЯ в том, что их трудно интегрировать с другими языками и другими API. Особенно, если требуется платформонезависимость. А переписать все систему, где несколько миллионов строк кода на С++ на каком-либо ФЯ нам не дадут


Оно и понятно, что не дадут. Более того, мне вот вообще ничего не дают писать на каком-нибудь F#. Аргументация простая — трудно найти ещё одного программиста, знающего ФЯ, а если и найдём, то ему надо будет больше платить.

Но в рамках ветки мы решаем другой вопрос — о том, насколько C++ подходит для написания компиляторов. И вот что оказывается: даже забывая про проверку типов, формирование промежуточного представления, кодогенерацию, мы упираемся в недостатки C++ уже на стадии парсинга. А увеличивая набор фич генератора, мы рано или поздно придём к тому, что реализуем свой ФЯ, компилирующийся в C++.
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[8]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 13.11.07 09:39
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>В AST нет смысла в визиторах?

AVK>Или визитор ничем не хуже внятного паттерн-матчинга?

Для работы с AST, где имеем общую базу у объектов-узлов — однофигственно. Паттерн-матчинг там нужен ради определения типа узла AST. Если алгоритмы обработки узлов относительно "большие", то используя синтаксис паттерн-матчинга рискуем получить файлы кода на десятки тыч. строк, ИМХО оформление в виде отдельных методов вкупе с partial поможет не превратить код в кашу.

В принципе, дело вкуса, конечно, на небольших задачах паттернг-матчинг в качестве визитора выглядит вполне эстетично.
Re[5]: Разработка языка-убийцы С++
От: lexis_t  
Дата: 22.11.07 12:33
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Мягко говоря сомнительная функциональность.

WH>Мало того что она ставит крест на агрессивных оптимизациях

И чем это ставит крест на оптимизациях Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз.

WH>но что во много раз хуже данная функциональность превращает код в тАкую лапшу что функция на 10К строк с кучей goto покажется кристально ясной.


Вы пробовали разобраться в исходниках буста ?? Особливо в части mpl!
Re[7]: object-like call stack
От: lexis_t  
Дата: 22.11.07 13:29
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

_>>И чем это ставит крест на оптимизациях Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз.

WH>Это делает практически не возможным анализ потоков данных.
WH>И как следствие убивает такие оптимизации как region inference или даже банальное вынесение проверок границ массивов за приделы цикла.

_>>Вы пробовали разобраться в исходниках буста ?? Особливо в части mpl!

WH>Хочешь чтобы весь код был таким?

1. Я думаю в вопросе оптимизации можно достичь приемлемого компромиса... Можно немного доработать синтаксис, открывать доступ не ко всем локальным переменным, вообще компилировать без этой фичи..
2. Возможность доступа к локальным переменным выше по стеку вовсе не означает, что нужно позволять лезть туда из любого места программы! Эта возможность должна быть ограничена чисто синтаксически, самой возможностью получения указателя на кадр-объект стека, которому к тому же должен быть ассоциирован правильный тип
Re[8]: object-like call stack
От: WolfHound  
Дата: 22.11.07 13:53
Оценка: +1
Здравствуйте, lexis_t, Вы писали:

_>1. Я думаю в вопросе оптимизации можно достичь приемлемого компромиса... Можно немного доработать синтаксис, открывать доступ не ко всем локальным переменным, вообще компилировать без этой фичи..

_>2. Возможность доступа к локальным переменным выше по стеку вовсе не означает, что нужно позволять лезть туда из любого места программы! Эта возможность должна быть ограничена чисто синтаксически, самой возможностью получения указателя на кадр-объект стека, которому к тому же должен быть ассоциирован правильный тип
Реально тут возникает еще куча вопросов. Мне лень перечислять.
А главное не ясно нафига все эти сложности вобще нужны?
Что мы получим то?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: ухожу-ухожу-ухожу...
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.07 09:52
Оценка: +1
Здравствуйте, lexis_t, Вы писали:

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

Любые сложные новые вещи получаются только тогда, когда есть хотя бы один человек, хорошо понимающий, что они такое. В большинстве случаев неспособность объяснить связана со слабым пониманием.
_>А уж извините приводить в пример оптимизацию при компиляции С++ под VM, или предлагать написать псевдокод... я не заказчик и здесь никто не обсуждает никаких спецификаций даже в нулевом приближении...
Это тебе пытаются помочь: раз ты не можешь сформулировать свою идею на простом русском языке — сформулируй на языке программирования. Если ты не можешь привести пример псевдокода с тем синтаксисом, которого ты хочешь, значит ты не знаешь, какого синтаксиса ты хочешь.

Если ты не можешь объяснить, какие преимущества даст "объектный стек", значит ты не знаешь, есть ли преимушества вообще.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка: +1
Здравствуйте, _Obelisk_, Вы писали:

_O_>Паттерн матчинг используется при обработке AST-а ...


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

Так причем тут С++?

ЗЫ

А можно в килобайтах, а не в строках кода. А то строчки мерять влом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Разработка языка-убийцы С++
От: c-smile Канада http://terrainformatica.com
Дата: 17.09.07 17:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>С++ очень плохо подходит для разработки компиляторов.


Чё так?
Re[2]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 17.09.07 18:23
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, Cpphater, Вы писали:


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

C>>Идейную наследственность вижу в кардинальном усилении метапрограммной составляющей. Одновременное, с этим, кардинальное удаление С рудиментов должно породить язык необычайной выразительной мощи.
C>>Ищу единомышленников, которые помогут мне в моих грандиозных планах
C>>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

CS>А чем D конкретно не устраивает в качестве могильщика?

CS>Чем могильщица Таня будет принципиально лучше?

Идет явная путанница между терминами "убийца" и "могильщик". Может быть D и хорош как могильщик, но не как убийца В D, например, есть встроенный GC, что является недопустимым для True потомка С++. GC может быть только библиотечным.

Не "Таня", а Tany. Или вы и Ruby называете по-свойски Рубиком?
от любви до ненависти...
Re[2]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 17.09.07 18:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Cpphater, Вы писали:


C>>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

WH>С++ очень плохо подходит для разработки компиляторов.
WH>И вобще ИМХО язык нужно писать на самом себе.
Согласен. И отчасти это будет так.
Обобщая различные концепты С++, я пришел к выводу, что язык должен иметь "микроядерную" архитектуру. Микроядро будет относительно простым и написанным на С++. На нём, но в терминах языка будут вводиться имплементации таких понятий как пространства имён, классов, функций и их взаимосвязей. Собственно микропрограммы могут писаться по-разному, соответственно порождая разные диалекты Tany. Например TanyJ, TanyC, Tany# которые могут рассматриваться как метапрограммные надстройки над Java, C++, C#. Но меня в первую очередь интересует создание TanyC как замена С++. Результатои работы компилятора Tany, для первых версий компилятора, будет код на С/C++ (для TanyJ был бы Java).
от любви до ненависти...
Re[4]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 17.09.07 19:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Cpphater, Вы писали:


C>>Обобщая различные концепты С++,

WH>Чего простите?
кирпичики языка, понятия, те же неймспейсы, классы, функции, внутренние алгоритмы поиска имён, автоматичесикх преобразований и т.п.

C>>я пришел к выводу, что язык должен иметь "микроядерную" архитектуру.

WH>Что такое микроядерная архитектура ядра? Lisp?
я сам ввел термин "микроядерная архитектура языка", не знаю существует ли что-то подобное, уже введённое для языков до меня . Но это какая-то аналогия с микроядерной архитектурой ОС. Отличие — микрокод это часть основного языка, но подавляющая часть имплементации языка является библиотекой на микрокоде. Микрокод у меня — функциональный язык темплейтов.

C>>Микроядро будет относительно простым и написанным на С++.

WH>Никокого С++. Язык нужно писать на самом себе.
WH>См http://nemerle.org/svn/nemerle/trunk
будет так, но не сразу.

C>>На нём, но в терминах языка будут вводиться имплементации таких понятий как пространства имён, классов, функций и их взаимосвязей.

WH>Те каждый раз писать свой язык?
Что значит каждый раз? это будет базовая библиотека типа как СТЛ для С++. пишется один раз для диалекта, а затем только подправляется

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

WH>Кошмар. Сказку про Вавилонскую башню помнишь?
не вижу аналогии
WH>Кстати одна из главных проблем С++ это куча диалектов.
диалекты — это, по сути, разные языки. Да и вообще, это пока далёкая тема, если такая проблема станет иметь место, то это уже будет означать успех языка

WH>Но С++ уже большой и хоть с трудом но это переживает. А вот твой язык сдохнет сразу.

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

C>>Например TanyJ, TanyC, Tany# которые могут рассматриваться как метапрограммные надстройки над Java, C++, C#. Но меня в первую очередь интересует создание TanyC как замена С++. Результатои работы компилятора Tany, для первых версий компилятора, будет код на С/C++ (для TanyJ был бы Java).

WH>Смотри R# http://rsdn.ru/projects/rsharp/article/rsharp_mag.xml
WH>Проект умер... ибо тупик.
Мне сложно понять что являлось там тупиком, но по крайней мере С++ вначале был тоже кодокенератором С кода.
от любви до ненависти...
Re: первый шаг убийцы
От: Cpphater Россия  
Дата: 17.09.07 21:39
Оценка:
Развёрнута SVN по адресу: http://tools.assembla.com/svn/Tany
а также Track по адресу: http://tools.assembla.com/Tany , правда он пока что пуст
от любви до ненависти...
Re[4]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 23.09.07 17:50
Оценка:
Здравствуйте, Smal, Вы писали:

S>Ничего смешного. Когда Вирт Паскаль придумывал (с Мейером, кажется), они сначала

S>написали код компилятора на Паскале, а потом отправили своего ассистента в 2-х недельный отпуск,
S>чтобы он там в машинные коды все перевел вручную.

А мне не нужен будет ассистент для подобного. С++ может считаться подмножеством TanyC. Любая программа на нём будет являться (быть может лишь только с небольшими лексическими изменениями) программой на TanyC.
от любви до ненависти...
Re[2]: Открылся сайт проекта!
От: Cpphater Россия  
Дата: 29.09.07 23:13
Оценка:
Сам сайт http://www.tany-lang.org/
Пока что там только форум, но скоро будет больше...
от любви до ненависти...
Re[3]: Открылся сайт проекта!
От: WolfHound  
Дата: 30.09.07 16:42
Оценка:
Здравствуйте, Cpphater, Вы писали:

Почему отступы делаешь то табами то пробелами? Бардачек однако.
Чтобы такого небыло включи в студии чтобы непечатыемые символы показывались. А чтобы в глаза не бросались сделай их бледносерыми.
А чем binary_procedure лучше всех остальных процедур?
object_visitor... будет просто огромным и пользоватся им будет ой не просто... Перешол бы на нормальный язык пока не поздно.
Ну это там где pattern matching есть:
        // the special case for unary operators
        | TT.TExpr.Call (TT.TExpr.OpCode (name), [parm], _) =>
          append (name);
          append ("(");
          recurse (parm.expr);
          append (")");

        // the special case for infix binary operators
        | TT.TExpr.Call (TT.TExpr.OpCode (name), [parm1, parm2], _) =>
          append ("(");
          recurse (parm1.expr);
          append (" " + name + " ");
          recurse (parm2.expr);
          append (")")

        // pretty print the list constructors
        | TT.TExpr.Call (TT.TExpr.StaticRef (_, mem, _), _, _) when is_list_cons (mem) =>
          print_list_constructors (expr)
              
        // write all the other calls in prefix form 
        | TT.TExpr.Call (func /* PExpr */, parms /* list [Parm] */, _) =>
          recurse (func);
          append (" (");
          print_fun_call_parms (parms);
          append (")")
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Открылся сайт проекта!
От: Cpphater Россия  
Дата: 30.09.07 19:25
Оценка:
Спасибо за замечания, WolfHound, постараюсь исправиться
binary_procedure я выделил как базовый класс для бинарных built-in процедур. (процедурами я называю функции выполняемые в компайл-тайм)

WH>object_visitor... будет просто огромным

почему? Количество визитируемых типов не должно превысить и десятка. Или это уже много?
Что касается перехода на другой язык... Это было бы неправильно идеологически... поэтому ложится в некоторый принцип. Сам говорил что язык надо делать на самом себе. С++ является подмножеством TanyC. Поэтому Nemerle мне не подходит
от любви до ненависти...
Re[4]: Разработка языка-убийцы С++
От: neFFy Россия  
Дата: 12.10.07 12:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>С++ очень плохо подходит для разработки компиляторов.

CS>>Чё так?
WH>Ни алгебраических типов.
WH>Ни сравнения с образцом.
WH>Ни нормальных макросов.
WH>Ни сборщика мусора.

ни кофе не приносит девелоперу..

а можно пример как перечисленное выше используется для разработки компиляторов?.
я просто слишком далек от этого
...coding for chaos...
Re[5]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 12.10.07 13:01
Оценка:
Здравствуйте, neFFy, Вы писали:

FF>а можно пример как перечисленное выше используется для разработки компиляторов?.

FF>я просто слишком далек от этого
Можно.

WH>>Ни алгебраических типов.

WH>>Ни сравнения с образцом.
Позволяют гораздо проще работать с AST.
Например попробуй представить как это
Автор: WolfHound
Дата: 30.09.07
будет выглядить на if'ах, визитерах и тп...

WH>>Ни нормальных макросов.

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

WH>>Ни сборщика мусора.

Следить за тем кто на кого ссылается и когда и кого можно удалить тот еще геморой.
ГЦ делает этот процесс сильно проще.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Разработка языка-убийцы С++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.10.07 18:19
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Гы... И ты думаешь, всего этого достаточно? И ты думаешь, что при лексическом анализе паттерн матчинг сильно помогает? А ты не задумывался, что нужно ещё сделать проверку (вывод) типов, перевести AST в промежуточное представление (а может быть, и в несколько промежуточных представлений — например, сначала в лямбду а затем в комбинаторы), сгенерить код? Не говоря конечно об оптимизациях.


Я писал вывод типов, семантический анализаторы, трансформации AST-ов в иное представление и др.
Паттерн матчинг используется при обработке AST-а ( в ходе семантического анализа, генерации кода, трансформации AST-a) для задания шаблонов узлов AST-а. Скажем, для binary expression с таким-то типом левого и правого аргумента назначить тип такой-то. Т.е. при том же выводе типов применяется.
А лексический анализ — это самое простейшее в трансляторе. Генераторы лексеров делают всю работу.

K>Ну и? Он только парсить умеет? Тогда что-то много 9000 строк. Ты что ли учёл сгенерированны код? Я бы в 2-3К строк уложился, будь у меня правильный генератор (из нах — 0.5К — только одна грамматика). А то все эти генераторы страдают похожестью на yacc.


Cocktail гораздо круче, чем yacc, но он платный.

9000 строк — это не генеренный код. Это спецификации для генератора.

Я же сказал, что не только парсит, но и строит таблицы символов, делает разрешение имен и семантический анализ. Если сможешь, представь тоже самое размером в 2-3К строк кода. Требования на парсер и построенный АСТ:
— полное покрытие спецификации C# 2.0
— в асте должны быть элементы представляющии директивы препроцессора (такие как #region и др)
— в асте должны быть представлены комментарии
— в асте должны быть позиции для каждого элемента
— должна быть нормальная система восстановления после ошибок и репорт о синтаксических и лексических ошибках
— парсер должен уметь парсить файлы в формате UTF-8 и UTF-16
— должен быть выделенный интерфейс для парсера и сканнера (ака. лексера)
— аст должен быть удобен для последующий обработки
— все должно быть платформонезависимым (работать под Win/Linux/Solaris)

Семантический анализ, вывод типов, разрешение имен не требую, ибо они в 2 — 3 килобайта не влезут

P.S.
Извини, но сколько реальных парсеров (или семантических анализаторов, кодогенераторов и т.п.) , которые используется в реальных коммерческих проектах, ты написал ?



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[7]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 18.10.07 19:52
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Я писал вывод типов, семантический анализаторы, трансформации AST-ов в иное представление и др.


И как, всё было просто, или прошлось опираться на костыли?

_O_>Паттерн матчинг используется при обработке AST-а ( в ходе семантического анализа, генерации кода, трансформации AST-a) для задания шаблонов узлов AST-а. Скажем, для binary expression с таким-то типом левого и правого аргумента назначить тип такой-то. Т.е. при том же выводе типов применяется.


Ага. Это как правило и есть немалая часть компилятора.

_O_>А лексический анализ — это самое простейшее в трансляторе. Генераторы лексеров делают всю работу.


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

K>>Ну и? Он только парсить умеет? Тогда что-то много 9000 строк. Ты что ли учёл сгенерированны код? Я бы в 2-3К строк уложился, будь у меня правильный генератор (из нах — 0.5К — только одна грамматика). А то все эти генераторы страдают похожестью на yacc.


_O_>Cocktail гораздо круче, чем yacc, но он платный.


А чем он круче кроме скорости и error handling?

_O_>9000 строк — это не генеренный код. Это спецификации для генератора.


_O_>Я же сказал, что не только парсит, но и строит таблицы символов, делает разрешение имен и семантический анализ. Если сможешь, представь тоже самое размером в 2-3К строк кода. Требования на парсер и построенный АСТ:

_O_>- полное покрытие спецификации C# 2.0

Ага.

_O_>- в асте должны быть элементы представляющии директивы препроцессора (такие как #region и др)


Ага.

_O_>- в асте должны быть представлены комментарии


Ага.

_O_>- в асте должны быть позиции для каждого элемента


Элементарно.

_O_>- должна быть нормальная система восстановления после ошибок и репорт о синтаксических и лексических ошибках


Это вообще проблема нерешённая. Всякие Cocktail просто предоставляют хорошую эвристику. Тонны кода тут ничего не решают.

_O_>- парсер должен уметь парсить файлы в формате UTF-8 и UTF-16


И это проблема?

_O_>- должен быть выделенный интерфейс для парсера и сканнера (ака. лексера)


И что?

_O_>- аст должен быть удобен для последующий обработки


Ага

_O_>- все должно быть платформонезависимым (работать под Win/Linux/Solaris)


Ага.

_O_>Семантический анализ, вывод типов, разрешение имен не требую, ибо они в 2 — 3 килобайта не влезут


Может и не требуешь, но компилятор — это далеко не только парсер. То, что ты назвал, как правило реализуется дольше и сложнее, чем парсер/лексер. И в данном случае сопоставление с образцом, сборщик мусора и т.д. являются неплохим подпорьем.

_O_>P.S.

_O_>Извини, но сколько реальных парсеров (или семантических анализаторов, кодогенераторов и т.п.) , которые используется в реальных коммерческих проектах, ты написал ?

Ни одного. Исключительно в самообразовательных целях. Возможно, мне ещё придётся писать парсер для коммерческого проекта. Так же планирую написать компилятор ML-образного языка для диплома, на OCaml. За парсер боюсь меньше всего, т.к. это штука простая. Вот разобраться в суперкомбинаторах и G-машине — это посерьёзнее будет... Зато я уже успел написать два генератора парсеров (один на Nemerle, можно найти в соотв. форуме). Кстати, если его доработать (вообще, серьёзно доработать), то можно запросто покрыть названные тобой пункты гораздо меньшим числом строк, чем 9К. Кстати, это всё благодаря тому, что в своём генераторе я ориентировался на преимущества, предоставляемые ФЯ.
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[9]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 19.10.07 06:22
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

K>>И как, всё было просто, или прошлось опираться на костыли?


_O_>Зависело от задач.


Я не про то. Я про тулзы, которыми пользовались. Писали на C# или C++? Тулзы позволяли адекватно отражать задачу, или приходилось трахаться?

K>>Вот и я про то же. Но если их не юзать, то паттерн матчинг мало поможет, и ФЯ почти не даст выигрыша перед ИЯ без паттерн-матчинга.


_O_>Генераторы надо юзать, ручками писать стоит только что-либо совсем простое.


Двумя руками за. Но я не про то. Почитай ещё раз внимательно выше по ветке.

K>>А чем он круче кроме скорости и error handling?


_O_>Наличие языка для описания AST-а (на самом деле не только AST-а но и других, подобных структур), наличие языка для написания трансформаций AST-а (с pattern matching-ом)


А вот не проще ли было сделать генерацию AST в ФЯ, которых хорошо подошёл бы для трансформации AST (например, Haskell, OCaml), чем изобретать велосипедную, нверняка не самую лучшую реализацию?

_O_>, наличие языка для описания attribute evaluators для AST-ов. Возможность генерации парсеров с множеством точек входа. Генерит хорошую информацию о конфликтах в грамматике. Для AST-ов генерятся механизмы сериализации/десериализации и визуализации AST-а. Есть примочка, автоматически выводящая спецификацию для сканнера из грамматики.


А умеет автоматически генерить правила для типовых случаев, чтобы не приходилось, как в yacc, справа от каждого правила писать { код }? А язык описания грамматики какой — yacc-образный, или полноценный BNF?

_O_>Есть библиотека со всякими полезными штуками для решения сопутствующих задач возникающих при создании компиляторов (хэширование строк, управление памятью и др)


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

K>>И это проблема?


_O_>Нет, но надеюсь, ты не забыл, что в тексте программы могут присутствовать символы в виде \u01d7 \u01e0 и т.д ? Сканер должен такое поддерживать.


Ага, и это не вызывает особых проблем. Примерно так (выдержка из спецификации, по которой генерится рабочий лексер, сделано копипастом из стандарта):

subst UnicodeEscapeSequence ::=
    "\\u" HexDigit HexDigit HexDigit HexDigit |
    "\\U" HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit HexDigit;
subst HexDigit ::= "0".."9" | "A".."F" | "a".."f";
Identifier ::= "@"? IdentifierStartCharacter IdentifierPartCharacter*;
subst IdentifierStartCharacter ::= U_Ll | U_Lu | U_Lt | U_Lm | U_Lo | 
        UnicodeEscapeSequence | "_";
subst IdentifierPartCharacter ::=
        U_Nl | U_Ll | U_Lu | U_Lt | U_Lm | U_Lo | U_Nd |
        UnicodeEscapeSequence | U_Mc | U_Mn | "_";


K>>Может и не требуешь, но компилятор — это далеко не только парсер. То, что ты назвал, как правило реализуется дольше и сложнее, чем парсер/лексер. И в данном случае сопоставление с образцом, сборщик мусора и т.д. являются неплохим подпорьем.


_O_>Задачи из области разработки компиляторов возникают отнюдь не только при разработки компиляторов. У нас они возникают при создании генераторов из формальных моделей, импорта и трансформации программ (source-to-source transformations), создании таких фич как IntelliSense, поддержка рефакторинга и т.п

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

Мы говорили не об околокомпиляторной задаче, а о компиляторе. Утверждение, что компилятор тяжело написать на языке, не обладающем определёнными возможностями, никак нельзя опровергнуть тем, что околокомипляторные задачи запросто решаются и без этих средств. Наоборот, тот же IntelliSense (его визуальная составляющая, поддержка в тектовом редакторе и т.п.) проще бы решалась на языке, обладающем хорошими "компонентными" возможностями, т.е. каком-нибудь C#, Java и т.п.

_O_>То, что сам написал пару генераторов, это похвально

_O_>Только еще раз повторю — 9К — это с выводом типов, разрешением имен и таблицей символов. Собственно парсер со сканнером там где-то 2700 занимают.

Ну, 2700 — это ещё жить можно Вывод типов в C# — штука несложная, т.к. она производится только для generic'ов. Хотя и алгоритм вывода типов в системе типов Хиндли-Милнера тоже весьма прост. Правда, подобное утверждение верно только для классической системы типов Хиндли-Милнера. Если в неё добавить type classes, перегрузку или что-то в этом роде, написание вывода типов на каком-нибудь C++ превращается в сущий ад.

_O_>А твой генератор парсеров какие парсеры генерит ? LL, LR(k), LALR(k) ?


LALR. Хотел так же добавить LL(*) и GLR, но руки не дошли.

_O_> Детектит ли он конфликты в грамматике и какую информацию выдает ? Предоставляет ли средства для динамического резолвинга конфликтов ?


Детектит, не не репортит, руки не дошли. Многие сам пытается разрешить. Всё равно, в грамматике серьёзного языка вроде C# такого не напишешь:

expr =
        expr * expr
    | expr / expr
    | expr + expr
    | expr - expr
    | ...


с соответсвующими %left, %right и %nonassoc. Там приходится следовать спецификаии из стандарта. Или я чего-то не догоняю?

_O_>Содержит ли какой-нибудь язык для описания AST-ов ?


Нет. А зачем?

_O_>Имеются ли возможности для задания правил вычисления атрибутов в AST-е ?


Это как?

_O_>Сделать в самообразовательных целях генератор парсеров не трудно. А вот сделать из этого продукт и довести до ума — тяжело. Я верю, что всегда можно сделать тул круче уже существующих. К сожаленью, это происходит редко. Плюс того же Cocktail-я в том, что это интегрированная система тулов, в которых каждый тул с каждым легко соеденить. Проектирование такой архитектуры требует времени (Cocktail с 1988-го года развивается)


_O_>Когда я учился в универе, мне казалось, что все можно написать за пару ночей (и ведь действительно писалось!) Потом реализм наступил.


У меня уже давно реализм наступил, когда я на работе впервые столкнулся с правилом "20% функциональности требует 80% времени". Сделать круче Coctail достаточно просто — для этого нужно просто ориентироватся не на C++/C#/Java, а на что-то функциональное. И при этом не заниматься тупым компированием yacc.

_O_>P.S.

_O_>Хочешь задачку, полезную для общества ? — Подумай надо созданием UML Virtual Machine. Т.е. над машиной, которая могла бы интерпретировать UML-модели (только бери последнюю версию стандарта, где action semantics есть). Это позволит симулировать модели без необходимости кодогенерации исполняемого приложения. А симуляция моделей — вещь нужная всяким военным, аэрокосмическим, телекоммуникационным компаниям (правда западным, не нашим).

Не, на мне и так висит несколько задачек, полезных для общества Всякие там генераторы и компиляторы — это исключительно в свободное время
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[10]: Разработка языка-убийцы С++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 19.10.07 08:41
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Я не про то. Я про тулзы, которыми пользовались. Писали на C# или C++? Тулзы позволяли адекватно отражать задачу, или приходилось трахаться?


Cocktail + C++. Для некоторых задач (писали прямой импорт файлов из Rational Rose и Borland Together Architect) я сделал свой генератор объектно-ориентированных AST-ов. Он генерит системы С++ классов, описывающих внутреннюю модель данных этих продуктов из спецификации на UML. В данном случае, для описания AST-а UML подошел лучше, чем Cocktail. Была заточка на эффективность (надо было парсить файлы размером в 400 мегов и больше) и удобство последующих трансформаций.
Подобная штучка из Eclipse-а (в EMF есть) зависала при импорте моделей размером от 15 мегов. Так что Java была отброшена сразу. С# не рассматривался по тем же причинам (плюс тогда была лишь его первая версия, без generic-ов).

K>А вот не проще ли было сделать генерацию AST в ФЯ, которых хорошо подошёл бы для трансформации AST (например, Haskell, OCaml), чем изобретать велосипедную, нверняка не самую лучшую реализацию?


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

K>А умеет автоматически генерить правила для типовых случаев, чтобы не приходилось, как в yacc, справа от каждого правила писать { код }? А язык описания грамматики какой — yacc-образный, или полноценный BNF?


Умеет. Язык описания грамматики — EBNF, BNF, плюс поддерживает yacc-йи формат.

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


Там заточка на производительность. Стандартные средства не всегда хороши.

K>Мы говорили не об околокомпиляторной задаче, а о компиляторе. Утверждение, что компилятор тяжело написать на языке, не обладающем определёнными возможностями, никак нельзя опровергнуть тем, что околокомипляторные задачи запросто решаются и без этих средств. Наоборот, тот же IntelliSense (его визуальная составляющая, поддержка в тектовом редакторе и т.п.) проще бы решалась на языке, обладающем хорошими "компонентными" возможностями, т.е. каком-нибудь C#, Java и т.п.


Я на С++ такое делал. C#/Java работу сильно не облегчат.

K>Ну, 2700 — это ещё жить можно Вывод типов в C# — штука несложная, т.к. она производится только для generic'ов. Хотя и алгоритм вывода типов в системе типов Хиндли-Милнера тоже весьма прост. Правда, подобное утверждение верно только для классической системы типов Хиндли-Милнера. Если в неё добавить type classes, перегрузку или что-то в этом роде, написание вывода типов на каком-нибудь C++ превращается в сущий ад.


Не столь все страшно. Я писал вывод типов, name resolution, semantic analyzer на С++ для UML 2.0, в котором есть перегрузка операций и операторов, множество неявных конверсий, шаблоны типов и операций в духе С++ (и даже кой в чем круче) и куча специфических вещей. Все это работает в online-режиме т.е. модель чекается и пересвязывается постоянно, когда юзер ее меняет.
Самое серьезная проблема здесь была — как определить степень воздействия изменения модели. Т.е. если мы переименовали класс, то какие части модели необходимо перечекать (переименование может привести к конфликту имен или наооборот, убрать конфликт)

Да, вывод типов — это ведь не только для generic-ов. Определить тип выражения "a + b" — это тоже вывод типов. Собственно, даже определить тип литерала (например числа 1) не всегда тривиально. Например, в таком специфическом языке как SDL, тип литерала зависит от его контекста и там в одном месте тип '1' будет Integer, а в другом 'Real' а в треьем — какой-нибудь 'Time'.

K>Детектит, не не репортит, руки не дошли. Многие сам пытается разрешить. Всё равно, в грамматике серьёзного языка вроде C# такого не напишешь:


K>
K>expr =
K>        expr * expr
K>    | expr / expr
K>    | expr + expr
K>    | expr - expr
K>    | ...
K>


K>с соответсвующими %left, %right и %nonassoc. Там приходится следовать спецификаии из стандарта. Или я чего-то не догоняю?


Вот пример конфликтов в грамматике Шарпа (есть и другие) :

(x) -y


это cast expression или parenthesized expression ?

или

A < B, C >>  D  // shift or type arguments ?


Конфликты решаются динамически, с помощью предикатов, которые делают lookahead.

У тебя генератор поддерживает задание каких-либо condition-ов на правила в грамматике для динамического резолвинга подобных конфликтов ?

_O_>>Содержит ли какой-нибудь язык для описания AST-ов ?

K>Нет. А зачем?

Для описания AST-а, как самостоятельной сущности. Нужно и удобно на практике.

_O_>>Имеются ли возможности для задания правил вычисления атрибутов в AST-е ?


Это позволяет существенно упростить написание семантического анализа.
Понятия синтезируемый атрибут/наследуемый атрибут, атрибутивная грамматика, higher order attribute grammar знакомы ?

K>Не, на мне и так висит несколько задачек, полезных для общества Всякие там генераторы и компиляторы — это исключительно в свободное время


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



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: О языках-убийцах
От: alpha21264 СССР  
Дата: 19.10.07 09:35
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Все разработчики новых языков не учитывают одной простой вещи: для того, чтобы реальные программисты стали писать на новом языке программы, красоты и выразительности самого языка недостаточно. Нужно, чтобы этот язык как можно более гладко интегрировался в существующий процесс разработки. В идеале, программист скачивает инсталляшку некоего языка "X", запускает ее — и вуаля, в Visual Studio (или в любой другой распространенной IDE) появлялись пункты "Add new "X" file to project", в MSDN — подробнейшая справка по языку "X" (желательно еще и переведенная на родной язык разработчика!) и пара учебников с примерами, при компиляции компилятор файлы *.cpp компилирует С++-овским компилятором, а файлы "X" — новым "X"-овсым, линкер корректно линкует разные объектники в один exe-шник... Нужно чтобы в файлах нового языка можно было свободно использовать все без исключения библиотеки того же С/С++, чтобы с новым языком работал отладчик, подсветка синтаксиса, автокомплит...


XC>Вот если все эти условия будут выполнены, тогда и появится язык-убийца.


Нуу... блин! Ты конечно прав. Но ты хочешь чтобы ребенок вел себя как взрослый.
Когда x-code подрастет, он это поймет. А когда повзрослеет — перестанет играть в
"те же яйца только в профиль". Может быть даже научится делать из С++ тот язык,
который ему нужен для текущей задачи. Но это ближе к пенсии

Течёт вода Кубань-реки куда велят большевики.
Re[11]: Разработка языка-убийцы С++
От: konsoletyper Россия https://github.com/konsoletyper
Дата: 19.10.07 14:01
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

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


Любой — это какой?

_O_>Я на С++ такое делал. C#/Java работу сильно не облегчат.


Сомневаюсь.

_O_>Да, вывод типов — это ведь не только для generic-ов. Определить тип выражения "a + b" — это тоже вывод типов. Собственно, даже определить тип литерала (например числа 1) не всегда тривиально. Например, в таком специфическом языке как SDL, тип литерала зависит от его контекста и там в одном месте тип '1' будет Integer, а в другом 'Real' а в треьем — какой-нибудь 'Time'.


Ну дык, для литералов тип заранее неизвестен. А идентификаторы как? Там обязательна аннотация типов? Тогда вывод типов не такой и сложный. Даже в языках с необязательной аннотацией типов используется достаточно простой алгоритм, основанный на унификации, но только в случае системы типов Хиндли-Милнера. А вот если берём другую систему типов (Nemerle) или расширяем её (Haskell) получаются жуткие навороты...

_O_>Вот пример конфликтов в грамматике Шарпа (есть и другие) :


_O_>
_O_>(x) -y 
_O_>


_O_>это cast expression или parenthesized expression ?


_O_>или


_O_>
_O_>A < B, C >>  D  // shift or type arguments ?
_O_>


_O_>Конфликты решаются динамически, с помощью предикатов, которые делают lookahead.


_O_>У тебя генератор поддерживает задание каких-либо condition-ов на правила в грамматике для динамического резолвинга подобных конфликтов ?


Нет. А разве для первого случая возможно что-то определённое сказать, не сделав семантического анализа? Как в данном случае поступают?

_O_>Для описания AST-а, как самостоятельной сущности. Нужно и удобно на практике.


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

_O_>Это позволяет существенно упростить написание семантического анализа.

_O_>Понятия синтезируемый атрибут/наследуемый атрибут, атрибутивная грамматика, higher order attribute grammar знакомы ?

Читал в красном драконе. А при чём тут это?

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


У меня тоже времени на разработку собственных идей не хватает. Работа
... << RSDN@Home 1.2.0 alpha rev. 710>>
Re[14]: Разработка языка-убийцы С++
От: _Obelisk_ Россия http://www.ibm.com
Дата: 20.10.07 07:09
Оценка:
Здравствуйте, konsoletyper, Вы писали:

K>Вот что-то я смотрел на фрагменты кода. В первом увидел что-то вроде алгебраических типов. Во втором — паттерн-матчинг. И не проще ли было бы описать AST языков с помощью type из OCaml, а преобразование — обычная функция, использующая паттерн-матичнг? Или я опять чего-то не догоняю?


Мне нужно генерить из AST-а другую модель, которая на С++ написана.
Cocktail генерит кода на С, С++, Java, Modula-2, С# (недавно вроде добавили) и позволяет удобным образом смешивать свои конструкции с кодом на конкретном языке программирования. Поэтому я могу использовать pattern-matching и методы Cocktail-я для задания правил обхода модели и присобачивания трансформаций к узлам AST-а, а собственно порождение новой модели писать на С++.

Вот у меня было правило (мэппит конструкию типа "<expr> as <type>" )
this : as_expr(expression := expression, type := type) :-
    RETURN MakeAsExpr(TranslateExpression(expression), TranslateType(type));
    .


Здесь
this : as_expr(expression := expression, type := type) :-

есть Cocktail-ое правило.

Это вызов С++-ой функции
MakeAsExpr


А это
TranslateExpression
TranslateType

вызовы Cocktail-ых функций, определенных в другом месте.

Т.е. я спокойно смешиваю формальную спецификацию на Cocktail-е, с вызовом С++-ых функций.
Не думаю, что OCaml мне это позволит. Правда я его не знаю

Проблема с ФЯ в том, что их трудно интегрировать с другими языками и другими API. Особенно, если требуется платформонезависимость. А переписать все систему, где несколько миллионов строк кода на С++ на каком-либо ФЯ нам не дадут



Душа обязана трудиться! (с) Н.Заболоцкий.
Re: Разработка языка-убийцы С++
От: Varkom Россия  
Дата: 31.10.07 09:49
Оценка:
А какова цель разработки нового языка? Создание коммерческого продукта, создание языка под какие-то нужды, или так, в целях самообразования?
Re[2]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 02.11.07 15:02
Оценка:
Здравствуйте, Varkom, Вы писали:

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


Создать язык на котором создавать коммерческие продукты меньшей кровью.
от любви до ненависти...
Re[3]: Разработка языка-убийцы С++
От: dipso  
Дата: 06.11.07 06:34
Оценка:
Здравствуйте, Cpphater, Вы писали:

C>Здравствуйте, Varkom, Вы писали:


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


C>Создать язык на котором создавать коммерческие продукты меньшей кровью.


Помоему C# совсем не плох для роли киллера,после C++ писать на нём одно удовольствие.
Вот сделать бы чтонибудь типа C# с постоянно включенным unsafe,без сборщика мусора,компилируемый в нативный код,ну и фреймворк есессно родной(всмысле .NET совместимый по типу Mono).Имхо это самый оптимальный вариант чем создовать очередного Франкенштайна).Ещё одно имхо — писать надо на C++ и всё ручками,ни каких духов мать их перемать.Максимум — STL(возможно свои аллокаторы для контейнеров),сколько говорили о её не всегда хорошей эффективности,а у boost с этим ещё хуже.До момента кодогенерации написать всё ручками не так уж сложно.А вот кодогенерация и уж тем более оптимизация не тривиальная задачка.Вот такое моё имхо)
Re[4]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 09.11.07 08:38
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>С++ очень плохо подходит для разработки компиляторов.

CS>>Чё так?
WH>Ни алгебраических типов.

А для программы компилятора они зачем???

WH>Ни сравнения с образцом.


Табличные LL(k) рулят. И не переубедишь.

WH>Ни нормальных макросов.


Для автоматного подхода к лексеру и парсеру имеющихся хватает с головой.

WH>Ни сборщика мусора.


Ну приплыли. И кому же это сборщик понадобился? Лексеру или парсеру? Или древовидным, монотонно растущим словарям?
Если программе-компилятору нужен сборщик мусора, то это какой-то наколенно-склёпанный компилятор.
Re[7]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 12.11.07 09:42
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А прямое обращение к типизированным данным чем хуже?

А pattern-matching у тебя по этим самым данным тоже работает?

V>Немерле разработан ради работы в составе платформы.

И?

V>Я всё-равно не услышал, зачем конкретно в программе-компиляторе постоянно выделять и затем уничтожать временные куски памяти?

Например различные трансформации (макросы, оптимизация итп)
Да и вобще нафига сидеть и выдумывать свякие хитрые схемы работы со структурами если можно писать простой код, а GC сам прекрасно разберется что нужно, а что нет.

V>Сдаётся мне, что компилятор должен только выделять память, а освобождать в конце своей работы.

С чего это?
Нафига хранить всякий мусор?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Разработка языка-убийцы С++
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.11.07 14:02
Оценка:
Здравствуйте, vdimas, Вы писали:

WH>>Нет ничего лучше для работы с AST.


V>А прямое обращение к типизированным данным чем хуже?


В AST нет смысла в визиторах? Или визитор ничем не хуже внятного паттерн-матчинга?
... << RSDN@Home 1.2.0 alpha rev. 716>>
AVK Blog
Re[8]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 15.11.07 08:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

V>>Я всё-равно не услышал, зачем конкретно в программе-компиляторе постоянно выделять и затем уничтожать временные куски памяти?

WH>Например различные трансформации (макросы, оптимизация итп)

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

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


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

V>>Сдаётся мне, что компилятор должен только выделять память, а освобождать в конце своей работы.

WH>С чего это?
WH>Нафига хранить всякий мусор?

А ты думаешь, что в твоей схеме будет хотя бы раз вызван GC до конца работы компилятора?
Сильно заблуждаешься, там загрузка проца будет под 100%, и никакого сбора мусора до конца работы не предвидится, только если память не начнёт заканчиваться.

Вот прямо сейчас вожусь с проектом, где активно обрабатывается звук (конференция аудио-видео), так вот, когда избавились от принципа постоянного выделения блоков памяти и максимально задействовали однажды выделенные структуры, то средняя загрузка проца упала от примерно 30% до практически нуля. Ну и самое главное — прекратились периодические ухудшения кач-ва звука (хрипение), надеюсь, объяснять не надо — почему?
Re[9]: Разработка языка-убийцы С++
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.11.07 17:31
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Для работы с AST, где имеем общую базу у объектов-узлов — однофигственно.


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

V> Паттерн-матчинг там нужен ради определения типа узла AST.


Не ради определения, а ради диспетчеризации вызовов.

V> Если алгоритмы обработки узлов относительно "большие", то используя синтаксис паттерн-матчинга рискуем получить файлы кода на десятки тыч. строк, ИМХО


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

V> оформление в виде отдельных методов вкупе с partial поможет не превратить код в кашу.


Код в кашу превращает исключительно програмимст.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re: Разработка языка-убийцы С++
От: lexis_t  
Дата: 18.11.07 20:16
Оценка:
Здравствуйте, Cpphater, Вы писали:

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

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

Зделайте в нем объектный стек вызовов, чтобы исключения можно было по-человечески обрабатывать.
Говорят в питоне это сделано!
Re[2]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 19.11.07 16:11
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>Зделайте в нем объектный стек вызовов, чтобы исключения можно было по-человечески обрабатывать.

Чего?
Подробней пожалуйсто.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 22.11.07 11:43
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>Фактически для компилятора ничего не поменяется, в стеке будут лежать все те же локальные переменные (упакованные в класс), но при обработке исключительной ситуации будет теоретическая возможность добраться до их значений (до раскручивания стека) и даже исправить! А потом восстановить прежнюю точку выполнения и продолжить как ни в чем не бывало!

Мягко говоря сомнительная функциональность.
Мало того что она ставит крест на агрессивных оптимизациях но что во много раз хуже данная функциональность превращает код в тАкую лапшу что функция на 10К строк с кучей goto покажется кристально ясной.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 22.11.07 12:47
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>И чем это ставит крест на оптимизациях Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз.

Это делает практически не возможным анализ потоков данных.
И как следствие убивает такие оптимизации как region inference или даже банальное вынесение проверок границ массивов за приделы цикла.

_>Вы пробовали разобраться в исходниках буста ?? Особливо в части mpl!

Хочешь чтобы весь код был таким?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Разработка языка-убийцы С++
От: Bear Hunter Украина  
Дата: 23.11.07 07:54
Оценка:
Здравствуйте, Cpphater, Вы писали:

C>[...]

C> название языка 'Tany'

А читаеться как "Та ну"?
Re[4]: Разработка языка-убийцы С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.11.07 16:18
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>Если представить, что каждая функция — это специальный класс, а при вызове функции на стеке создается объект с типом функция-класс...

_>Таким образом появляется возможность адресовать переменные, лежащие выше по стеку, если имеется указатель на кадр стека и конкретный тип (то есть класс-функция).
_>Фактически для компилятора ничего не поменяется, в стеке будут лежать все те же локальные переменные (упакованные в класс), но при обработке исключительной ситуации будет теоретическая возможность добраться до их значений (до раскручивания стека) и даже исправить!
Никакого отношения к способу "упаковки переменных" эта возможность не имеет. Это раз.
_>А потом восстановить прежнюю точку выполнения и продолжить как ни в чем не бывало!
Эта — тоже. Это два.

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

2. Стартовать выполнение с того места, где оно было прервано, можно независимо от того, каким образом хранится стек. Обычно это не удается сделать по чисто синтаксическим причинам — довольно сложно себе представить современный язык высокого уровня, в котором логика такого продолжения достаточно прозрачна.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Разработка языка-убийцы С++
От: lexis_t  
Дата: 27.11.07 16:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Непонятно, чего хочется.

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

Почему все дружно бросились объяснять, что это невозможно??? и не имеет смысла???

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

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

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


Вот я и предлагаю подход, при котором такое продолжение будет прозрачным именно с точки зрения синтаксиса.
Re[9]: object-like call stack
От: lexis_t  
Дата: 27.11.07 16:16
Оценка:
Здравствуйте, WolfHound

см ниже
Re[5]: Разработка языка-убийцы С++
От: lexis_t  
Дата: 27.11.07 16:28
Оценка:
Если смотреть на вопрос "объектного стека" с точки зрения философии программирования, то я бы отметил следующие вещи:

1. Определение функций как специальных классов доводит ОО парадигму яыка до логического завершения.
2. Объектный, типизированный стек вызовов дает языку новый мощный и выразительный механизм (как его использовать можно обсуждать в будущем. Я могу предположить его использование от тупого облегчения обработки ошибок, до нового подхода при составлении алгоритмов...)
3. Противоречия между моделью языка высокого уровня и реальной архитектурой железа, читай проблемы оптимизации были всегда.. но всегда находились и компромиссы. Так было еще со страничной организацией памяти, так есть с RTTI...
Re[6]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 27.11.07 16:31
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>Почему все дружно бросились объяснять, что это невозможно???

Где?

_>и не имеет смысла???

А он есть?

_>Все что заранее имеет смысл — уже придумано и реализовано. А не придумано и не реализовано то, смысл чего понять заранее тяжело. Окончательно смысл будет понятен лет через дцать после первой реализации.

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

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

Примеры в студию.
Ибо лично у меня вобще ни разу жилания не возникало делать подобные вещи.
А поработав с функциональными языками так и вобще большую часть переменных делаю не изменяемой.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Разработка языка-убийцы С++
От: WolfHound  
Дата: 27.11.07 16:39
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>1. Определение функций как специальных классов доводит ОО парадигму яыка до логического завершения.

Есть мнение что использование ОО на уровне методов вобще говоря идея плохая.
ИМХО куда лучше оставить ОО на уровне дизайна высокого уровня, а вычисления делать в функциональном стиле.
Смотри на http://nemerle.org

_>2. Объектный, типизированный стек вызовов дает языку новый мощный и выразительный механизм (как его использовать можно обсуждать в будущем.

Не показал чего он дает.
Напиши псевдокод.

_>Я могу предположить его использование от тупого облегчения обработки ошибок,

Каким образом?

_>до нового подхода при составлении алгоритмов...)

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

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

1)Давно в прошлом.
2)При наличии нормальной VM страничная организация адресного пространства не проблема.

_>так есть с RTTI...

А причем тут железо вобще?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: ухожу-ухожу-ухожу...
От: lexis_t  
Дата: 27.11.07 17:07
Оценка:
1. Прога на асме (если руки из плечей) всегда будет работать быстрее, чем С++, и уж подавно чем ВИРТУАЛЬНАЯ МАШИНА! нах с++ и .нет!
2. Если плюсы подхода нужны только мне, то ради меня вставлять новую фичу в язык не надо. Если их вижу ТОЛЬКО я, значит из меня хреновый программер!
3. Извините, что не получилось здоровой дискуссии и бла-бла-бла...
Re[8]: ухожу-ухожу-ухожу...
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.11.07 06:24
Оценка:
Здравствуйте, lexis_t, Вы писали:

_>1. Прога на асме (если руки из плечей) всегда будет работать быстрее, чем С++, и уж подавно чем ВИРТУАЛЬНАЯ МАШИНА! нах с++ и .нет!


_>2. Если плюсы подхода нужны только мне, то ради меня вставлять новую фичу в язык не надо. Если их вижу ТОЛЬКО я, значит из меня хреновый программер!
Некорректная логика. Может быть, ты просто хреновый объясняльщик?
_>3. Извините, что не получилось здоровой дискуссии и бла-бла-бла...
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: ухожу-ухожу-ухожу...
От: lexis_t  
Дата: 28.11.07 08:23
Оценка:
Здравствуйте, Sinclair

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

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

PS: А объяснять я действительно не умею
Re[6]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 15:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Ни алгебраических типов.

WH>>>Ни сравнения с образцом.
WH>Позволяют гораздо проще работать с AST.
WH>Например попробуй представить как это
Автор: WolfHound
Дата: 30.09.07
будет выглядить на if'ах, визитерах и тп...


Чтобы он смог это представить, ему потребуется понять все перечисленные тобой идеомы. Без этого твой пример для него, что газета для обезьяны.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Генераторы надо юзать, ручками писать стоит только что-либо совсем простое.


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

_O_>Наличие языка для описания AST-а


Это конечно полезно. Но как быть если язык позволяет расширять синтаксис в рантайме?

_O_> (на самом деле не только AST-а но и других, подобных структур), наличие языка для написания трансформаций AST-а (с pattern matching-ом),


Можно пример? И поддерживаются ли эти фичи какой либо IDE? Интелисенс есть?

_O_> наличие языка для описания attribute evaluators для AST-ов.


Тоесть банального чтения АСТ? Оять не помешало бы поглядеть на примерчик...

_O_> Возможность генерации парсеров с множеством точек входа.


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

_O_> Генерит хорошую информацию о конфликтах в грамматике.


Это приемущество применения построителей парсеров. Не повторяйся.

_O_>Для AST-ов генерятся механизмы сериализации/десериализации и визуализации AST-а.


Здорово. Причем тут С++, то?

_O_>Есть библиотека со всякими полезными штуками для решения сопутствующих задач возникающих при создании компиляторов (хэширование строк, управление памятью и др)


Ну, костыли они и есть костыли. Чем от этого С++-то лучше стал? Все порядочные языки такие фукнции в стандартной библиотеке имеют.

_O_>Хорошая документация и примеры. Плюс поддержка со стороны разработчиков. Но, к сожаленью, тул платный (есть какая-то бесплатная версия, но сильно убогая)


И к сожалению к С++ отношения не имеющий. Да?

_O_>>>- парсер должен уметь парсить файлы в формате UTF-8 и UTF-16

K>>И это проблема?

_O_>Нет, но надеюсь, ты не забыл, что в тексте программы могут присутствовать символы в виде \u01d7 \u01e0 и т.д ? Сканер должен такое поддерживать.


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

_O_>Задачи из области разработки компиляторов возникают отнюдь не только при разработки компиляторов. У нас они возникают при создании генераторов из формальных моделей, импорта и трансформации программ (source-to-source transformations), создании таких фич как IntelliSense, поддержка рефакторинга и т.п

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

Ну, и чем тут помогает сам С++, то?

_O_>Только еще раз повторю — 9К — это с выводом типов, разрешением имен и таблицей символов. Собственно парсер со сканнером там где-то 2700 занимают.


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

Кстати, а Шарп 3.0 вы поддерживаете?

_O_>Сделать в самообразовательных целях генератор парсеров не трудно. А вот сделать из этого продукт и довести до ума — тяжело.


Это так с любым софтом. Хотя сделать генератор парсеров по любому не просто. Тут опыт нужен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

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


Что воздух сотрясать? Давай померяемся?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Т.е. я спокойно смешиваю формальную спецификацию на Cocktail-е, с вызовом С++-ых функций.

_O_>Не думаю, что OCaml мне это позволит. Правда я его не знаю

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

Другое дело, что Коктель вам предоставляет массу, скажем так, библиотек и утилит. В общем, массу уже написанного кода. Ведь как не просто было бы на ФЯ написать вывод АСТ в текст, но если он уже есть, то работы будет меньше по любому.

Так что если сранвинвать языки, то С++ несомненно лузер в области компиляторо строения. А если гтовые фрэймворки, то лучше тот, что содержит больше фич и имеет более высокое качество.

_O_>Проблема с ФЯ в том, что их трудно интегрировать с другими языками и другими API.


Ну, вот тот же Немерле интегрируется с C++, C#, VB и другими языками сносно поддерживающими дотент. Вот только чем боьше на нем пишешь, тем сеньше хочешь писать на других.

_O_> Особенно, если требуется платформонезависимость. А переписать все систему, где несколько миллионов строк кода на С++ на каком-либо ФЯ нам не дадут


Это другой вопрос. Но зачем было писать эти миллионы строк? К тому же только что их было 9000.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, vdimas, Вы писали:

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


Ты действительно думашь, что мощьноть паттерн-матчинга равна мощьности шаблона Посетитель?

Как тебе вот такой паттерн:
<[ if ($methodName(..$parms) $rtueExpr else $falseExpr ]>

это один паттерн! Он распознает сразу конструкцию if/else с любыми подвыражениями и функцией в качестве услвия. Причем мы сразу можем узнать имя фунции, список параметров и что в выражениях. Полученные переменные, а именно methodName, parms, rtueExpr, falseExpr можно снова разбирать паттерн-матчингом.

Подобную мощьность можно получить толко в дорогущих специализированных продуктах вроде упоминавшегося здесь Коктеля. А все ООЯ здесь отдыхают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, Cpphater, Вы писали:

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

C>Идейную наследственность вижу в кардинальном усилении метапрограммной составляющей. Одновременное, с этим, кардинальное удаление С рудиментов должно породить язык необычайной выразительной мощи.
C>Ищу единомышленников, которые помогут мне в моих грандиозных планах
C>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

Несколько вопросов:

1. В чем новизна?
2. Какие языки ты уже изучил? Другими словами кроме С++, ты что знаешь? Какие концепции и парадигмы изучи (ФЯ, ЛП...)?
3. Почему твой язык предпочтут скажем тому же С++0х?
4. Что будешь делать с совместимостью. Ведь выбросив С-шную грязь, ты потеряешь и совместимость.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, Cpphater, Вы писали:

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


Ага. Лет за 50 до тебя изобрели Лисп. Но в нем синтаксиса как такового нет. Потом изобрели много чего и в итоге Немерле. База языка довольно мала. Большая часть реализована на макросах.

C>Микрокод у меня — функциональный язык темплейтов.


Почему "темплейтов"? И что ты пкладываешь в это понятие? Метапрограммирование туда входит?

WH>>Но С++ уже большой и хоть с трудом но это переживает. А вот твой язык сдохнет сразу.

C>Успех языка будет напрямую зависеть от возможности гораздо долее быстрого (по сравнени с имеющимися языками) написания на нём различных приложений. Если это будет продемонстированно, то народ подтянется и обеспечит ему не столь короткую жизнь.

А какие концепции, по-твоему, позолят достичь ускорения? Вот в том же Немерле таких концепций через край. А ты то что хочешь предложить?

C>Мне сложно понять что являлось там тупиком, но по крайней мере С++ вначале был тоже кодокенератором С кода.


Конечно сама генерация исходников на другом языке — это не тупик. Тупик был в другом. Я просто не обладал тем объемом знаний который требовался для воплощения моей мечты в жизнь. В итоге мне дали ссыклу на язык в котором все мои идеи были воплощены в жизнь на значительно более высоком уровне, чем я мог даже мечтать. Язык этот — Немерле. Очень советую прежде чем вынашивать планы создания newC++ сначала изучить достойные языки современности. Вот мой список:
1. Есественно Немерле .
2. Лисп.
3. Хаскель.
4. Скала.

Список состоит только из языков поддерживающих компиляции (хоть как-то... если кто начнет тыкать пальцем в Лисп).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 17:04
Оценка:
Здравствуйте, Cpphater, Вы писали:

C>Идет явная путанница между терминами "убийца" и "могильщик". Может быть D и хорош как могильщик, но не как убийца В D, например, есть встроенный GC, что является недопустимым для True потомка С++. GC может быть только библиотечным.


ЖЦ там как раз опциональный. Насколько я знаю С++0х тоже будет в какой-то степени поддерживать ЖЦ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 26.01.08 13:08
Оценка:
Здравствуйте, VladD2, Вы писали:


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


VD>Ты действительно думашь, что мощьноть паттерн-матчинга равна мощьности шаблона Посетитель?


Для обработки узлов AST — практически да. Я уже сделал замечание, что узлы имеют общую базу.

VD>Как тебе вот такой паттерн:

VD>
VD><[ if ($methodName(..$parms) $rtueExpr else $falseExpr ]>
VD>

VD>это один паттерн! Он распознает сразу конструкцию if/else с любыми подвыражениями и функцией в качестве услвия. Причем мы сразу можем узнать имя фунции, список параметров и что в выражениях. Полученные переменные, а именно methodName, parms, rtueExpr, falseExpr можно снова разбирать паттерн-матчингом.

Как это относится к задаче написания своего парсера?
Re[10]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 26.01.08 13:16
Оценка:
Здравствуйте, AndrewVK, Вы писали:

V>>Для работы с AST, где имеем общую базу у объектов-узлов — однофигственно.


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


При количестве типов типов объектов в несколько десятков и более, двойная диспечерезация пока что самая эффективная. Насчёт громозкости — дело вкуса. Мне отдельные короткие методы кажутся куда как менее громоздкими, чем страшный по размерам паттерн-матчинг.


V>> Паттерн-матчинг там нужен ради определения типа узла AST.


AVK>Не ради определения, а ради диспетчеризации вызовов.


Разумеется, а зачем еще нужно определять тип узла.


V>> Если алгоритмы обработки узлов относительно "большие", то используя синтаксис паттерн-матчинга рискуем получить файлы кода на десятки тыч. строк, ИМХО


AVK>Не рискуем. При паттерн-матчинге в одной конструкции мы имеем количество вариантов, соответствующее конкретному родителю, а не вообще все ноды AST. В самых запущенных случаях это пара десятков вариантов.


Для ASN.1 это около сотни. В принципе, узлы тоже могут иметь сложную иерархию, и, соответственно, укороченный визитор по базам.


V>> оформление в виде отдельных методов вкупе с partial поможет не превратить код в кашу.


AVK>Код в кашу превращает исключительно програмимст.


Сотня тысяч строк в одном файле — это каша в любом случае, даже при "идеальном" стиле самого кода.
Re[11]: Разработка языка-убийцы С++
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.01.08 16:11
Оценка:
Здравствуйте, vdimas, Вы писали:

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


V>При количестве типов типов объектов в несколько десятков и более, двойная диспечерезация пока что самая эффективная.


При чем тут двойная диспетчеризация? Двойная диспетчеризация просто используется, чтобы реализацию AcceptVisitor осуществлялась методом Copy-Paste. И все.

AVK>>Не ради определения, а ради диспетчеризации вызовов.


V>Разумеется, а зачем еще нужно определять тип узла.


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

AVK>>Не рискуем. При паттерн-матчинге в одной конструкции мы имеем количество вариантов, соответствующее конкретному родителю, а не вообще все ноды AST. В самых запущенных случаях это пара десятков вариантов.


V>Для ASN.1 это около сотни.


Оченоь актуально в контексте темы топика.

AVK>>Код в кашу превращает исключительно програмимст.


V>Сотня тысяч строк в одном файле — это каша в любом случае


Вот я и говорю — программист.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[11]: Разработка языка-убийцы С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.01.08 11:14
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Для обработки узлов AST — практически да. Я уже сделал замечание, что узлы имеют общую базу.


Ты не прав. Если захочешь, разберешся сам. Доказывать ничего не хочу.

VD>>Как тебе вот такой паттерн:

VD>>
VD>><[ if ($methodName(..$parms) $rtueExpr else $falseExpr ]>
VD>>

VD>>это один паттерн! Он распознает сразу конструкцию if/else с любыми подвыражениями и функцией в качестве услвия. Причем мы сразу можем узнать имя фунции, список параметров и что в выражениях. Полученные переменные, а именно methodName, parms, rtueExpr, falseExpr можно снова разбирать паттерн-матчингом.

V>Как это относится к задаче написания своего парсера?


Компилятора. Так вот, напрямую и очень сильно. Сделать квази-цитирование для любого языка задача не сложная. А дальше можно будет работать не с АСТ, а шаблонами состоящими из квази-цитат. Причем по ним будет доступен паттерн-матчинг. Посетитель супротив этого все равно что совковая лопата супротив эксковатора.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Разработка языка-убийцы С++
От: varnie  
Дата: 19.02.08 11:19
Оценка:
Здравствуйте, Cpphater, Вы писали:

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

C>Идейную наследственность вижу в кардинальном усилении метапрограммной составляющей. Одновременное, с этим, кардинальное удаление С рудиментов должно породить язык необычайной выразительной мощи.
C>Ищу единомышленников, которые помогут мне в моих грандиозных планах
C>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

хм. а если опуститься с небес на землю грешную? с чего вы к примеру взяли что "удаление С рудиментов" привнесет какой-то офигительный плюс языку? пока что ни одной конкретной идеи.

ИМХО.
"Я женился на первой же женщине, которая обратилась ко мне по мейлу." © Л. Торвальдс
Re[12]: Разработка языка-убийцы С++
От: vdimas Россия  
Дата: 21.02.08 09:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:


V>>При количестве типов типов объектов в несколько десятков и более, двойная диспечерезация пока что самая эффективная.


AVK>При чем тут двойная диспетчеризация? Двойная диспетчеризация просто используется, чтобы реализацию AcceptVisitor осуществлялась методом Copy-Paste. И все.


Не всё, сам по себе способ очень эффективный для техники полиморфизма, используемый в таких языках как С++, C#, Java. Т.е. такой способ эффективней, чем прямое определение типа узла и диспечеризация на if-ах или switch-ах.

V>>Разумеется, а зачем еще нужно определять тип узла.


AVK>Для диспетчеризации явно определять тип узла не обязательно. Можно, к примеру, просто сделать виртуальный метод. Диспетчеризация будет, определения типа узла нет.


Интересный взгляд на вещи. Вообще-то, двойная диспечеризация была изобретена именно для задач, где требовалось эффективно определять тип объекта в иерархии (визитор — лишь одна из таких задач). Пусть это "определение типа" выполняется неявно (т.е. тип напрямую не запрашивается), но суть от этого не меняется.


AVK>>>Код в кашу превращает исключительно програмимст.


V>>Сотня тысяч строк в одном файле — это каша в любом случае


AVK>Вот я и говорю — программист.


Ну вот передо мной файлы исходников на C# одного из компиляторов CORBA. Обработка узлов сделана классическим визитором, методы разнесены по файлам, суммарно более 100k только эта часть. Если оформить в виде единого паттерн-матчинга, т.е. запихнуть в один файл, то это будет страшно, независимо от запихивающего программиста. Там, конечно, будет экономия на пропавших заголовках методов визитора, но грубо 5%, вряд ли более.
Re[5]: Разработка языка-убийцы С++
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 24.03.08 22:23
Оценка:
Cpphater,

K>>>>Боюсь, ты опоздал. Есть Ruby, Nemerle, Template Haskell, Scheme, D и т.д. Зачем тебе ещё один?


AVK>>>Очевидно, у них у всех есть фатальный недостаток.

КД>>Я, я знаю какой Ну спросите, спросите меня
C>Спрашиваем, но сами тоже ответим
C>Ни один из них не является идейным потомком С++. Одни подслащают жизнь в отдельных областях, другие делают кодирование безопасным, третьи вообще чисто функциональные. Ни один из них не может рассматриваться как революционный шаг вперёд. Ни один из них не эффетивен как С. Продолжение будет следовать...

Выделенное неверно.

Собственно уже сейчас в Хаскелле и Схеме (я имею ввиду самые могучие реализации — Bigloo, Gambit, Chicken) реализованы такие оптимизации, реализуя ручками которые ты умрёшь прежде чем закончишь для сколь-нибудь сложной программы на С(++). Хотя судя по подходу тебя в-основном интересуют микрооптимизации.

Даже если так, то скажем Gambit Scheme отстаёт от чистого C в пределах 10-15%, причём тебе в C нужно будет ещё взять хороший компилятор и поездить по программе на С.

Вот здесь http://www.phildawes.net/blog/2007/04/21/some-hardcore-gambit-c-features/ товарищ подробно и с расстановкой объясняет, почему программа на Gambit Scheme может быть настолько быстрой, насколько вообще позволяет железо.

А вот здесь http://www.math.purdue.edu/~lucier/615/software/ собрано ПО для численных и символьных вычислений на Gambit Scheme. Можешь сам погонять и убедиться. Лично я гонял матричные вычисления и мне перфоманса хватило за глаза.

И кроме того, уж с чем-чем, а с метапрограммированием в Scheme (как и в любом Лисп-подобном языке) всё в полном порядке, C++-у такие возможности даже и не приснятся.

Короче, мой скептицизм мне подсказывает, что если чего у вас получится, то в соответствии с 10м законом Гринспуна... Я бы это время направил на изучение какого-нибудь инновационного языка. А может и просто в Лазер Танк поиграл — и то больше пользы...
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[6]: Разработка языка-убийцы С++
От: Cpphater Россия  
Дата: 25.03.08 06:32
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Выделенное неверно.

голословное утверждение, не доказаное последующим текстом.

LCR>Даже если так, то скажем Gambit Scheme отстаёт от чистого C в пределах 10-15%, причём тебе в C нужно будет ещё взять хороший компилятор и поездить по программе на С.

голословно, возможно и верно для ограниченного набора алгоритмов, но даже в этом случае фраза "не эффетивен как С" остаётся верна, т.к. эпсилон уж не 10-15%

LCR>Вот здесь http://www.phildawes.net/blog/2007/04/21/some-hardcore-gambit-c-features/ товарищ подробно и с расстановкой объясняет, почему программа на Gambit Scheme может быть настолько быстрой, насколько вообще позволяет железо.

беглый взгляд на статью не выявил этих объяснений.

LCR>А вот здесь http://www.math.purdue.edu/~lucier/615/software/ собрано ПО для численных и символьных вычислений на Gambit Scheme. Можешь сам погонять и убедиться. Лично я гонял матричные вычисления и мне перфоманса хватило за глаза.

для математики уж лучше фортран брать, он уж точно быстрее си

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

LCR>Короче, мой скептицизм мне подсказывает, что если чего у вас получится, то в соответствии с 10м законом Гринспуна... Я бы это время направил на изучение какого-нибудь инновационного языка. А может и просто в Лазер Танк поиграл — и то больше пользы...

Вот и играй.
от любви до ненависти...
Re: Разработка языка-убийцы С++
От: Аноним  
Дата: 25.03.08 20:56
Оценка:
Здравствуйте, Cpphater, Вы писали:

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

C>Идейную наследственность вижу в кардинальном усилении метапрограммной составляющей. Одновременное, с этим, кардинальное удаление С рудиментов должно породить язык необычайной выразительной мощи.
C>Ищу единомышленников, которые помогут мне в моих грандиозных планах
C>Разработка будет открытая (всё по BSD), основной язык имплементации С++, название языка 'Tany'

такой язык уже сотворили
C# называеться
идея была перескочить C/C++/Java как минимум
что получилось смотри сам

а вообще хотелось бы больше конкретики
например примеры C++ и твоего языка

PS
а то тут на форуме флуд развели какой парсер лучше для языка
сколько кто знает компиляторов хотя бы того же C/C++ в которых используеться вся та туфта которую тут перечиляли?
flex/bison и больше нет
а все остальное тотже AST итд для парсинга программерского хлама....
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.