Здравствуйте, WolfHound, Вы писали:
WH>Мягко говоря сомнительная функциональность. WH>Мало того что она ставит крест на агрессивных оптимизациях
И чем это ставит крест на оптимизациях Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз.
WH>но что во много раз хуже данная функциональность превращает код в тАкую лапшу что функция на 10К строк с кучей goto покажется кристально ясной.
Вы пробовали разобраться в исходниках буста ?? Особливо в части mpl!
Здравствуйте, lexis_t, Вы писали:
_>И чем это ставит крест на оптимизациях Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз.
Это делает практически не возможным анализ потоков данных.
И как следствие убивает такие оптимизации как region inference или даже банальное вынесение проверок границ массивов за приделы цикла.
_>Вы пробовали разобраться в исходниках буста ?? Особливо в части mpl!
Хочешь чтобы весь код был таким?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>И чем это ставит крест на оптимизациях Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз. WH>Это делает практически не возможным анализ потоков данных. WH>И как следствие убивает такие оптимизации как region inference или даже банальное вынесение проверок границ массивов за приделы цикла.
_>>Вы пробовали разобраться в исходниках буста ?? Особливо в части mpl! WH>Хочешь чтобы весь код был таким?
1. Я думаю в вопросе оптимизации можно достичь приемлемого компромиса... Можно немного доработать синтаксис, открывать доступ не ко всем локальным переменным, вообще компилировать без этой фичи..
2. Возможность доступа к локальным переменным выше по стеку вовсе не означает, что нужно позволять лезть туда из любого места программы! Эта возможность должна быть ограничена чисто синтаксически, самой возможностью получения указателя на кадр-объект стека, которому к тому же должен быть ассоциирован правильный тип
Здравствуйте, lexis_t, Вы писали:
_>1. Я думаю в вопросе оптимизации можно достичь приемлемого компромиса... Можно немного доработать синтаксис, открывать доступ не ко всем локальным переменным, вообще компилировать без этой фичи.. _>2. Возможность доступа к локальным переменным выше по стеку вовсе не означает, что нужно позволять лезть туда из любого места программы! Эта возможность должна быть ограничена чисто синтаксически, самой возможностью получения указателя на кадр-объект стека, которому к тому же должен быть ассоциирован правильный тип
Реально тут возникает еще куча вопросов. Мне лень перечислять.
А главное не ясно нафига все эти сложности вобще нужны?
Что мы получим то?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lexis_t, Вы писали:
_>Если представить, что каждая функция — это специальный класс, а при вызове функции на стеке создается объект с типом функция-класс... _>Таким образом появляется возможность адресовать переменные, лежащие выше по стеку, если имеется указатель на кадр стека и конкретный тип (то есть класс-функция). _>Фактически для компилятора ничего не поменяется, в стеке будут лежать все те же локальные переменные (упакованные в класс), но при обработке исключительной ситуации будет теоретическая возможность добраться до их значений (до раскручивания стека) и даже исправить!
Никакого отношения к способу "упаковки переменных" эта возможность не имеет. Это раз. _>А потом восстановить прежнюю точку выполнения и продолжить как ни в чем не бывало!
Эта — тоже. Это два.
Непонятно, чего хочется.
1. Получить при обработке, скажем, исключения, не только ссылку на описание метода, но и на фактические значения параметров и переменных — приятно, но обычно чрезмерно дорого. Поясняю: в жизни самые популярные переменные попадают в регистры, и их значения безнадежно теряются при спуске вниз по стеку. Это неудобно при отладке, зато позволяет эффективно использовать ресурсы машины и получать значительную оптимизацию. Если заставлять всё размещать на стеке, то эффективность некоторых алгоритмов упадет на порядки.
2. Стартовать выполнение с того места, где оно было прервано, можно независимо от того, каким образом хранится стек. Обычно это не удается сделать по чисто синтаксическим причинам — довольно сложно себе представить современный язык высокого уровня, в котором логика такого продолжения достаточно прозрачна.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Непонятно, чего хочется. S>1. Получить при обработке, скажем, исключения, не только ссылку на описание метода, но и на фактические значения параметров и переменных — приятно, но обычно чрезмерно дорого. Поясняю: в жизни самые популярные переменные попадают в регистры, и их значения безнадежно теряются при спуске вниз по стеку. Это неудобно при отладке, зато позволяет эффективно использовать ресурсы машины и получать значительную оптимизацию. Если заставлять всё размещать на стеке, то эффективность некоторых алгоритмов упадет на порядки.
Почему все дружно бросились объяснять, что это невозможно??? и не имеет смысла???
Все что заранее имеет смысл — уже придумано и реализовано. А не придумано и не реализовано то, смысл чего понять заранее тяжело. Окончательно смысл будет понятен лет через дцать после первой реализации.
Лично у меня за годы программирования много раз встречались ситуации, где возможность изменить значения локальных переменных на лету сэкономила бы дни работы и сделала бы архитектуру намного более прозрачной.
S>2. Стартовать выполнение с того места, где оно было прервано, можно независимо от того, каким образом хранится стек. Обычно это не удается сделать по чисто синтаксическим причинам — довольно сложно себе представить современный язык высокого уровня, в котором логика такого продолжения достаточно прозрачна.
Вот я и предлагаю подход, при котором такое продолжение будет прозрачным именно с точки зрения синтаксиса.
Если смотреть на вопрос "объектного стека" с точки зрения философии программирования, то я бы отметил следующие вещи:
1. Определение функций как специальных классов доводит ОО парадигму яыка до логического завершения.
2. Объектный, типизированный стек вызовов дает языку новый мощный и выразительный механизм (как его использовать можно обсуждать в будущем. Я могу предположить его использование от тупого облегчения обработки ошибок, до нового подхода при составлении алгоритмов...)
3. Противоречия между моделью языка высокого уровня и реальной архитектурой железа, читай проблемы оптимизации были всегда.. но всегда находились и компромиссы. Так было еще со страничной организацией памяти, так есть с RTTI...
Здравствуйте, lexis_t, Вы писали:
_>Почему все дружно бросились объяснять, что это невозможно???
Где?
_>и не имеет смысла???
А он есть?
_>Все что заранее имеет смысл — уже придумано и реализовано. А не придумано и не реализовано то, смысл чего понять заранее тяжело. Окончательно смысл будет понятен лет через дцать после первой реализации.
Так реализации схем типа твоей уже были. Так сразу языки не вспомню но точно помню что гдето было.
Вот только они оказались нафиг никому не нужны.
_>Лично у меня за годы программирования много раз встречались ситуации, где возможность изменить значения локальных переменных на лету сэкономила бы дни работы и сделала бы архитектуру намного более прозрачной.
Примеры в студию.
Ибо лично у меня вобще ни разу жилания не возникало делать подобные вещи.
А поработав с функциональными языками так и вобще большую часть переменных делаю не изменяемой.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lexis_t, Вы писали:
_>1. Определение функций как специальных классов доводит ОО парадигму яыка до логического завершения.
Есть мнение что использование ОО на уровне методов вобще говоря идея плохая.
ИМХО куда лучше оставить ОО на уровне дизайна высокого уровня, а вычисления делать в функциональном стиле.
Смотри на http://nemerle.org
_>2. Объектный, типизированный стек вызовов дает языку новый мощный и выразительный механизм (как его использовать можно обсуждать в будущем.
Не показал чего он дает.
Напиши псевдокод.
_>Я могу предположить его использование от тупого облегчения обработки ошибок,
Каким образом?
_>до нового подхода при составлении алгоритмов...)
Если ты придумаешь новый способ составления алгоритмов то премия Тьюрига тебе обеспечена.
_>3. Противоречия между моделью языка высокого уровня и реальной архитектурой железа, читай проблемы оптимизации были всегда.. но всегда находились и компромиссы. Так было еще со страничной организацией памяти,
1)Давно в прошлом.
2)При наличии нормальной VM страничная организация адресного пространства не проблема.
_>так есть с RTTI...
А причем тут железо вобще?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
1. Прога на асме (если руки из плечей) всегда будет работать быстрее, чем С++, и уж подавно чем ВИРТУАЛЬНАЯ МАШИНА! нах с++ и .нет!
2. Если плюсы подхода нужны только мне, то ради меня вставлять новую фичу в язык не надо. Если их вижу ТОЛЬКО я, значит из меня хреновый программер!
3. Извините, что не получилось здоровой дискуссии и бла-бла-бла...
Здравствуйте, lexis_t, Вы писали:
_>1. Прога на асме (если руки из плечей) всегда будет работать быстрее, чем С++, и уж подавно чем ВИРТУАЛЬНАЯ МАШИНА! нах с++ и .нет! _>2. Если плюсы подхода нужны только мне, то ради меня вставлять новую фичу в язык не надо. Если их вижу ТОЛЬКО я, значит из меня хреновый программер!
Некорректная логика. Может быть, ты просто хреновый объясняльщик? _>3. Извините, что не получилось здоровой дискуссии и бла-бла-бла...
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Я не люблю, когда цепляются к словам...
К тому же, просто с точки зрения любого открытого проекта, любые сложные новые вещи получаются только тогда, когда еть единомышленники, которые понимают друг-друга без разжевывания мыслей.
А уж извините приводить в пример оптимизацию при компиляции С++ под VM, или предлагать написать псевдокод... я не заказчик и здесь никто не обсуждает никаких спецификаций даже в нулевом приближении...
Здравствуйте, lexis_t, Вы писали:
_>К тому же, просто с точки зрения любого открытого проекта, любые сложные новые вещи получаются только тогда, когда еть единомышленники, которые понимают друг-друга без разжевывания мыслей.
Любые сложные новые вещи получаются только тогда, когда есть хотя бы один человек, хорошо понимающий, что они такое. В большинстве случаев неспособность объяснить связана со слабым пониманием. _>А уж извините приводить в пример оптимизацию при компиляции С++ под VM, или предлагать написать псевдокод... я не заказчик и здесь никто не обсуждает никаких спецификаций даже в нулевом приближении...
Это тебе пытаются помочь: раз ты не можешь сформулировать свою идею на простом русском языке — сформулируй на языке программирования. Если ты не можешь привести пример псевдокода с тем синтаксисом, которого ты хочешь, значит ты не знаешь, какого синтаксиса ты хочешь.
Если ты не можешь объяснить, какие преимущества даст "объектный стек", значит ты не знаешь, есть ли преимушества вообще.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>>>Ни алгебраических типов. WH>>>Ни сравнения с образцом. WH>Позволяют гораздо проще работать с AST. WH>Например попробуй представить как это
Здравствуйте, _Obelisk_, Вы писали:
_O_>Паттерн матчинг используется при обработке AST-а ...
Ну, и какой это к черту парсер на С++? Это пол компилятора написанного на специализированно средстве генерирующем С-код в качестве выхода. С тем же успехом можно было генерировать маш.код.
Так причем тут С++?
ЗЫ
А можно в килобайтах, а не в строках кода. А то строчки мерять влом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Не, специально заточенные языки для описания AST-ов и их трансформаций гораздо удобней, чем любой язык программирования общего назначения.
Что воздух сотрясать? Давай померяемся?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Т.е. я спокойно смешиваю формальную спецификацию на Cocktail-е, с вызовом С++-ых функций. _O_>Не думаю, что OCaml мне это позволит. Правда я его не знаю
ОКамл тебе позволит не заниматься фигей, а работать на одном языке обладающем всеми фичами вашего любимого Коктеля, но при том еще рядом очень приятных вкусностей.
Другое дело, что Коктель вам предоставляет массу, скажем так, библиотек и утилит. В общем, массу уже написанного кода. Ведь как не просто было бы на ФЯ написать вывод АСТ в текст, но если он уже есть, то работы будет меньше по любому.
Так что если сранвинвать языки, то С++ несомненно лузер в области компиляторо строения. А если гтовые фрэймворки, то лучше тот, что содержит больше фич и имеет более высокое качество.
_O_>Проблема с ФЯ в том, что их трудно интегрировать с другими языками и другими API.
Ну, вот тот же Немерле интегрируется с C++, C#, VB и другими языками сносно поддерживающими дотент. Вот только чем боьше на нем пишешь, тем сеньше хочешь писать на других.
_O_> Особенно, если требуется платформонезависимость. А переписать все систему, где несколько миллионов строк кода на С++ на каком-либо ФЯ нам не дадут
Это другой вопрос. Но зачем было писать эти миллионы строк? К тому же только что их было 9000.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Я конечно никогда не занимался написанием компиляторов, но на пальцах объясните, плиз.
?? Особливо в части mpl!
