Re[4]: Custom-изация синтаксиса ЯП
От: Silver_s Ниоткуда  
Дата: 08.12.09 13:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>Не надо. Весь цимус в том, что текст никуда не девается и не меняется.


Текст можно и не трогать в файлах, а на экране чтобы после написания public сворачиволось в какую-то иконку.
Или хотя бы в обычной студии другим цветом показыать public,private чтобы с основным текстом не сливалось.

А для выделения структуры действительно что-то нужно. Кнопок сворачивания недостаточо. Но так чтобы быстро строчить не мешало.
Я для #region как-то поменял цвет фона(сделал слегка темнее белого), и даже удивился насколько такая мелочь улучшает читабельность, когда много #region.
Re[5]: Custom-изация синтаксиса ЯП
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 08.12.09 14:03
Оценка:
Здравствуйте, Silver_s, Вы писали:

S_>Текст можно и не трогать в файлах, а на экране чтобы после написания public сворачиволось в какую-то иконку.


А что это даст?

S_> Или хотя бы в обычной студии другим цветом показыать public,private чтобы с основным текстом не сливалось.


Ну, это и без структурированного редактора можно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
AVK Blog
Re: Custom-изация синтаксиса ЯП
От: mefrill Россия  
Дата: 09.12.09 13:29
Оценка: 7 (3) +1
Здравствуйте, wat3rs, Вы писали:

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


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


Я этой темой занимался. Даже, в свое время диссертацию написал "особенности синтаксического анализа открытых контекстно-свободных языков" . Языки с расширяемым синтаксисом называют открытыми. В том смысле, что пользователь может динамически изменять грамматику языка. Если изменяется только синтаксис, язык называется синтаксически открытым, а если еще и лексика -- лексически открытым.

Основными особенностями синтаксиса открытых языков являются:
1. Грамматика с любыми возможными правилами. Поэтому, нужен алгоритм анализа, который обрабатывает любую грамматику без ограничений типа LALR(k) или LL(k), т.е. бизоны и антиэлэры не подойдут.
2. Грамматика большая, пользователи могут много чего навводить. Значит, нужен алгоритм анализа, который не тормозит на больших грамматиках.
3. Синтаксические неоднозначности, поэтому нужен алгоритм, который с этими неоднозначностями хорошо работает.

Когда такой алгоритм создан, надо предоставить пользователю хороший способ расширять синтаксис. Т.е. надо придумать "начальную" грамматику, в которую входили бы правила для расширения языка, -- ядро открытого языка. На основе ядра можно расширять язык.

Надо придумать, как задавать семантику синтаксических конструкций. Это тоже непросто, нужна формальная модель вычисления по дереву представления (если это КС-грамматика) текста. Это тоже надо придумать. Для языков программирования можно не заморачиваться и выражать семантику на том языке программирования, который будет расширяться.

Лексику можно расширять с помощью синтаксиса регулярных выражений. Каждый лексический тип описывается своим регулярным выражением, которое потом транслируется в конечный автомат. Лексический анализатор запускает такие автоматы параллельно и таким образом выделяет токены из текста.

Самое важно, что необходимо понять -- открытость языка подразумевает, что есть сообщество, которое этот язык понимает, потому как каждый язык представляет собой результат договоренности. Ты этого коснулся немного, но по другому поводу.

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

Вообще, здесь много чего можно рассказать, проблема большая.
Re[2]: Custom-изация синтаксиса ЯП
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 09.12.09 15:11
Оценка: +1
Здравствуйте, mefrill, Вы писали:

M>Я этой темой занимался. Даже, в свое время диссертацию написал "особенности синтаксического анализа открытых контекстно-свободных языков" .


А нет ли ее в электронном виде, можно ли почитать?
Re[2]: Custom-изация синтаксиса ЯП
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.09 21:15
Оценка:
Здравствуйте, 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, тем самым, практически, убрав ограничения на расширение синтаксиса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Custom-изация синтаксиса ЯП
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.12.09 21:21
Оценка:
Здравствуйте, wat3rs, Вы писали:

W>Было бы классно иметь возможность настроить синтаксис языка программирования под себя.


Это бессмысленно, так как возможности языка определяются исключительно его семантикой и рантаймом.

Сделать конвертер синтаксиса не так сложно. Но нужно иметь общую семантическую базу. Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.

Но что это даст? Возможность посадить за один проект программистов знающих разные языки? Насколько это актуально?

