Здравствуйте, wat3rs, Вы писали:
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
W>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
Я этой темой занимался. Даже, в свое время диссертацию написал "особенности синтаксического анализа открытых контекстно-свободных языков" . Языки с расширяемым синтаксисом называют открытыми. В том смысле, что пользователь может динамически изменять грамматику языка. Если изменяется только синтаксис, язык называется синтаксически открытым, а если еще и лексика -- лексически открытым.
Основными особенностями синтаксиса открытых языков являются:
1. Грамматика с любыми возможными правилами. Поэтому, нужен алгоритм анализа, который обрабатывает любую грамматику без ограничений типа LALR(k) или LL(k), т.е. бизоны и антиэлэры не подойдут.
2. Грамматика большая, пользователи могут много чего навводить. Значит, нужен алгоритм анализа, который не тормозит на больших грамматиках.
3. Синтаксические неоднозначности, поэтому нужен алгоритм, который с этими неоднозначностями хорошо работает.
Когда такой алгоритм создан, надо предоставить пользователю хороший способ расширять синтаксис. Т.е. надо придумать "начальную" грамматику, в которую входили бы правила для расширения языка, -- ядро открытого языка. На основе ядра можно расширять язык.
Надо придумать, как задавать семантику синтаксических конструкций. Это тоже непросто, нужна формальная модель вычисления по дереву представления (если это КС-грамматика) текста. Это тоже надо придумать. Для языков программирования можно не заморачиваться и выражать семантику на том языке программирования, который будет расширяться.
Лексику можно расширять с помощью синтаксиса регулярных выражений. Каждый лексический тип описывается своим регулярным выражением, которое потом транслируется в конечный автомат. Лексический анализатор запускает такие автоматы параллельно и таким образом выделяет токены из текста.
Самое важно, что необходимо понять -- открытость языка подразумевает, что есть сообщество, которое этот язык понимает, потому как каждый язык представляет собой результат договоренности. Ты этого коснулся немного, но по другому поводу.
Для языков программирования я вижу основное применение расширяемых языков программирования -- это кастомизация кода программы под конкретную инженерную задачу. Чтобы не описывать в терминах шаблонов или там классов, а напрямую -- посредством тех синтаксических конструкций, которые выражают мир этой задачи.
Вообще, здесь много чего можно рассказать, проблема большая.
Здравствуйте, wat3rs, Вы писали:
W>В идеале кастомный синтаксис должен быть чем-то типа скина. Чтоб его можно было настроить так же , как и цветовую схему в редакторе. Однако, если ведётся командная разработка, где часто надо смотреть в чужой код (и объяснять, почему он не компилится), то такая кастомизация будет вызывать проблемы (да и чужая схема подсветки может сильно раздражать).
W>Безусловно (пока это не стало мейнстримом ) если программист пользуется своим синтаксисом, то ему все равно надо знать стандартный, хотя бы на уровне чтения. Иначе таки придётся с собой на флешке носить std2john и john2std. Так же, как если вы дома настроили под себя какой-либо инструмент (например поменяли кей-биндинги), то чтобы работать с ним в другом месте — нужно или помнить стандартные, или носить свои конфиги.
W>Интеграция с VCS таки действительно может стать проблемой, но думаю, это решаемо.
Мне кажется, что проблема здесь — именно разрешение кастомизации синтаксиса. Почему это проблема, а не решение — да просто потому что она добавится к списку уже существующих проблем, которые требуется решать в командных разработках:
* чужая схема подсветки — (меньшая из проблем, но уже помянутая)
* различные взгляды на форматирование кода (не самая большая проблема)
* различные предпочтения при композиции кода и выборе абстракций (уже очень большая проблема, т.к. там где одному нужна гибкость для тестирования, второй предпочтет улучшение читаемости с затруднением тестирования)
* различные парадигменные подходы (если я начну писать на чистом ФП в чисто императивной команде, это будет фактически приравниваться к саботажу)
Добавляем сюда кастомизацию синтаксиса и вместо команды получаем набор индивидуалов, пишуших почти на разных языках и не способных объясняться друг с другом.
Как же решаются вышеперечисленные проблемы (кроме подсветки синтаксиса) в команде? Соглашением! Если что-то кому-то не нравится, то он идет в баню, потому как есть соглашения (форматирования кода, метрики связности, покрытие тестами, и прочая кухня), направленные на унификацию хотя бы в пределах команды.
Если бы мне попался язык с возможностью кастомизации синтаксиса, я бы первым делом составил командное соглашение об использовании единого синтаксиса.
Здравствуйте, wat3rs, Вы писали:
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
из-за того, что вкусы разные, мне будет лень учить синтаксис каждого члена тима разработки, а им будет лень учить мой синтаксис — как тогда ревювать код? а если он мне скажет: "посмотри, у меня здесь почему-то не компилится" или ещё что-нить в таком духе — и у каждого свой синтаксис ) так что, постоянно std2me-me2std? ужас, правда? а если я его всё-же "выучу", что-нибудь забуду, не предусмотрю и допущу досадный трудноуловимый баг? как дебаггать тогда вообще? а если мой синтаксис будет куда более изощрён, нежели синтаксис товарища, сидящего слева, и его вариант не будет поддерживать "новой фичи, которую я только что от нечего делать придумал"? мне ради собственной эстетики придётся отвлечься на написание ещё какого-нибудь рула в лексере/грамматике — и так, пожалуй, будет вечно ) короче говоря, неоправданная трата времени в любом случае получается
W>Тогда можно сделать такую утилиту std-to-john : она будет брать на вход обычный файл с исходниками на некотором языке и конвертить его в синтаксис Джона для этого языка. А чтобы скомпилировать джонов код, будет утилита john-to-std, которая будет делать то же самое, но наоборот
а как же без этого ) кстати, чей именно синтаксис будет использоваться при сабмитах в svn? только std? :D и толку тогда от своего синтаксиса? это сулит постоянную возню с тулзой std2me/me2std, причём вплоть до таскания оной на флешке в самих экзотических ситуациях (а такие, конечно же, бывают)
У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
Было бы классно иметь возможность настроить синтаксис языка программирования под себя. Я знаю, что из всех языков в этом направлении продвинулись лиспы (common lisp / scheme), в основном за счёт практически полного отсутствия этого синтаксиса
Но, как я понимаю, и для лиспа есть нерешаемые средствами языка задачи. Например, насколько проблематично реализовать поддержку инфиксной нотации? (я знаю, что есть макрос prefix->infix, так что задача вроде решаема). А использование квадратных скобочек для списков? Индентации как в питоне — чтобы меньше скобочек надо было ставить? Brackets for lists и принудительную индентацию, как я понимаю, никак нельзя сделать средствами языка, т.е. для этого нужен некий внешний преобразователь.
В идеале я вижу custom syntax так: Джон использует свой синтаксис, а Джим — свой. IDE должна позволять Джону посмотреть код Джима, автоматически преобразуя его в джоновый (и наоборот). Т.е. если Джон предпочитает писать null, а Джим — nil, то когда Джон открывает файл, созданный Джимом, программа должна заменить все nil на null.
Тогда можно сделать такую утилиту std-to-john : она будет брать на вход обычный файл с исходниками на некотором языке и конвертить его в синтаксис Джона для этого языка. А чтобы скомпилировать джонов код, будет утилита john-to-std, которая будет делать то же самое, но наоборот. Нужна ещё будет утилита , которая будет преобразовывать сообщения об ошибках так, чтобы , например, заменялся номер строки и столбца.
Я думаю, это теоретически реализуемо, однако никогда о таком не слышал. А очень хотелось бы. Во многих языках мне не нравятся те или иные стилистические решения, и, думаю, я не одинок. Было бы прекрасно иметь такой инструмент, который, например, позволил бы писать поменьше скобок и запятых в языках типа python-a, а то мне после знакомства с хаскелем очень лень стало писать эти "лишние" знаки
Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, VladD2, Вы писали:
VD>>Но что это даст?
Т>Возможно, это позволит избежать флейма на тему "что лучше: {} или begin end".
Здравствуйте, wat3rs, Вы писали:
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
W>Было бы классно иметь возможность настроить синтаксис языка программирования под себя. Я знаю, что из всех языков в этом направлении продвинулись лиспы (common lisp / scheme), в основном за счёт практически полного отсутствия этого синтаксиса
W>В идеале я вижу custom syntax так: Джон использует свой синтаксис, а Джим — свой. IDE должна позволять Джону посмотреть код Джима, автоматически преобразуя его в джоновый (и наоборот). Т.е. если Джон предпочитает писать null, а Джим — nil, то когда Джон открывает файл, созданный Джимом, программа должна заменить все nil на null.
W>Какие ещё проблемы могут возникнуть?
Код просматривают не только в IDE, но и в книжках, в документации.
Здравствуйте, wat3rs, Вы писали:
W>Но, как я понимаю, и для лиспа есть нерешаемые средствами языка задачи. Например, насколько проблематично реализовать поддержку инфиксной нотации? (я знаю, что есть макрос prefix->infix, так что задача вроде решаема). А использование квадратных скобочек для списков? Индентации как в питоне — чтобы меньше скобочек надо было ставить? Brackets for lists и принудительную индентацию, как я понимаю, никак нельзя сделать средствами языка, т.е. для этого нужен некий внешний преобразователь.
Неверно понимаете смысл построения DSL в Лиспе. DSL в Лиспе обычно тоже выражаются в s-expressions. Все остальное, считаются не идиоматическими решениями, для примера смотрим loop, который очень многие Лисперы не любят.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, wat3rs, Вы писали:
W>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, wat3rs, Вы писали:
W>>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
M>Синтаксис во многом завязан на правила именования. Одни любят писать ObjectInctance.KillMyself(), другие obj_instance->kill_myself(), третьи objectInstance.suicide();
А четвёртые (и, может, пятые) знают правила языка, на котором имена записывают, и не используют myself в данном случае
Здравствуйте, mefrill, Вы писали:
M>Я этой темой занимался. Даже, в свое время диссертацию написал "особенности синтаксического анализа открытых контекстно-свободных языков" .
А нет ли ее в электронном виде, можно ли почитать?
Здравствуйте, Qbit86, Вы писали:
Q>Бог с ним, с синтаксисом. Лексику хотя бы кастомизировать!
Да, это тоже очень классно. Нормальная юникодовая λ вместо lambda или хаскелевского бекслеша — это довольно удобно. Хотя IDE leksah умеет заменять уродцев на красавцев.
Ммм, предвижу большой метасрач.
W>Например, насколько проблематично реализовать поддержку инфиксной нотации? (я знаю, что есть макрос prefix->infix, так что задача вроде решаема).
Принципиальных сложностей, вроде и нет. Надо определиться с тем, как задавать и различать доступные операторы и их приоритеты, как понимать, где переходить обратно к префиксной записи (при задании лямбд например) и т.д. Ну и написать парсер.
W>А использование квадратных скобочек для списков? Индентации как в питоне — чтобы меньше скобочек надо было ставить? Brackets for lists и принудительную индентацию, как я понимаю, никак нельзя сделать средствами языка, т.е. для этого нужен некий внешний преобразователь.
Одна из особенностей лиспа в том, что программа на языке является структурой данных этого языка. Т.е. текстовое представление структур данных должно быть отделено от их семантики. Если достаточно изменить синтаксис литералов (например, вид скобок для списков) — надо твикать ридер (часть интерпретатора, преобразующую текст в структуры данных) — некоторые имплементации это позволяют (например, plt scheme). Соответственно, при реализации синтаксиса с индентациями — lisp way будет придумать способ преобразования индентированного текста в список — но это довольно неудачная идея, на мой взгляд.
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д. W>В идеале я вижу custom syntax так: Джон использует свой синтаксис, а Джим — свой. IDE должна позволять Джону посмотреть код Джима, автоматически преобразуя его в джоновый (и наоборот). Т.е. если Джон предпочитает писать null, а Джим — nil, то когда Джон открывает файл, созданный Джимом, программа должна заменить все nil на null. W>Тогда можно сделать такую утилиту std-to-john : она будет брать на вход обычный файл с исходниками на некотором языке и конвертить его в синтаксис Джона для этого языка. А чтобы скомпилировать джонов код, будет утилита john-to-std, которая будет делать то же самое, но наоборот. Нужна ещё будет утилита , которая будет преобразовывать сообщения об ошибках так, чтобы , например, заменялся номер строки и столбца.
Внимание, вопрос. Нахрена?. В мире столько разнообразных парадигм программирования — с которыми можно эксперементировать. А от того, что в отдельно взятом языке мы заменим одни токены на другие — он не станет ни лучше, ни хуже — а мы лишь впустую потратим время.
Здравствуйте, wat3rs, Вы писали:
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
W>Было бы классно иметь возможность настроить синтаксис языка программирования под себя.
В поставку Окамла входит препроцессор camlp4, позволяющий вытворять с синтаксисом что угодно. Например: http://caml.inria.fr/pub/docs/manual-camlp4/manual007.html (почти полная переделка языка — revised syntax)
Но там преобразование в одну сторону, std-to-john там нет.
Здравствуйте, wat3rs, Вы писали:
W>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor
1. Думаю это вполне реально.
2. Но на первых порах замучаешься писать интеграцию с IDE, SVN...
3. Зато потом это может дать рельно новый взгляд на код и понимание проблем в целом
Спасибо за ссылки, они довольно любопытные. Структурированный редактор — это отличная идея.
Понял, что протупил с примером, т.к. null и nil — это не обязательно синтаксис, более хороший пример будет таким: Джон хочет, чтобы в C++ или Java везде, где это возможно, перевод строки заменял точку с запятой, а отступ — фигурные скобоки. Тогда hello world Джон напишет примерно так:
#include <iostream>
using namespace std
void main ()
cout << "Hello, world!"
cout << endl
В идеале кастомный синтаксис должен быть чем-то типа скина. Чтоб его можно было настроить так же , как и цветовую схему в редакторе. Однако, если ведётся командная разработка, где часто надо смотреть в чужой код (и объяснять, почему он не компилится), то такая кастомизация будет вызывать проблемы (да и чужая схема подсветки может сильно раздражать).
Безусловно (пока это не стало мейнстримом ) если программист пользуется своим синтаксисом, то ему все равно надо знать стандартный, хотя бы на уровне чтения. Иначе таки придётся с собой на флешке носить std2john и john2std. Так же, как если вы дома настроили под себя какой-либо инструмент (например поменяли кей-биндинги), то чтобы работать с ним в другом месте — нужно или помнить стандартные, или носить свои конфиги.
Интеграция с VCS таки действительно может стать проблемой, но думаю, это решаемо.
Здравствуйте, wat3rs, Вы писали:
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
Синтаксис во многом завязан на правила именования. Одни любят писать ObjectInctance.KillMyself(), другие obj_instance->kill_myself(), третьи objectInstance.suicide();
Здравствуйте, Andir, Вы писали:
W>>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
A>Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor
Еще бы надо заменять public, static (слишком их много в C#) на какие то иероглифы,значки.
Здравствуйте, Курилка, Вы писали:
К>А четвёртые (и, может, пятые) знают правила языка, на котором имена записывают, и не используют myself в данном случае
Тогда уже suicide, просто я придумывал идентификатор из двух слов.
Здравствуйте, AndrewVK, Вы писали:
S_>> Еще бы надо заменять public, static (слишком их много в C#) на какие то иероглифы,значки.
AVK>Не надо. Весь цимус в том, что текст никуда не девается и не меняется.
Текст можно и не трогать в файлах, а на экране чтобы после написания public сворачиволось в какую-то иконку.
Или хотя бы в обычной студии другим цветом показыать public,private чтобы с основным текстом не сливалось.
А для выделения структуры действительно что-то нужно. Кнопок сворачивания недостаточо. Но так чтобы быстро строчить не мешало.
Я для #region как-то поменял цвет фона(сделал слегка темнее белого), и даже удивился насколько такая мелочь улучшает читабельность, когда много #region.
Здравствуйте, mefrill, Вы писали:
M>Я этой темой занимался. Даже, в свое время диссертацию написал "особенности синтаксического анализа открытых контекстно-свободных языков" . Языки с расширяемым синтаксисом называют открытыми. В том смысле, что пользователь может динамически изменять грамматику языка. Если изменяется только синтаксис, язык называется синтаксически открытым, а если еще и лексика -- лексически открытым.
В теме говорилось немного о другом. Если я правильно понял автора темы, он предлагал сделать один язык (с токи зрения семантики), но который позволял бы автоматически конвертировать код в разные синтаксические представления.
Данная задача решается путем написания нескольких парсеров и генераторов кода. Тогда, скажем, средствами IDE можно будет автоматически конвертировать код в нужый синтаксис.
Ты же описываешь другую задач — создание расширяемого языка.
M>Основными особенностями синтаксиса открытых языков являются: M>1. Грамматика с любыми возможными правилами. Поэтому, нужен алгоритм анализа, который обрабатывает любую грамматику без ограничений типа LALR(k) или LL(k), т.е. бизоны и антиэлэры не подойдут.
Вовсе не обязательно. Расширение можно ограничить некоторыми разумными рамками.
M>2. Грамматика большая, пользователи могут много чего навводить. Значит, нужен алгоритм анализа, который не тормозит на больших грамматиках.
Если отбросить первый пункт, то и этот проблемой являться не будет. Иначе выбор будет из двух вариантов: PEG и GLR.
M>3. Синтаксические неоднозначности, поэтому нужен алгоритм, который с этими неоднозначностями хорошо работает.
Опять же не обязательно. Можно просто ругаться на неоднозначности.
В прочем, хорошим решением является использование PEG-а. Он по определению однозначен.
M>Когда такой алгоритм создан, надо предоставить пользователю хороший способ расширять синтаксис. Т.е. надо придумать "начальную" грамматику, в которую входили бы правила для расширения языка, -- ядро открытого языка. На основе ядра можно расширять язык.
M>Надо придумать, как задавать семантику синтаксических конструкций. Это тоже непросто, нужна формальная модель вычисления по дереву представления (если это КС-грамматика) текста. Это тоже надо придумать. Для языков программирования можно не заморачиваться и выражать семантику на том языке программирования, который будет расширяться.
Такой механизм давно придуман в Лиспе — макры. В качестве примера языка с синтаксисом — макры Nemerle.
M>Лексику можно расширять с помощью синтаксиса регулярных выражений. Каждый лексический тип описывается своим регулярным выражением, которое потом транслируется в конечный автомат. Лексический анализатор запускает такие автоматы параллельно и таким образом выделяет токены из текста.
M>Самое важно, что необходимо понять -- открытость языка подразумевает, что есть сообщество, которое этот язык понимает, потому как каждый язык представляет собой результат договоренности. Ты этого коснулся немного, но по другому поводу.
Ну, язык может мимикрировать под другие языки. Все что выходит за их пределы можно рассматривать как расширения.
Если используется идеология макросов, то вопрос о форме расширений решается сам собой.
M>Для языков программирования я вижу основное применение расширяемых языков программирования -- это кастомизация кода программы под конкретную инженерную задачу. Чтобы не описывать в терминах шаблонов или там классов, а напрямую -- посредством тех синтаксических конструкций, которые выражают мир этой задачи.
Это только часть возможностей. И у этого подхода есть четко определенное название — DSL-естроение, т.е. создание внешний и встроенных языков предметной области.
M>Вообще, здесь много чего можно рассказать, проблема большая.
Ага. Только это не та проблема которую описал автор темы. Эта проблема (описанная тобой) меня интересует. А вот проблема поднятая автором темы — это баловство. От языка мне в первую очередь нужна семантика. Синтаксические различия я переживу. А автор темы предлагает сделать общую семантическую базу и разный синтаксис. Такие языки уже есть: Delphi .Net, VB .Net и C#. За малый исключением они конвертируемы друг в друга. Не так сложно встроить автоматическую их конвертацию в IDE.
Что же касается языков с расширяемым синтаксисом и семантикой, то — это очень интересное и перспективное направление развития ЯП. Собственно Nemerle (которым я увлекся в последние годы) является чуть ли не единственным пригодным к использованию представителем такого языка если не брать в рассчет диалекты Лиспа (так как они не имеют синтаксиса как такового) и некоторое количество исследовательских работ (которые не пригодны для практического использования).
В наших планах пересадить Nemerle на PEG, тем самым, практически, убрав ограничения на расширение синтаксиса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, wat3rs, Вы писали:
W>Было бы классно иметь возможность настроить синтаксис языка программирования под себя.
Это бессмысленно, так как возможности языка определяются исключительно его семантикой и рантаймом.
Сделать конвертер синтаксиса не так сложно. Но нужно иметь общую семантическую базу. Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.
Но что это даст? Возможность посадить за один проект программистов знающих разные языки? Насколько это актуально?
Лично мне интересно иметь возможность расширять язык таким образом, чтобы можно было уменьшать сложность решения различных прикладных задач. Для этого язык должен позволять создавать DSL-и (внешние и/или внутренние, т.е. встроенные в язык). А как только язык расширяется, то он выходит за рамки возможностей усредненного мэйнстрим-языка и конвертировать его код в разные Delphi .Net, VB .Net и C# будет просто невозможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это бессмысленно, так как возможности языка определяются исключительно его семантикой и рантаймом.
VD>Сделать конвертер синтаксиса не так сложно. Но нужно иметь общую семантическую базу. Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.
Когда я только начал изучать .NET + C# (году эдак в 2001-2002) меня жутко бесили статьи в МСДНе, в которых примеры были только на VB.NET.
VD>Лично мне интересно иметь возможность расширять язык таким образом, чтобы можно было уменьшать сложность решения различных прикладных задач. Для этого язык должен позволять создавать DSL-и (внешние и/или внутренние, т.е. встроенные в язык). А как только язык расширяется, то он выходит за рамки возможностей усредненного мэйнстрим-языка и конвертировать его код в разные Delphi .Net, VB .Net и C# будет просто невозможно.
+1. В качестве общей семантической базы можно вообще использовать машинный код. Тогда конвертор *-to-std будет называться компилятором, а std-to-* — декомпилятором.
Здравствуйте, Mazay, Вы писали:
M>+1. В качестве общей семантической базы можно вообще использовать машинный код. Тогда конвертор *-to-std будет называться компилятором, а std-to-* — декомпилятором.
А какой машинный код?
Java bytecode? x86 assembly?
Здравствуйте, Курилка, Вы писали:
M>>+1. В качестве общей семантической базы можно вообще использовать машинный код. Тогда конвертор *-to-std будет называться компилятором, а std-to-* — декомпилятором.
К>А какой машинный код? К>Java bytecode? x86 assembly?
Для общности — x86+x64 assembly. Java bytecode все равно JIT Compiler'ом в машинный переводится потом. Вот с интерпертируемыми языками уже хуже.
Здравствуйте, VladD2, Вы писали: VD>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.
Угу, и код с yield превращает в фарш. Еще интересно было бы посмотреть, во что превращаются в переложении на сишарп отсутствующие в нем фичи vb.net-а (напрмиер, параметры по умолчанию — хотя в шарп их добавили, late bunding — и т.п.).
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, VladD2, Вы писали: VD>>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки. MC>Угу, и код с yield превращает в фарш. Еще интересно было бы посмотреть, во что превращаются в переложении на сишарп отсутствующие в нем фичи vb.net-а (напрмиер, параметры по умолчанию — хотя в шарп их добавили, late bunding — и т.п.).
Ты внимательно прочитал то, что я написал? Заметил слова "некоторого подмножества".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>>>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки. VD>Ты внимательно прочитал то, что я написал? Заметил слова "некоторого подмножества".
Хм. Ну значит я тебя (а конкретно — твое двоеточие) не так понял.
Здравствуйте, Mr.Cat, Вы писали:
VD>>>>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки. VD>>Ты внимательно прочитал то, что я написал? Заметил слова "некоторого подмножества". MC>Хм. Ну значит я тебя (а конкретно — твое двоеточие) не так понял.
Сори. Действительно звучит двояко. Но я имел в виду именно подмножества этих языков. Они процентов на 99 пересекаются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
а если он мне скажет: "посмотри, у меня здесь почему-то не компилится" или ещё что-нить в таком духе — и у каждого свой синтаксис ) так что, постоянно std2me-me2std? ужас, правда? 
а если я его всё-же "выучу", что-нибудь забуду, не предусмотрю и допущу досадный трудноуловимый баг? как дебаггать тогда вообще? а если мой синтаксис будет куда более изощрён, нежели синтаксис товарища, сидящего слева, и его вариант не будет поддерживать "новой фичи, которую я только что от нечего делать придумал"? 
мне ради собственной эстетики придётся отвлечься на написание ещё какого-нибудь рула в лексере/грамматике — и так, пожалуй, будет вечно ) короче говоря, неоправданная трата времени в любом случае получается
