У всех людей вкусы разные. Одни любят 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)? Какие ещё проблемы могут возникнуть?
Здравствуйте, 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>У всех людей вкусы разные. Одни любят 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>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor
Здравствуйте, 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, причём вплоть до таскания оной на флешке в самих экзотических ситуациях (а такие, конечно же, бывают)
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>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
Здравствуйте, wat3rs, Вы писали:
W>В идеале кастомный синтаксис должен быть чем-то типа скина. Чтоб его можно было настроить так же , как и цветовую схему в редакторе. Однако, если ведётся командная разработка, где часто надо смотреть в чужой код (и объяснять, почему он не компилится), то такая кастомизация будет вызывать проблемы (да и чужая схема подсветки может сильно раздражать).
W>Безусловно (пока это не стало мейнстримом ) если программист пользуется своим синтаксисом, то ему все равно надо знать стандартный, хотя бы на уровне чтения. Иначе таки придётся с собой на флешке носить std2john и john2std. Так же, как если вы дома настроили под себя какой-либо инструмент (например поменяли кей-биндинги), то чтобы работать с ним в другом месте — нужно или помнить стандартные, или носить свои конфиги.
W>Интеграция с VCS таки действительно может стать проблемой, но думаю, это решаемо.
Мне кажется, что проблема здесь — именно разрешение кастомизации синтаксиса. Почему это проблема, а не решение — да просто потому что она добавится к списку уже существующих проблем, которые требуется решать в командных разработках:
* чужая схема подсветки — (меньшая из проблем, но уже помянутая)
* различные взгляды на форматирование кода (не самая большая проблема)
* различные предпочтения при композиции кода и выборе абстракций (уже очень большая проблема, т.к. там где одному нужна гибкость для тестирования, второй предпочтет улучшение читаемости с затруднением тестирования)
* различные парадигменные подходы (если я начну писать на чистом ФП в чисто императивной команде, это будет фактически приравниваться к саботажу)
Добавляем сюда кастомизацию синтаксиса и вместо команды получаем набор индивидуалов, пишуших почти на разных языках и не способных объясняться друг с другом.
Как же решаются вышеперечисленные проблемы (кроме подсветки синтаксиса) в команде? Соглашением! Если что-то кому-то не нравится, то он идет в баню, потому как есть соглашения (форматирования кода, метрики связности, покрытие тестами, и прочая кухня), направленные на унификацию хотя бы в пределах команды.
Если бы мне попался язык с возможностью кастомизации синтаксиса, я бы первым делом составил командное соглашение об использовании единого синтаксиса.
Здравствуйте, wat3rs, Вы писали:
W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
Синтаксис во многом завязан на правила именования. Одни любят писать ObjectInctance.KillMyself(), другие obj_instance->kill_myself(), третьи objectInstance.suicide();
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, wat3rs, Вы писали:
W>>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.
M>Синтаксис во многом завязан на правила именования. Одни любят писать ObjectInctance.KillMyself(), другие obj_instance->kill_myself(), третьи objectInstance.suicide();
А четвёртые (и, может, пятые) знают правила языка, на котором имена записывают, и не используют myself в данном случае
Здравствуйте, 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
Здравствуйте, Andir, Вы писали:
W>>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?
A>Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor
Еще бы надо заменять public, static (слишком их много в C#) на какие то иероглифы,значки.
Здравствуйте, Курилка, Вы писали:
К>А четвёртые (и, может, пятые) знают правила языка, на котором имена записывают, и не используют myself в данном случае
Тогда уже suicide, просто я придумывал идентификатор из двух слов.