Лично мне интересно иметь возможность расширять язык таким образом, чтобы можно было уменьшать сложность решения различных прикладных задач. Для этого язык должен позволять создавать DSL-и (внешние и/или внутренние, т.е. встроенные в язык). А как только язык расширяется, то он выходит за рамки возможностей усредненного мэйнстрим-языка и конвертировать его код в разные Delphi .Net, VB .Net и C# будет просто невозможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Custom-изация синтаксиса ЯП
От: Mazay Россия  
Дата: 11.12.09 07:48
Оценка:
Здравствуйте, 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-* — декомпилятором.
Главное гармония ...
Re[3]: Custom-изация синтаксиса ЯП
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.12.09 08:08
Оценка:
Здравствуйте, Mazay, Вы писали:

M>+1. В качестве общей семантической базы можно вообще использовать машинный код. Тогда конвертор *-to-std будет называться компилятором, а std-to-* — декомпилятором.


А какой машинный код?
Java bytecode? x86 assembly?
Re[4]: Custom-изация синтаксиса ЯП
От: Mazay Россия  
Дата: 11.12.09 08:30
Оценка:
Здравствуйте, Курилка, Вы писали:

M>>+1. В качестве общей семантической базы можно вообще использовать машинный код. Тогда конвертор *-to-std будет называться компилятором, а std-to-* — декомпилятором.


К>А какой машинный код?

К>Java bytecode? x86 assembly?

Для общности — x86+x64 assembly. Java bytecode все равно JIT Compiler'ом в машинный переводится потом. Вот с интерпертируемыми языками уже хуже.
Главное гармония ...
Re[2]: Custom-изация синтаксиса ЯП
От: Трурль  
Дата: 11.12.09 09:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Но что это даст?


Возможно, это позволит избежать флейма на тему "что лучше: {} или begin end".
Re[3]: Custom-изация синтаксиса ЯП
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.12.09 09:59
Оценка: +2
Здравствуйте, Трурль, Вы писали:

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


VD>>Но что это даст?


Т>Возможно, это позволит избежать флейма на тему "что лучше: {} или begin end".


Наоборот спровоцирует ежедневное его проявление
Re[3]: Custom-изация синтаксиса ЯП
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.12.09 12:07
Оценка: 1 (1) +1 :)))
Здравствуйте, Трурль, Вы писали:

VD>>Но что это даст?


Т>Возможно, это позволит избежать флейма на тему "что лучше: {} или begin end".


Мне кажется, что это плохо, так как людям с таким уровнем будет нечем себя занять.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Custom-изация синтаксиса ЯП
От: Mr.Cat  
Дата: 11.12.09 12:36
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.
Угу, и код с yield превращает в фарш. Еще интересно было бы посмотреть, во что превращаются в переложении на сишарп отсутствующие в нем фичи vb.net-а (напрмиер, параметры по умолчанию — хотя в шарп их добавили, late bunding — и т.п.).
Re[3]: Custom-изация синтаксиса ЯП
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.12.09 14:35
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

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

VD>>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.
MC>Угу, и код с yield превращает в фарш. Еще интересно было бы посмотреть, во что превращаются в переложении на сишарп отсутствующие в нем фичи vb.net-а (напрмиер, параметры по умолчанию — хотя в шарп их добавили, late bunding — и т.п.).

Ты внимательно прочитал то, что я написал? Заметил слова "некоторого подмножества".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Custom-изация синтаксиса ЯП
От: Mr.Cat  
Дата: 12.12.09 21:40
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>>>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.
VD>Ты внимательно прочитал то, что я написал? Заметил слова "некоторого подмножества".
Хм. Ну значит я тебя (а конкретно — твое двоеточие) не так понял.
Re[3]: Custom-изация синтаксиса ЯП
От: mefrill Россия  
Дата: 13.12.09 17:09
Оценка: 32 (2)
Здравствуйте, D. Mon, Вы писали:
DM>А нет ли ее в электронном виде, можно ли почитать?

Сюда положил автореферат. Наверное, это лучше, чем диссертация, там много математики. Код программы лежит здесь, если будет интересно посмотреть.
Re[5]: Custom-изация синтаксиса ЯП
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 13:45
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

VD>>>>Скажем сделать конвертер для некоторого подмножества: Delphi .Net, VB .Net и C# не проблема. Тот же Рефлектор без проблем декомпилирует код в эти языки.

VD>>Ты внимательно прочитал то, что я написал? Заметил слова "некоторого подмножества".
MC>Хм. Ну значит я тебя (а конкретно — твое двоеточие) не так понял.

Сори. Действительно звучит двояко. Но я имел в виду именно подмножества этих языков. Они процентов на 99 пересекаются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.