Custom-изация синтаксиса ЯП
От: wat3rs  
Дата: 06.12.09 23:10
Оценка: 1 (1) +1
У всех людей вкусы разные. Одни любят 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)? Какие ещё проблемы могут возникнуть?
Re: Кастомизация лексики языка
От: Qbit86 Кипр
Дата: 06.12.09 23:17
Оценка:
Здравствуйте, wat3rs, Вы писали:

Бог с ним, с синтаксисом. Лексику хотя бы кастомизировать!
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Кастомизация лексики языка
От: wat3rs  
Дата: 06.12.09 23:28
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Бог с ним, с синтаксисом. Лексику хотя бы кастомизировать!


Да, это тоже очень классно. Нормальная юникодовая λ вместо lambda или хаскелевского бекслеша — это довольно удобно. Хотя IDE leksah умеет заменять уродцев на красавцев.
Re[3]: Кастомизация лексики языка
От: Qbit86 Кипр
Дата: 06.12.09 23:39
Оценка:
Здравствуйте, wat3rs, Вы писали:

W>Хотя IDE leksah умеет заменять уродцев на красавцев.


Leksah сам по себе тот ещё уродец :) Но это — сугубо имхо, причём никем не разделяемое.
Глаза у меня добрые, но рубашка — смирительная!
Re: Custom-изация синтаксиса ЯП
От: Mr.Cat  
Дата: 07.12.09 01:08
Оценка:
Здравствуйте, wat3rs, Вы писали:

Ммм, предвижу большой метасрач.

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, которая будет делать то же самое, но наоборот. Нужна ещё будет утилита , которая будет преобразовывать сообщения об ошибках так, чтобы , например, заменялся номер строки и столбца.
Внимание, вопрос. Нахрена?. В мире столько разнообразных парадигм программирования — с которыми можно эксперементировать. А от того, что в отдельно взятом языке мы заменим одни токены на другие — он не станет ни лучше, ни хуже — а мы лишь впустую потратим время.
Re: Custom-изация синтаксиса ЯП
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 07.12.09 03:23
Оценка:
Здравствуйте, 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 там нет.
Re: Custom-изация синтаксиса ЯП
От: Mazay Россия  
Дата: 07.12.09 04:09
Оценка: 1 (1)
Здравствуйте, 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, но и в книжках, в документации.
Главное гармония ...
Re: Custom-изация синтаксиса ЯП
От: Andir Россия
Дата: 07.12.09 06:07
Оценка:
Здравствуйте, wat3rs, Вы писали:

W>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?


Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor

C Уважением, Andir!
Re: Custom-изация синтаксиса ЯП
От: Цыба Украина  
Дата: 07.12.09 06:30
Оценка: 3 (2)
Здравствуйте, 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, причём вплоть до таскания оной на флешке в самих экзотических ситуациях (а такие, конечно же, бывают)
Re: Custom-изация синтаксиса ЯП
От: Banch  
Дата: 07.12.09 07:14
Оценка:
1. Думаю это вполне реально.
2. Но на первых порах замучаешься писать интеграцию с IDE, SVN...
3. Зато потом это может дать рельно новый взгляд на код и понимание проблем в целом
Re: Custom-изация синтаксиса ЯП
От: wat3rs  
Дата: 07.12.09 10:28
Оценка:
Спасибо за ссылки, они довольно любопытные. Структурированный редактор — это отличная идея.

Понял, что протупил с примером, т.к. null и nil — это не обязательно синтаксис, более хороший пример будет таким: Джон хочет, чтобы в C++ или Java везде, где это возможно, перевод строки заменял точку с запятой, а отступ — фигурные скобоки. Тогда hello world Джон напишет примерно так:
#include <iostream>
using namespace std
void main ()
    cout << "Hello, world!"
    cout << endl


В идеале кастомный синтаксис должен быть чем-то типа скина. Чтоб его можно было настроить так же , как и цветовую схему в редакторе. Однако, если ведётся командная разработка, где часто надо смотреть в чужой код (и объяснять, почему он не компилится), то такая кастомизация будет вызывать проблемы (да и чужая схема подсветки может сильно раздражать).

Безусловно (пока это не стало мейнстримом ) если программист пользуется своим синтаксисом, то ему все равно надо знать стандартный, хотя бы на уровне чтения. Иначе таки придётся с собой на флешке носить std2john и john2std. Так же, как если вы дома настроили под себя какой-либо инструмент (например поменяли кей-биндинги), то чтобы работать с ним в другом месте — нужно или помнить стандартные, или носить свои конфиги.

Интеграция с VCS таки действительно может стать проблемой, но думаю, это решаемо.
Re: Custom-изация синтаксиса ЯП
От: FR  
Дата: 07.12.09 11:12
Оценка: +1
Здравствуйте, wat3rs, Вы писали:

W>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?


