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

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

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

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

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

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

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

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

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

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

1. В чем новизна?
2. Какие языки ты уже изучил? Другими словами кроме С++, ты что знаешь? Какие концепции и парадигмы изучи (ФЯ, ЛП...)?
3. Почему твой язык предпочтут скажем тому же С++0х?
4. Что будешь делать с совместимостью. Ведь выбросив С-шную грязь, ты потеряешь и совместимость.

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

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

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

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

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

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

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

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

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

Список состоит только из языков поддерживающих компиляции (хоть как-то... если кто начнет тыкать пальцем в Лисп).

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

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

ЖЦ там как раз опциональный. Насколько я знаю С++0х тоже будет в какой-то степени поддерживать ЖЦ.

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИМХО.

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


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

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

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

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

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

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


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

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

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

Ну вот передо мной файлы исходников на C# одного из компиляторов CORBA. Обработка узлов сделана классическим визитором, методы разнесены по файлам, суммарно более 100k только эта часть. Если оформить в виде единого паттерн-матчинга, т.е. запихнуть в один файл, то это будет страшно, независимо от запихивающего программиста. Там, конечно, будет экономия на пропавших заголовках методов визитора, но грубо 5%, вряд ли более.

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м законом Гринспуна... Я бы это время направил на изучение какого-нибудь инновационного языка. А может и просто в Лазер Танк поиграл — и то больше пользы...

Здравствуйте, 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м законом Гринспуна... Я бы это время направил на изучение какого-нибудь инновационного языка. А может и просто в Лазер Танк поиграл — и то больше пользы...
Вот и играй.

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

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

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

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

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