У Максима http://rsdn.ru/Users/66608.aspx среда http://symade.tigris.org/ все это вроде позволяет. Но он еще дальше пошел, у него в базе AST так что с ошибками и трансформированием все должно быть хорошо.
Re[2]: Custom-изация синтаксиса ЯП
От: samius Япония http://sams-tricks.blogspot.com
Дата: 07.12.09 11:13
Оценка: 1 (1) +2
Здравствуйте, wat3rs, Вы писали:

W>В идеале кастомный синтаксис должен быть чем-то типа скина. Чтоб его можно было настроить так же , как и цветовую схему в редакторе. Однако, если ведётся командная разработка, где часто надо смотреть в чужой код (и объяснять, почему он не компилится), то такая кастомизация будет вызывать проблемы (да и чужая схема подсветки может сильно раздражать).


W>Безусловно (пока это не стало мейнстримом ) если программист пользуется своим синтаксисом, то ему все равно надо знать стандартный, хотя бы на уровне чтения. Иначе таки придётся с собой на флешке носить std2john и john2std. Так же, как если вы дома настроили под себя какой-либо инструмент (например поменяли кей-биндинги), то чтобы работать с ним в другом месте — нужно или помнить стандартные, или носить свои конфиги.


W>Интеграция с VCS таки действительно может стать проблемой, но думаю, это решаемо.


Мне кажется, что проблема здесь — именно разрешение кастомизации синтаксиса. Почему это проблема, а не решение — да просто потому что она добавится к списку уже существующих проблем, которые требуется решать в командных разработках:
* чужая схема подсветки — (меньшая из проблем, но уже помянутая)
* различные взгляды на форматирование кода (не самая большая проблема)
* различные предпочтения при композиции кода и выборе абстракций (уже очень большая проблема, т.к. там где одному нужна гибкость для тестирования, второй предпочтет улучшение читаемости с затруднением тестирования)
* различные парадигменные подходы (если я начну писать на чистом ФП в чисто императивной команде, это будет фактически приравниваться к саботажу)

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

Как же решаются вышеперечисленные проблемы (кроме подсветки синтаксиса) в команде? Соглашением! Если что-то кому-то не нравится, то он идет в баню, потому как есть соглашения (форматирования кода, метрики связности, покрытие тестами, и прочая кухня), направленные на унификацию хотя бы в пределах команды.

Если бы мне попался язык с возможностью кастомизации синтаксиса, я бы первым делом составил командное соглашение об использовании единого синтаксиса.
Re: Custom-изация синтаксиса ЯП
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 07.12.09 12:56
Оценка:
Здравствуйте, wat3rs, Вы писали:

W>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.


Синтаксис во многом завязан на правила именования. Одни любят писать ObjectInctance.KillMyself(), другие obj_instance->kill_myself(), третьи objectInstance.suicide();
Re[2]: Custom-изация синтаксиса ЯП
От: Курилка Россия http://kirya.narod.ru/
Дата: 07.12.09 13:09
Оценка: :)
Здравствуйте, Mystic, Вы писали:

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


W>>У всех людей вкусы разные. Одни любят do-end, другие — фигурные скобочки. Одни любят писать object.method() , а другие — object method. А также Nil vs null и т.д.


M>Синтаксис во многом завязан на правила именования. Одни любят писать ObjectInctance.KillMyself(), другие obj_instance->kill_myself(), третьи objectInstance.suicide();


А четвёртые (и, может, пятые) знают правила языка, на котором имена записывают, и не используют myself в данном случае
Re: Custom-изация синтаксиса ЯП
От: yumi  
Дата: 07.12.09 13:38
Оценка: 1 (1)
Здравствуйте, 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
Re[2]: Custom-изация синтаксиса ЯП
От: Silver_s Ниоткуда  
Дата: 07.12.09 17:30
Оценка:
Здравствуйте, Andir, Вы писали:

W>>Кто что слышал о подобном, расскажите плиз. И если взяться за создание таких утилит, можно ли тогда будет гарантировать адекватность сообщений об ошибках (компиляции и run-time)? Какие ещё проблемы могут возникнуть?


A>Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor


Еще бы надо заменять public, static (слишком их много в C#) на какие то иероглифы,значки.
Re[3]: Custom-изация синтаксиса ЯП
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 08.12.09 11:11
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А четвёртые (и, может, пятые) знают правила языка, на котором имена записывают, и не используют myself в данном случае


Тогда уже suicide, просто я придумывал идентификатор из двух слов.
Re[2]: Custom-изация синтаксиса ЯП
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.12.09 12:32
Оценка: +2
Здравствуйте, Andir, Вы писали:

A>Недавно в дотнет-форуме был прототип редактора для C#-like языка: Structured Editor


Я видел вживую в 2007, емнип, году (Кирилл поправит) — идея очень интересная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re[3]: Custom-изация синтаксиса ЯП
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.12.09 12:32
Оценка:
Здравствуйте, Silver_s, Вы писали:

S_> Еще бы надо заменять public, static (слишком их много в C#) на какие то иероглифы,значки.


Не надо. Весь цимус в том, что текст никуда не девается и не меняется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.