Re: Универсальный синтаксис для языков программирования - Философия программирования

Здравствуйте, Chrome, Вы писали:
C>Так что давайте по теме.

Я считаю, что Вы пытаетесь решить не ту проблему. Поверьте, при изучении языка изучение собственно синтаксиса занимает ничтожно малое количество времени по сравнением с изучением семантики языка и основных приемов программирования. Например, в одном языке оператор неподвижной точки можно записать вот так:

Y f = f (Y f)

А в другом — нельзя, и главным для программиста будет именно этот факт, а не то, как именно эта конструкция выглядит.

--Так...
Y f = f (Y f)

;так...
(define (Y f) (f (Y f)))

<!-- ...или так -->
<function name="Y">
  <param bind="f"/>
  <returns>
    <call function="f">
      <param><call function="Y"><param>f</param></call></param>
    </call>
  </returns>
</funtion>

Если Вы зададите некоторое абстрактный, оторванный от семантики метаязык, и в его рамках будете разрабатывать языки, специфичные для конкретной семантики — с точки зрения удобства для программиста Вы ничего не добьетесь. Скорее даже проиграете, т.к. рамки метаязыка наверняка не позволят разработать удобный синтаксис и будут все сильнее мешать со временем, когда начнут проявляться недочеты дизайна самого метаязыка.

Я не согласен с логикой Ваших рассуждений. Вот цитата из Вашего исходгного сообщения:

Потребность в синтаксисе не связанном с семантикой зачастую возникает в рамках программирования на любом языке.
Когда в программу на C# или C++ нужно вставить какое нибудь дерево, типа XML, HTML, SQL и т д

Из того, что программисту иногда одновременно требуется оперировать конструкциями с различными синтаксисом и семантикой еще не следует, что для этого необходим общий синтаксис языков программирования. В большинстве случаев очень неплохо смотрятся решения, не выходящие (или почти не выходящие) за рамки основного используемого языка — т.е. создание библиотек, макросов или некоторое расширение самого языка. Для примера возьмем регулярные выражения. Вполне себе отдельный язык, который вполне успешно применяется внутри программ на других языках, причем безо всякого там общего синтаксиса: программист задает регулярное выражение либо как строку (и использует библиотеки, навроде pcre), либо как сущность самого языка (как это сделано в boost::xpressive). Если же речь идет о приближающемся к равному проценте кода на обоих языках — стоит подумать о специализированных средствах. Для примера можно взять html-шаблонизаторы. Они склеивают логически связанный код на двух языках, при этом не требуя модификации самих языков и смешивания кода в одном файле. Такой подход вполне удобен.

Здравствуйте, Mr.Cat, Вы писали:

C>>XMLем:
MC>Зачем же Вы так на ночь глядя? Теперь сниться же будет.
Испугался! А если я сейчас ещё напишу библиотеку, которая будет переводить регэксы в такую форму?

Здравствуйте, Cyberax, Вы писали:
C>Испугался! А если я сейчас ещё напишу библиотеку, которая будет переводить регэксы в такую форму?

Мряк. Зато, млин, универсальный синтаксис. Осталось разработать xml-схемы для sql и C++.

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

ГВ>>Присоединюсь к предыдущим ораторам: можно пальцем в какой-нибудь универсальный синтаксис?

C>Я дам критерий, описывающий множество универсальных синтаксисов.
C>Для этого следуют задуматься, какова роль синтаксиса в языке программирования?
C>Ответ примерно такой — на основании правил синтаксися компилятор стороит из текста программы дерево AST.

AST строится на основании грамматических правил с учётом семантических ограничений. Это вспомогательная конcтрукция, а не целевая. Понимаешь? Задача компилятора — вовсе не AST сгенерировать, а выдать исполняемый код. AST — только промежуточная форма представления, подчиняющаяся тем правилам, которые отражены в синтаксисе исходного языка. Синтаксические правила, в свою очередь, тесно связаны с семантикой конструкций языка. Разные языки — разные AST.

C>После того, как дерево построено, про исходный синтаксис можно забыть. Он больше не оказывает влияние на дальнейший процесс компиляции и исполнение программы.

Угу. Но это дерево не может быть абы каким. Оно (его структура) тоже подчиняется жёстким правилам, заданным языком.

C>(Исключением могут быть языки, которым на этапе исполнения доступен собственный текст в исходном "текстовом" виде.
C>но это экзотика в современных технологиях.)
C>Таким образом, любой синтаксис, с помошью правил которого можно собрать эквивалентное дерево AST, можно назвать эквивалентным исходному синтаксису языка,
C>а такой синтаксис, который позволяет построить какое угодно дерево — можно назвать универсальным.

Остаётся задать вполне логичный вопрос: а кто, и главное, как будет компилировать это самое "какое угодно" AST? Вот тебе AST, сформулированное на Lisp:

(node-a (construct1 a b) (construct2 c d))

Дальше что вы намерены делать?

C>Примеры — синтаксис лиспа, синтаксис XML, да мало ли нотаций можно приспособить, что бы описывать дерево?

Верно, само дерево описать не сложно. Вопрос в том, повторюсь, какое именно это должно быть дерево. То есть ключевой момент — семантика узлов AST.

C>Но для человека они удобны не очень. Моя цель — попытаться построить удобный для человека, краткий, практичный универсальный синтаксис, не уступающий по краткости конкретным синтаксисам современных языков.

Вот и задумайся: что же ты собираешься описывать?

C>PS. Кстати, эквивалентный синтаксис в XML поддерживается некоторыми авторами языков, для С# такой точно существует, еще про что то слышал.

Можно задать такой набора правил, что структура узлов даного XML-дерева будет сильно похожа на AST C#. Даже эквивалентна. Но человеку оперировать такими конструкциями дико неудобно. Сокращаем до уровня удобства — получаем обратно C# или язык, эквивалентный C# с точностью до вида лексем. Ну, сможем заменить class на, скажем, XSetDescription какой-нибудь.

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

C>изучил концепции другого языка
На это и уходит большая часть времени

C>вместо того что бы ставить отдельную IDE
Никогда не сталкивался с такой проблемой. Для мелких программ я, например, IDE не пользую, а если проект большой — установка IDE/поиск плагинов занимают сравнительно немного времени.

C>Отсутсвует синтаксический шок при изучении другого языка.
Опять же, на мой взгляд у впечатлительного программиста скорее случится семантический шок.

C>Или все же сомнения в возможности реализации?
Нет, сомнений нет. Просто, на мой взгляд, Вы несколько преувеличиваете реальную пользу от такого проекта.

Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.
Возможно ли создать универсальный синтаксис, эффективный для человека и пригодный для описания произвольной семантики современных языков программирования.

Под описанием семантики я подразумеваю формирование(при помощи универсального синтаксиса)дерева — эквивалентного дереву разбора, которое формирует парсер обычного языка.
Эффективный для человека – означает, что эквивалентное описание должно быть не намного длиннее оригинального.

Сегодня синтаксис и семантика языка связаны – каждый язык имеет свою грамматику для описания набора концептов, которыми язык оперирует – классов, функций, переменных и т д
Несколько языков имеют примерно общую семантику, но различный синтаксис, как в примере Visual basic .Net and C#
Более того, существуют предложения создавать грамматику на каждый новый набор понятий (DSL)

Напрашивается аналогия с XML
До него каждый изобратал свой формат для каждого вида текстовых данных, после – резко перестали.
Для примера пара XML и HTML – у последнего есть несколько вкусностей – иногда можно опустить кавычки вокруг значений атрибутов, атрибуты могут вообще не иметь значений, открывающие и закрывающие таги могут пересекаться. Некоторые элементы не требуют закрывающих тагов. Но от этого постепенно отказываются в пользу универсальности(XHTML) – никому не хочется изучать эти часности.
И речь не идет о машинном разборе – HTML часто пишет и читает человек.
Тем не меннее, XHTML выглядит предпочтительно.

Начасть можно с рассмотрения лексических примитивов:
Оформление комментариев
Допустимые символы в идентификаторах
Синтаксис строк – вид кавычек, специальные символы, перенос на новую строку
Формат чисел
Чувствительность к регистру.
Все эти детали изменяются от языка к языку, на усмотрение его авторов, не принося ничего, кроме головной боли для пользователей.

Потребность в синтаксисе не связанном с семантикой зачастую возникает в рамках программирования на любом языке.
Когда в программу на C# или C++ нужно вставить какое нибудь дерево, типа XML, HTML, SQL и т д — тут начинается нецелевое использование конструкций языка, таких как: темплейты, выражения, дерево классов. Функциональные языки приспосабливают свои функции.

Решение, не очень хорошее, в природе существует – синтаксис типа лиспа, или гораздо хуже XML – можно выразить что хочешь, но слишком многословно, и недостаточно статически типизировано.

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

Добавлю и я свои пять копеек.

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

C>Но почему кажется сомнительным профит от затеи? Для меня это неожиданно.
C>Универсальный синтаксис — значит универсальная качесвенная среда разработки,

Связь не очевидна. Функции IDE сильно зависят от семантики языка (рефакторинг и множество других вещей)
Поэтому про универсальность, основанной только на синтаксисе говорить не приходится.
Хотя в IDE можно использовать плагины, которые решили бы эту проблему.
Как следствие, здесь качественная IDE = качественные плагины.

C>устранение границ между вселенными разных языков — подключил модуль, изучил концепции другого языка и можешь начинать писать, вместо того что бы ставить отдельную IDE

Предлагается использовать одновременно несколько концепций (языков) в проекте?
Тогда здесь встает проблема взаимодействия этих языков. Допустим на "вход" языка работы с матрицами должны подаваться массивы определенного вида, что совсем не очевидно для "выхода" языка "как С++". Т.е. все равно необходима некая, пусть и минимальная, семантика.

C>Отсутсвует синтаксический шок при изучении другого языка.

Это да. Но появляется семантический шок

Хотя и не больший, чем при изучении библиотек конкретного языка. Скорее даже меньший, т.к. синтаксис гибче.

C>Создание своего языка упрощается — вы не пишете лексический анализатор, гораздо проще создать грамматику, и то не целиком, а только уникальную часть
C>ну и т д.

И здесь тоже согласен.
Более того, считаю что это самый важный плюс такого универсального синтаксиса. Уверен, что без разработки и использования различных DSL программирование далеко не уедет.

C>Или все же сомнения в возможности реализации?

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

Вон тот же XML и Lisp (что в плане синтаксиса почти одно и то же) — реализованы (шепотом: нечеловечны).
Или другая крайность. Всю программу рассматривать просто как последовательность слов (привет FORTH), и пусть "язык" сам разберется, что к чему. Но тогда пользы от такого синтаксиса ноль. Такое, например, можно сделать на LISP — сделать программу из одного большого списка операторов практически с любым синтаксисом, а затем анализировать его и исполнять.

Кстати сейчас появляются инструменты, позволяющие писать код прямо в AST. Как следствие, можно описать любой язык не задумываясь об его текстовом представлении. Если не ошибаюсь, такие средства (думаю в зачаточном состоянии) есть в Visual Studio и Intellij IDEA. Microsoft занимался (занимается?) Intentional Programming, mkizub — SymADE

Теперь о более конструктивных вещах. Если описывать синтаксис, незначительно касаясь семантики, то вот некоторые вещи которые можно было бы использовать:
— отступы (как в Python)
— инфиксные операторы с приоритетами и пр. настройками (Haskell, Prolog)
— игры с именами идентификаторов (начальные буквы или символы #, _, $ и пр.) (Erlang, Prolog, Haskell, Smalltalk, PHP)
— списки (Lisp) — группа чего-то
— порядок слов (в Smalltalk первым в предложении стоит объект, в Haskell, Lisp — функция, затем аргументы)
— описание (ключ:значение) (опять Smalltalk — сообщения с несколькими параметрами)
— предопределенные операторы, знаки пунктуации (например, точка как взятие части от целого или как окончание предложения, [] как описание группы, точка с запятой как ... ну не знаю я

)
— ну и самое сложное и интересное — разнесение слов универсального языка к "частям речи" (привет J) и задание правил построения предложений. Ну чтобы AST формировался как разбор предложения естественного языка: HashMap — что? класс (существительное), какой? public (прилагательное), какой? static (тоже прилагательное). Так же с глаголами и наречиями.

Могу по-подробнее расписать, если непонятно выразился.
Вот как-то так...

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

C>Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.

Имхо, вряд ли.

C>Возможно ли создать универсальный синтаксис, эффективный для человека и пригодный для описания произвольной семантики современных языков программирования.

Какая-то неактуальная задача. Гораздо актуальней разработать тулзину с одной кнопкой "Сделать как надо"

C>Решение, не очень хорошее, в природе существует – синтаксис типа лиспа

Ну, например, люди взяли что-то от Лиспа и сделали достаточно расширяемую штуку со статической типизацией. Фрагмент отсюда:

{define-proc {save visual:Graphic, 
                 save-to-file?:bool = false,
                 filename:String = "image.png"}:void 
    
    || calculate offset
    let x:Distance = 0pt
    let y:Distance = 0pt
    {if visual.parent != null then
        set (x,y)={transform-coordinates 0pt,0pt, visual.parent,visual}
    }
    
    {dump x,y}
    
    || get display context
    let gc = {visual.get-display-context}
    {if visual.layout == null then
        {throw {Exception "InvalidLayout"}}        
    }
    
    
    || get bounds
    let bounds:GRect = {visual.layout.get-bounds}
    {output bounds.width, bounds.height}
    
    || create the offscreen stuff
    let (r2:Renderer2d, d:Drawable) =
        {Renderer2d.create-offscreen 
            (bounds.width + 2 * visual.margin + 2* visual.border-width), 
            (bounds.height+ 2 * visual.margin + 2* visual.border-width) ,  
            ||the resolution makes a difference in the jpg-file
            {max 300dpi, (1/(gc.pixel-size))}
        }
...

Только в народ эта штука не пошла.

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

C>К сожалению, в области программирования вашу аналогию следует дополнить таким пассажем:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

C>Думаю, что от монолитного понятия "ЯЗЫК ПРОГРАММИРОВАНИЯ" можно аналогичным образом отделить еще несколько составных частей.

Ты уж определись, что ты хочешь — отделить синтаксис или сделать один общий синтаксис для кучи языков.

C>Что пойдет языкам на пользу. Не будет каждый автор языка тратить 90 процентов времени на изобретение велосипеда.

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

C>У меня есть мысль, что и синтаксис — не вполне часть языка.

Мысль это конечно здорово, но без весомых аргументов ценность у нее невелика. А вот с аргументами как то у тебя не очень.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

C>Для описания HTML приделали костыль в виде темплейтов ASPX

Это не костыль, это называется DSL. Там не HTML внутри C#, а наоборот, C# внутри HTML.

C>Для SQL немного расширили синтаксис, теперь при помощи синтаксиса C# 3.0 можно удовлетворительно описывать подмножество языка SQL, причем синтаксис этого описания немного проигрывает оригинальному синтаксису SQL

Во-первых Query comprehension это не SQL, он даже по модели данных не SQL. С SQL его роднят только названия некоторых ключевых слов и функциональная природа. Во-вторых, если уж утверждаешь, что он проигрывает в синтаксисе, хотелось бы услышать какое то обоснование.

C>Согласитесь?

Нет.

C>Давайте представим, что разработчики языка еще немного напряглись и стало возможным
C>описывать структуру HTML совсем близко к тексту. ASPX пойдут в топку.

Неа, не пойдут. Хотя бы потому что пространства HTML и C# кода внутри ASPX не идентичны, и связаны довольно таки нетривиальными преобразованиями. И проблема не в синтаксисе, а в семантике.

C>Может случиться так, что улучшенный синтаксис позволит формировать
C>деревья программ не только для простейших языков типа SQL, но и для самого C#

Та же самая ошибка. Основная задача LINQ это не синтаксис, похожий на SQL, а интеграция запросов в систему типов языка. И даже query comprehension созданы не только и не столько для имитации синтаксиса SQL, сколько для устранения избыточного синтаксического мусора (дублирующихся объявлений параметров лямбд в основном) по сравнению с функциональной формой. И решить эту задачу универсальным способом, не затрагивая семантики, невозможно. И именно поэтому, коль уж хочется кучи собственных DSL в рамках языка универсального, не синтаксис униварсальный придумывают, а создают средства метапрограммирования (читай расширения семантики), как например в случае макросов Немерле.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

C>>Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.
.>Подумай, чем бы ты мог заменить язык регулярных выражений, скажем?
XMLем:

s/hello.*/world/g;

<regex>
<pattern>
<textString>hello</textString>
<zeroOrMore><wildcard type="any"/></zeroOrMore>
</pattern>
<replaceWith type="global">
<textString>world</textString>
<replaceWith>
</regex>

Здравствуйте, Cyberax, Вы писали:
C>XMLем:
Зачем же Вы так на ночь глядя? Теперь сниться же будет.

Здравствуйте, x-code, Вы писали:
XC>А вот почему в C#3.0 не ввели встроенный xml-непонятно

Боже мой, зачем оно надо?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Разные языки — разные AST.

Более того — для разных целей в рамках одного языка тоже нужны разные AST, и AST для дизайн-тайма в IDE и AST для компиляторат обычно сильно отличаются.
Но и это еще не все — нередко сам компилятор в процессе компиляции использует несколько разных AST на разных этапах компиляции.
Поэтому говорить об универсальной AST для разных языков

Вобщем, как обычно, все скатилось на универсальные парсеры и хранение исходников в AST.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

AVK>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Разные языки — разные AST.

AVK>Вобщем, как обычно, все скатилось на универсальные парсеры и хранение исходников в AST.

А резве не такая цель стояла?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

C>Здравствуйте, Курилка, Вы писали:

MC>>>Интересно, почему?

Что-то личное, как нелюбовь Торвальдса к C++ и любовь ван Россума к GIL?
К>>Выделенное это как?

C>Ну не любит Линус Торвальдс С++ и всячески сопротивляется его использованию в ядре.

Мда, работать меньше надо, прочитал вместо Торвальдса "Страуструп"

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

C>Хотелось бы понять, почему конкретный синтаксис настолько более компактен по сравнению с общим и какие успехи достигнуты в данном направлении мыслящим сообществом.

Потому что он конкретный, а не общий.

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

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

А самое главное — что непонятно зачем это нужно.

Зачем нужен XML — понятно. Он описывает данные. Универсальный формат записи структур данных — это хорошо. Потому что новые структуры данных возникают постоянно при решении текущих рабочих задач. Для каждой из них придумывать или изучать новый синтаксис — жутко неудобно. Излишние потери времени и соответственно денег. А как часто приходится по работе менять язык, на котором пишешь? В большинстве случаев хватает одного-двух ключей. И молотка.
Если же вдруг появилась какая-то потребность в новом, не использовавшемся ранее языке — то скорее всего изучение его синтаксиса будет ну самой наименьшей из всех возникших при этом проблем. Так зачем оно надо?

Обобщенное средство всегда неудобнее конкретного, созданного специально под данную задачу.

Здравствуйте, Chrome, Вы писали:
C>Возможно ли создать универсальный синтаксис, эффективный для человека и пригодный для описания произвольной семантики современных языков программирования.

А зачем?

Здравствуйте, Mr.Cat, Вы писали:

MC>А зачем?
Попробую провести аналогию.
Был такой язык в школе — Бейсик
в нем на уровне грамматики были втроены забавыные конструкции, вроде
Print, Draw, Circle
Еще был паскаль, а в нем ReadLn, WriteLn, кажется.
Думаю, много еще таких языков было, где в грамматику были встроены библиотечные функции.
Не было в то время ясного понимания, что есть язык и есть библиотека.
И не следует мешать одно с другим. А следует отделять мух от котлет.
Думаю, что от монолитного понятия "ЯЗЫК ПРОГРАММИРОВАНИЯ" можно аналогичным образом отделить еще несколько составных частей. Эти части традиционно содержатся в понятии "ЯЗЫК ПРОГРАММИРОВАНИЯ", но, как мне кажется, не имеют к нему прямого отношения.
Кандидаты на эти части, подлежащие отделению
— Back end копилятора
— Runtime engine
— лексический анализатор
— и, как мне кажется, синтаксис языка

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

Так что на вопрос "Зачем" я бы ответил — это попытка убрать из понятия "ЯЗЫК ПРОГРАММИРОВАНИЯ" все лишнее.
(Зы. Остаться там должно то, что между деревом разбора и Back end копилятора)

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

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

C>>Хотелось бы понять, почему конкретный синтаксис настолько более компактен по сравнению с общим и какие успехи достигнуты в данном направлении мыслящим сообществом.

F>Потому что он конкретный, а не общий.

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

К сожалению, в области программирования вашу аналогию следует дополнить таким пассажем:
к каждому из "обычных" ключей прилагается инструкция по применению — 500 страниц. И если вы ее не прочитали, вы с высокой вероятнотью будете закручивать гайки против резьбы.
Думаю, с таким уточнением вы не будете скептически настроены по отношению к изобретению разводного ключа.

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

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

F>А самое главное — что непонятно зачем это нужно.

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

В общем идею про универсальный синтаксис можно сформулировать как создание XML в области языков программирования.
— XML для человека а не для машины.

F>Зачем нужен XML — понятно. Он описывает данные. Универсальный формат записи структур данных — это хорошо. Потому что новые структуры данных возникают постоянно при решении текущих рабочих задач. Для каждой из них придумывать или изучать новый синтаксис — жутко неудобно. Излишние потери времени и соответственно денег. А как часто приходится по работе менять язык, на котором пишешь? В большинстве случаев хватает одного-двух ключей. И молотка.

Обычно не хватает, но выбора нет.

F>Если же вдруг появилась какая-то потребность в новом, не использовавшемся ранее языке — то скорее всего изучение его синтаксиса будет ну самой наименьшей из всех возникших при этом проблем. Так зачем оно надо?

F>Обобщенное средство всегда неудобнее конкретного, созданного специально под данную задачу.

это не так. Обратите внимание на корень слова "Обобщенное" — под него подпадает ситуация, кода люди решали задачу частным образом, а потом некто обобщил эти попытки и решил ее в общем случае. И не факт, что это решение хуже.
Вот если бы вы сказали СПЕЦИАЛИЗИРОВАННОЕ средство, я может с вами и согласился бы.
Но в данном случае я пытаюсь понять, возможно ли именно ОБОБЩИТЬ понятие синтаксиса и вынести его из понятия "язык программирования".

Одна утопия для иллюстрации концепции
Возьмем язык C#
Его синтаксис хорошо подходит для описания программ на языке C#
Но программистам этого недостаточно.
Им требовалось включать в тексты деревья программ на других языках
Наиболее частые примеры HTML и SQL
Для описания HTML приделали костыль в виде темплейтов ASPX
Для SQL немного расширили синтаксис, теперь при помощи синтаксиса C# 3.0 можно удовлетворительно описывать подмножество языка SQL, причем синтаксис этого описания немного проигрывает оригинальному синтаксису SQL
Согласитесь?
Пойдем немного дальше.
Попробуем применить расширенный синтаксис к старой проблеме HTML
Мы видим, что у нас появилась возможность описать структуру HTML страниц приемлемым образом
new HTML{ Head = {Title = "Page title"}, Body=new HtmlBody(..elements..)}
как то так. Уже довольно близко к оригиналу.
Давайте представим, что разработчики языка еще немного напряглись и стало возможным
описывать структуру HTML совсем близко к тексту. ASPX пойдут в топку.
Мы получим один синтаксис подходящий для трех языков.
При этом мы не обьединили грамматики трех языков.
Может случиться так, что улучшенный синтаксис позволит формировать
деревья программ не только для простейших языков типа SQL, но и для самого C#

и описание родной конструкции типа switch в его нотации будет не менее изящьно, чем встроенное.
тогда можно будет провести ревизию грамматики C# 10.0 и выкинуть из него излишние конструкции.
ну и получим что то вроде синтаксиса отделенного от семантики.

1960-е – Х. Барендрегт (H. Barendregt) описал семантику ламбда-исчисления
1969 – Д. Скотт (Dana S. Scott) предложил использовать домены (особый вид множеств) для формализации
денотационной семантики как функции вычисления значения синтаксически корректных конструкций языка
1979 – М. Гордон (Michael J.C. Gordon) исследовал денотационную семантику языков программирования
1964 – П. Лендин (Peter J. Landin) разработал семантику модели языка программирования в форме абстрактной
машины на состояниях
1969 – Ч. Хоар (Charles A.R. Hoare) создал аксиоматический метод, моделирующий операторы языка программирования
1960-е – Р. Флойд (Robert W. Floyd) создал метод индуктивных утверждений для формализации семантики
протекания информации в программе (графическая иллюстрация — блок-схемы)

В 1980 году у нас был переведен прекрасный сборник статей, который так и называется "Семантика языков программирования".

C>Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.

Нет.

C>Возможно ли создать универсальный синтаксис, эффективный для человека и пригодный для описания произвольной семантики современных языков программирования.

Нет.

C>Под описанием семантики я подразумеваю формирование(при помощи универсального синтаксиса)дерева — эквивалентного дереву разбора, которое формирует парсер обычного языка.

Это какая-то непонятная предложения.

Где в нем семантика (смысл конструкций) языка-то?

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

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

Это как пример теоретической невозможности чего-то сделать по краткому переводу.

C>Сегодня синтаксис и семантика языка связаны – каждый язык имеет свою грамматику для описания набора концептов, которыми язык оперирует – классов, функций, переменных и т д
C>Несколько языков имеют примерно общую семантику, но различный синтаксис, как в примере Visual basic .Net and C#
C>Более того, существуют предложения создавать грамматику на каждый новый набор понятий (DSL)

C>Напрашивается аналогия с XML
C>До него каждый изобратал свой формат для каждого вида текстовых данных, после – резко перестали.

http://www.sics.se/~joe/ml9/doc.html как опровержение. Конфигурационные файлы на Tcl/Lua/Python никто не перестал делать.

C>Начасть можно с рассмотрения лексических примитивов:

И вот это я тоже не очень понял. Зачем на лексику-то смотреть, если интересна связь синтаксис+семантика?

C>Потребность в синтаксисе не связанном с семантикой зачастую возникает в рамках программирования на любом языке.
C>Когда в программу на C# или C++ нужно вставить какое нибудь дерево, типа XML, HTML, SQL и т д — тут начинается нецелевое использование конструкций языка, таких как: темплейты, выражения, дерево классов. Функциональные языки приспосабливают свои функции.

Почему нецелевое-то? Очень даже целевое, все же, это языки общего назначения.

C>Хотелось бы понять, почему конкретный синтаксис настолько более компактен по сравнению с общим и какие успехи достигнуты в данном направлении мыслящим сообществом.

Я уже высказался — кое-что теоретически невозможно.

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

C>Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.
Подумай, чем бы ты мог заменить язык регулярных выражений, скажем?
Но хотя да, нередко перебарщивают с изобретением оригинальных синтаксисов для красоты.

Здравствуйте, Mr.Cat, Вы писали:

C>>Испугался! А если я сейчас ещё напишу библиотеку, которая будет переводить регэксы в такую форму?
MC>Мряк. Зато, млин, универсальный синтаксис. Осталось разработать xml-схемы для sql и C++.
Для C++ уже есть — частично в GCC-XML, частично в LLVM.

Здравствуйте, Cyberax, Вы писали:
C>Для C++ уже есть — частично в GCC-XML, частично в LLVM.

Почитав про gcc-xml, понял, что идея с универсальным синтаксисом не так уж нереальна. Только синтаксис этот — как gcc-xml — не для людей предназначен будет.

ГВ>Это слишком узко. Давай уж проще — напишем программу автоматизации всего. По логике вещей программа автоматизации всего не потребует языка, поскольку будет автоматизировать, в числе прочих, задачу выражения мыслей человека в машиночитаемом представлении.

В нашей школе, к сожалению, риторику не преподавали.
Я догадываюсь, что существуют различные фигуры речи вроде иронии, сарказма,
но не слишком силен в их интерпретации.
Про кнопку "Сделать чтоб все работало" мне в одном из первых ответов отписали )

Так что давайте по теме.

Универсальный синтаксис для языков программирования существует, и не один.
Но они весма многословны и неудобны для человека.
Я пытаюсь понять, может его можно подсократить, избавившись от избыточности и сделать приемлемым для человека.
Все же синтаксис языка программирования — это некий адаптер между человеком и концептами языка программирования
Концепты в языках разные, но человек в данной связке величина постоянная.
Синтаксис делается для удобства именно человека, так что есть надежда найти некий инвариант, независимый от конкретного языка.

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

C>Универсальный синтаксис для языков программирования существует, и не один.
Например?
C>Но они весма многословны и неудобны для человека.
C>Я пытаюсь понять, может его можно подсократить, избавившись от избыточности и сделать приемлемым для человека.
C>Все же синтаксис языка программирования — это некий адаптер между человеком и концептами языка программирования
C>Концепты в языках разные, но человек в данной связке величина постоянная.
C>Синтаксис делается для удобства именно человека, так что есть надежда найти некий инвариант, независимый от конкретного языка.
ИМХО, инвариантами являются как раз концепты, а синтаксис — это средство обозначения таких концептов. Стол — он везде стол, но обозначается синтаксически по-разному в разных языках.
Вот явным образом формализовать семантику концептов — это сложная задачка. Во всяком случае с ней пока не справились на том же уровне, что и формализация синтаксиса.

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

C>Универсальный синтаксис для языков программирования существует, и не один.
C>Но они весма многословны и неудобны для человека.

Присоединюсь к предыдущим ораторам: можно пальцем в какой-нибудь универсальный синтаксис?

Здравствуйте, Геннадий Васильев, Вы писали:

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

C>>Универсальный синтаксис для языков программирования существует, и не один.
C>>Но они весма многословны и неудобны для человека.

ГВ>Присоединюсь к предыдущим ораторам: можно пальцем в какой-нибудь универсальный синтаксис?

XML?

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

C>Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.
C>Возможно ли создать универсальный синтаксис, эффективный для человека и пригодный для описания произвольной семантики современных языков программирования.

"Сишный" синтаксис — самый распространенный в мире (С,C++,C#,Java...)
вполне адекватный для написания программ человеком — компактный, логичный, если не считать некоторых перекосов С++ — вполне простой для парсинга, в том числе и для "быстрого" парсинга в IDE, при построении разных Class View и т.д.
Некоторые вещи вполне можно вынести в "общую" часть — все что касается лесического анализа (комментарии, строки, числа...) Я в свое время написал такой лексический анализатор.
Ну и семантика — построение выражений, распределение функций скобок (круглые — приоритет и параметры объектов, квадратные — индексация и атрибуты, фигурные — коллекции и операторные скобки, угловые — xml), и т.д.
Имеет смысл встроить XML прямо в язык. Как он будет использоваться — дело конкретного языка, но парсер должен понимать xml-вставки в тексте программы (Comega, Scala — уже сделано).

ГВ>Присоединюсь к предыдущим ораторам: можно пальцем в какой-нибудь универсальный синтаксис?

Я дам критерий, описывающий множество универсальных синтаксисов.
Для этого следуют задуматься, какова роль синтаксиса в языке программирования?
Ответ примерно такой — на основании правил синтаксися компилятор стороит из текста программы дерево AST.
После того, как дерево построено, про исходный синтаксис можно забыть. Он больше не оказывает влияние на дальнейший процесс компиляции и исполнение программы.
(Исключением могут быть языки, которым на этапе исполнения доступен собственный текст в исходном "текстовом" виде.
но это экзотика в современных технологиях.)
Таким образом, любой синтаксис, с помошью правил которого можно собрать эквивалентное дерево AST, можно назвать эквивалентным исходному синтаксису языка,
а такой синтаксис, который позволяет построить какое угодно дерево — можно назвать универсальным.
Примеры — синтаксис лиспа, синтаксис XML, да мало ли нотаций можно приспособить, что бы описывать дерево?
Но для человека они удобны не очень. Моя цель — попытаться построить удобный для человека, краткий, практичный универсальный синтаксис, не уступающий по краткости конкретным синтаксисам современных языков.

PS. Кстати, эквивалентный синтаксис в XML поддерживается некоторыми авторами языков, для С# такой точно существует, еще про что то слышал.

Здравствуйте, Chrome, Вы писали:
C>Моя цель — попытаться построить удобный для человека, краткий, практичный универсальный синтаксис, не уступающий по краткости конкретным синтаксисам современных языков.

Так что Вы хотите получить в итоге? Метаязык, подмножеством которого будут другие языки? Как XML, только более пригодный для человекописания?

Здравствуйте, x-code, Вы писали:

XC>(Comega, Scala — уже сделано).

Слава богу что безобразие под названием сиомега не прошло, а вместо него сделали линк.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

XC>>(Comega, Scala — уже сделано).
AVK>Слава богу что безобразие под названием сиомега не прошло, а вместо него сделали линк.

Ну сиомега и не планировалась как рабочий продукт

это типа исследовательского языка. А вот почему в C#3.0 не ввели встроенный xml-непонятно

в бейсик вроде ввели... хотя мне-то как раз все равно, т.к. я программирую на С++

Здравствуйте, Mr.Cat, Вы писали:

XC>>А вот почему в C#3.0 не ввели встроенный xml-непонятно

MC>Боже мой, зачем оно надо?

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

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

XC>>>А вот почему в C#3.0 не ввели встроенный xml-непонятно

MC>>Боже мой, зачем оно надо?

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

Еще более абстрактное чем XML? Интересно, как это могло-бы выглядеть?

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

LVV>ИМХО, инвариантами являются как раз концепты, а синтаксис — это средство обозначения таких концептов. Стол — он везде стол, но обозначается синтаксически по-разному в разных языках.
А мне вот как раз кажется, что стол — везде разный.
Потому что мы говорим не о реальном столе, а о его модели. И кто-то рассматривает стол как композицию из ножек и поверхности, кто-то — как частный случай общего понятия "мебель", кто-то — как второго участника действия "положить на".

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, Mr.Cat, Вы писали:

C>>Для C++ уже есть — частично в GCC-XML, частично в LLVM.
MC>Почитав про gcc-xml, понял, что идея с универсальным синтаксисом не так уж нереальна. Только синтаксис этот — как gcc-xml — не для людей предназначен будет.
Да, именно. Любой синтаксис в итоге превращается в дерево. Дерево можно представить по желанию в виде XML, S-выражений LISPа, и т.п.

Только на практике обычно удобнее работать со специализированым представлением.

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

.>Подумай, чем бы ты мог заменить язык регулярных выражений, скажем?

Регэксы — это хороший пример. Совершенно пакостный write-only синтаксис

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>AST строится на основании грамматических правил с учётом семантических ограничений. Это вспомогательная конcтрукция, а не целевая. Понимаешь? Задача компилятора — вовсе не AST сгенерировать, а выдать исполняемый код. AST — только промежуточная форма представления, подчиняющаяся тем правилам, которые отражены в синтаксисе исходного языка. Синтаксические правила, в свою очередь, тесно связаны с семантикой конструкций языка. Разные языки — разные AST.

Это всё правильно и неправильно одновременно.
Скажи, байткод — это промежуточная форма представления или целевая? Байткод ведь можно интерпретировать непосредственно, а можно скомпилировать в нэйтивный код, а можно создать процессор, который будет на аппаратном уровне поддерживать исполнения байткода. Так как он — целевая или промежуточная форма?
С AST аналогично. Фактически, после того, как AST был слинкован (символьные имены были resolved) и верифицирован — его можно исполнять, интерпретировать. Или можно продолжать его трансляцию (перевод) на другой язык — на язык байткода, на язык нэйтивных инструкций и т.п. В этом смысле AST ничем от байткода или нэйтивного кода не отличается. А с точки зрения программиста — отличается. Потому как AST (особенно если под S понимать семантику, а не синтаксис) и есть его программа. Потом эту программу можно транслировать для разных backend-ов, с разной степенью оптимизации, разным ABI — но это будет всё та-же программа.

C>>После того, как дерево построено, про исходный синтаксис можно забыть. Он больше не оказывает влияние на дальнейший процесс компиляции и исполнение программы.

ГВ>Угу. Но это дерево не может быть абы каким. Оно (его структура) тоже подчиняется жёстким правилам, заданным языком.

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

ГВ>Остаётся задать вполне логичный вопрос: а кто, и главное, как будет компилировать это самое "какое угодно" AST? Вот тебе AST, сформулированное на Lisp:

ГВ>

(node-a (construct1 a b) (construct2 c d))

ГВ>Дальше что вы намерены делать?

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

ГВ>Верно, само дерево описать не сложно. Вопрос в том, повторюсь, какое именно это должно быть дерево. То есть ключевой момент — семантика узлов AST.

"Семантика" будет определятся либо на этапе декларации узла (для "макросов"), либо внешними плагинами (tree transformation), либо она будет "встроенной" в бэкенд(ы).

ГВ>Можно задать такой набора правил, что структура узлов даного XML-дерева будет сильно похожа на AST C#. Даже эквивалентна. Но человеку оперировать такими конструкциями дико неудобно. Сокращаем до уровня удобства — получаем обратно C# или язык, эквивалентный C# с точностью до вида лексем. Ну, сможем заменить class на, скажем, XSetDescription какой-нибудь.

Посмотри на XL — с одной стороны достаточно гибкий, по мощности не уступающий лиспу. С другой стороны — по выразительности (краткости) не уступающий C#.

MC>Так что Вы хотите получить в итоге? Метаязык, подмножеством которого будут другие языки? Как XML, только более пригодный для человекописания?

Как XML, только более пригодный для человекописания? — Примерно так, но очень упрощенно. Что стоит позаимствовать у xml:
1) тривиальный и понятный лексический анализатор — то есть первый уровень корректности оформления программы можно оценить даже не загружая грамматику (xml schema)
2) единообразие конструкций
3) возможность расширять грамматику на самом XML
Конечно, человек не потерпит огромной избыточности, присущей XML описанию или прямой кальки с него.
То есть компилятору придется проводить некоторые вычисления для прояснения умолчаний, подобно тому, как современные языки производят вывод типов.

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

Универсальный синтаксис — определенно метаязык — на нем самом могут быть заданы правила и ограничения, применяемые к определенным элементам.

И этот метаязык не имеет за душой никаких намерений, кроме построения по этим правилам типизированного дерева (DOM)
Это дерево затем передается компилятору(или нескольким), который смотрит на него как на AST
Это же дерево доступно программе в Runtime — она использует его как данные.

Что бы импортировать "язык программирования" необходимо подключить(#include) модуль с описанием конструкций языка на самом метаязыке и добавить к компилятору модуль трансляции дерева DOM в дерево для back end компилятора.

Здравствуйте, ., Вы писали:
.>Подумай, чем бы ты мог заменить язык регулярных выражений, скажем?

Ну вот boost::xpressive гляньте. Вполне адекватная замена для небольших выражений.

Ну что ж. Идея ясна, хотя профит от такой затеи мне кажется сомнительным. Когда ждать набросков языка?

Здравствуйте, Mr.Cat, Вы писали:

MC>Ну что ж. Идея ясна, хотя профит от такой затеи мне кажется сомнительным. Когда ждать набросков языка?

Собственно, вопрос я задавал вопрос с целью выяснить, не изобрел ли кто уже подобный велосипед. Судя по тотальному непониманию о чем речь, подобный велосипед не слишком распространен в природе.
Вы вроде человек не ленивый и вникли. Естественны сомнения в возможности реализации.
Но почему кажется сомнительным профит от затеи? Для меня это неожиданно.

Универсальный синтаксис — значит универсальная качесвенная среда разработки,
устранение границ между вселенными разных языков — подключил модуль, изучил концепции другого языка и можешь начинать писать, вместо того что бы ставить отдельную IDE
Отсутсвует синтаксический шок при изучении другого языка.
Создание своего языка упрощается — вы не пишете лексический анализатор, гораздо проще создать грамматику, и то не целиком, а только уникальную часть
ну и т д.

Или все же сомнения в возможности реализации?

Здравствуйте, x-code, Вы писали:

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

XC>Еще более абстрактное чем XML? Интересно, как это могло-бы выглядеть?

Прочти еще раз мои слова, но более внимательно. Речь не идет о введении формата (ни нового, ни старого).
Речь идет о предоставлении программистам некого АПИ (или слоглашений) которые позволят расширять компилятор.

Скажем описываем функцию:

ststic class Initializers
{
  [Initializer]
  public static Expression[Fun[XElement]] XXml(string input, CompilerContext compilerContext)
  {
     ... // парсим ХМЛ из строки и преборазуем его в Expression генерирующий (после преобразования в код) XElement.
  }
}

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

XElement elem = XXml(@"<teg></teg>");

XXml распарсивает ХМЛ и возвращает Expression (т.е. дерево выражений из C# 3.0) описывающий функцию генерирующую требуемый граф объектов типа XElement.
Далее компилятор преобразует Expression в MSIL и помещает вместо вызова XXml.

В итоге в файле оказывается код аналогичный прямому описанию ХМЛ-я в виде объектов. При этом в коде мы описываем только текст ХМЛ-я. Это соответствует тому что мы имеем в Васике, но формат (ХМЛ в данном случае) не пришит гвоздями к языку. Любой программист сможет сделать свой инициализатор для своих нужды.

Вот только XXml — это ни что иное как макрос. А их так боится Хейлсберг.

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

C>>>Для C++ уже есть — частично в GCC-XML, частично в LLVM.
MC>>Почитав про gcc-xml, понял, что идея с универсальным синтаксисом не так уж нереальна. Только синтаксис этот — как gcc-xml — не для людей предназначен будет.
C>Да, именно. Любой синтаксис в итоге превращается в дерево. Дерево можно представить по желанию в виде XML, S-выражений LISPа, и т.п.
Вообще-то в граф превращается.

В дерево он нередко со скрипом лезет.

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

C>Как XML, только более пригодный для человекописания? — Примерно так, но очень упрощенно. Что стоит позаимствовать у xml:
C>1) тривиальный и понятный лексический анализатор — то есть первый уровень корректности оформления программы можно оценить даже не загружая грамматику (xml schema)
C>2) единообразие конструкций
C>3) возможность расширять грамматику на самом XML
C>Конечно, человек не потерпит огромной избыточности, присущей XML описанию или прямой кальки с него.
C>То есть компилятору придется проводить некоторые вычисления для прояснения умолчаний, подобно тому, как современные языки производят вывод типов.

Я пока не понял, чем требуемое отличается от Лиспа. То же AST дерево в компактной записи, тоже есть возможности расширения (макросы)..

B>Связь не очевидна. Функции IDE сильно зависят от семантики языка (рефакторинг и множество других вещей)
B>Поэтому про универсальность, основанной только на синтаксисе говорить не приходится.
B>Хотя в IDE можно использовать плагины, которые решили бы эту проблему.
B>Как следствие, здесь качественная IDE = качественные плагины.

Проведем аналогию — Текстовый формат vs XML
для первого IDE — это notepad или отдельно написанный специализированный редактор
для XML — независимо от семантики, автоматически умеем строить outline дерева программы, базовая подсветка синтаксиса, после подключения схемы еще и intellisence, все без всякого знания предметной области

аналогично и для универсального синтаксиса — подсветка, автозавршение, дерево программы — абсолютно бесплатно без плагинов
а это уже немало.
Рефакторинг — да — это плагины, хотя простейший, типа rename, может, обойдется без них.

B>Предлагается использовать одновременно несколько концепций (языков) в проекте?
B>Тогда здесь встает проблема взаимодействия этих языков. Допустим на "вход" языка работы с матрицами должны подаваться массивы определенного вида, что совсем не очевидно для "выхода" языка "как С++". Т.е. все равно необходима некая, пусть и минимальная, семантика.

— согласен, трудности существуют.

B>Теперь о более конструктивных вещах. Если описывать синтаксис, незначительно касаясь семантики, то вот некоторые вещи которые можно было бы использовать:
B>- отступы (как в Python)
B>- инфиксные операторы с приоритетами и пр. настройками (Haskell, Prolog)
B>- игры с именами идентификаторов (начальные буквы или символы #, _, $ и пр.) (Erlang, Prolog, Haskell, Smalltalk, PHP)
B>- списки (Lisp) — группа чего-то
B>- порядок слов (в Smalltalk первым в предложении стоит объект, в Haskell, Lisp — функция, затем аргументы)
B>- описание (ключ:значение) (опять Smalltalk — сообщения с несколькими параметрами)
B>- предопределенные операторы, знаки пунктуации (например, точка как взятие части от целого или как окончание предложения, [] как описание группы, точка с запятой как ... ну не знаю я

)
B>- ну и самое сложное и интересное — разнесение слов универсального языка к "частям речи" (привет J) и задание правил построения предложений. Ну чтобы AST формировался как разбор предложения естественного языка: HashMap — что? класс (существительное), какой? public (прилагательное), какой? static (тоже прилагательное). Так же с глаголами и наречиями.

B>Могу по-подробнее расписать, если непонятно выразился.

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

ключ: значение — не очень знаком, посмотрю, ключи это имена параметров? может ввести предлоги? copy FROM src TO dest

в общем, если напишите еще на эту тему или дадите ссылки на интересные статьи, буду благодарен.

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

ГВ>>AST строится на основании грамматических правил с учётом семантических ограничений. Это вспомогательная конcтрукция, а не целевая. Понимаешь? Задача компилятора — вовсе не AST сгенерировать, а выдать исполняемый код. AST — только промежуточная форма представления, подчиняющаяся тем правилам, которые отражены в синтаксисе исходного языка. Синтаксические правила, в свою очередь, тесно связаны с семантикой конструкций языка. Разные языки — разные AST.

M>Это всё правильно и неправильно одновременно.
M>Скажи, байткод — это промежуточная форма представления или целевая? Байткод ведь можно интерпретировать непосредственно, а можно скомпилировать в нэйтивный код, а можно создать процессор, который будет на аппаратном уровне поддерживать исполнения байткода. Так как он — целевая или промежуточная форма?

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

C>>>После того, как дерево построено, про исходный синтаксис можно забыть. Он больше не оказывает влияние на дальнейший процесс компиляции и исполнение программы.

ГВ>>Угу. Но это дерево не может быть абы каким. Оно (его структура) тоже подчиняется жёстким правилам, заданным языком.

M>Опять-же правильно, но не до конца. Скажем, есть такое понятие как синтаксический сахар. Эти конструкции могут транслироваться в фиксированный набор семантических понятий поддерживаемых данным языком, но в семантике языка не представленные. То есть дерево может быть в достаточной степени "абы каким", лишь бы эти дополнительные части могли быть выражены через поддерживаемые в языке семантические понятия.

Гы. То есть критерий достаточности "абыкаковости" — возможность выразить новые конструкции через уже имеющиеся. Но именно об этом я и говорю. Только не обобщаю такие высказывания до "всевыразимости вообще". Выразить — можно. Больше того, всё, что умеет один Тьюринг-полный язык, сумеет и другой. Всё дело в цене таких выражений.

ГВ>>Остаётся задать вполне логичный вопрос: а кто, и главное, как будет компилировать это самое "какое угодно" AST? Вот тебе AST, сформулированное на Lisp:
ГВ>>

(node-a (construct1 a b) (construct2 c d))

ГВ>>Дальше что вы намерены делать?

M>Рискну предположить, что дальше это будет компилировать компьютер. На основе определений данных при декларации node-a (то есть эта декларация является макросом), или же на основе внешних подключаемых к компилятору плагинов, которые будут преобразовывать узлы типа node-a.

Да-да.

ГВ>>Верно, само дерево описать не сложно. Вопрос в том, повторюсь, какое именно это должно быть дерево. То есть ключевой момент — семантика узлов AST.

M>"Семантика" будет определятся либо на этапе декларации узла (для "макросов"), либо внешними плагинами (tree transformation), либо она будет "встроенной" в бэкенд(ы).

Правильно. Я об этом и говорю — есть некий первоначальный набор структур, который будет использоваться в качестве инструментального. А теперь попробуй прикинуть, как и почему этот самый первоначальный набор будет влиять на всё, что с его помощью порождается.

M>Посмотри на XL — с одной стороны достаточно гибкий, по мощности не уступающий лиспу. С другой стороны — по выразительности (краткости) не уступающий C#.

Спасибо, посмотрю.

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

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

Бог ты мой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

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

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

AVK>Бог ты мой.

Вот только давайте не будем придираться к словам. Я думаю, Вы прекрасно понимаете о чем я говорю.
Но если все-таки нет, то вот (из первого попавшегося): A Language Workbench in Action — MPS
Сам такое не пробовал, но выглядит вполне симпатично.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

B>Вот только давайте не будем придираться к словам. Я думаю, Вы прекрасно понимаете о чем я говорю.

Понимаю конечно. Это и печалит.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

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

VD>XXml распарсивает ХМЛ и возвращает Expression (т.е. дерево выражений из C# 3.0) описывающий функцию генерирующую требуемый граф объектов типа XElement.
VD>Далее компилятор преобразует Expression в MSIL и помещает вместо вызова XXml.
VD>В итоге в файле оказывается код аналогичный прямому описанию ХМЛ-я в виде объектов. При этом в коде мы описываем только текст ХМЛ-я. Это соответствует тому что мы имеем в Васике, но формат (ХМЛ в данном случае) не пришит гвоздями к языку. Любой программист сможет сделать свой инициализатор для своих нужды.
VD>Вот только XXml — это ни что иное как макрос. А их так боится Хейлсберг.

Хороший подход

Но тогда получается, что и многие конструкции языка можно реализовать таким вот способом... Т.е. с этой точки зрения компилятор — это язык макросов + API к построителю деревьев выражений + генератор кода? А синтаксис — это только какая-то минимальная база (соглашения об именах, скобках, некотором минимуме ключевых слов и т.д.)
Кстати, "язык макросов" — это должен быть тот же язык, что и основной (как я понимаю, так сделано в Nemerle), или что-то другое? Если тот-же, то могут ли макросы использовать макросы, и что делать если для генерации кода макроса1 используется макрос2, а для макроса2 — макрос1, и т.д.?
Если сделать такую систему вне дотнета (например для С++ или D) — каким по Вашему должен быть язык макросов?

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

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

C>Вопрос такой – возможно ли отделить синтаксис языков программирования от семантики.

Ответ будет зависеть от того, что Вы понимаете под "семантикой языков программирования"

C>Возможно ли создать универсальный синтаксис, эффективный для человека и пригодный для описания произвольной семантики современных языков программирования.

C>Под описанием семантики я подразумеваю формирование(при помощи универсального синтаксиса)дерева — эквивалентного дереву разбора, которое формирует парсер обычного языка.

Безусловно. С одним "но"... см. ниже.

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

А "оригинального" — это какого?

C>Сегодня синтаксис и семантика языка связаны – каждый язык имеет свою грамматику для описания набора концептов, которыми язык оперирует – классов, функций, переменных и т д

Хм... Семантика... Семантика-то в грамматику языка не входит. Чи под семантикой языка Вы понимаете "набор концептов, которыми язык оперирует"!?

C>Несколько языков имеют примерно общую семантику, но различный синтаксис, как в примере Visual basic .Net and C#

Эээ... Т.е. семантика это уже не "набор концептов, которыми язык оперирует"? Просто уточняю... у Nemerle, например, ... и ну у F#... "семантика" тоже "примерно общая"? А у C# и Nemerle?

C>Более того, существуют предложения создавать грамматику на каждый новый набор понятий (DSL)

Существуют. Но не понятно к чему тут "более того"?!

C>Напрашивается аналогия с XML

Так... Вы о универсальном синтаксисе какого языка? В том смысле, языка описания чего? Из сказанного Вами выше, вроде как следует что, о языке описания "дерева — эквивалентного дереву разбора..." Так? Ну тогда в чем проблемы? Домен, так сказать, определ... вот определение "эффективности" малость не понятное. Но все же... в чем проблема?

C>Начасть можно с рассмотрения лексических примитивов:

Дальше у вас идет перечесление "примитивов" имеющих весьма опосредованное отношение к "дереву разбора". По этому, повторяю вопрос... О языке описания чего идет речь?

C>Потребность в синтаксисе не связанном с семантикой зачастую возникает в рамках программирования на любом языке.

Вообще говоря, синтаксис и так с семантикой никак не связан

Вопрос только в том, что Вы понимаете под семантикой.

C>Когда в программу на C# или C++ нужно вставить какое нибудь дерево, типа XML, HTML, SQL и т д — тут начинается нецелевое использование конструкций языка, таких как: темплейты, выражения, дерево классов. Функциональные языки приспосабливают свои функции.

Слабо понял о чем речь? Можно по подробней на тему "в программу ... вставить ...дерево, типа XML, HTML, SQL"? Что значит "вставить"?

C>Решение, не очень хорошее, в природе существует – синтаксис типа лиспа, ...

"Ситаксис типа лиспа" решения в своей области весьма удачное. И возможно, если в Вашем опеределении "эффективности для человека" разобраться с термином "оригинальное описание", то все встанет на свои места.

C> ... или гораздо хуже XML – можно выразить что хочешь, но слишком многословно, и недостаточно статически типизировано.

за типизацию.

C>Хотелось бы понять, почему конкретный синтаксис настолько более компактен по сравнению с общим и какие успехи достигнуты в данном направлении мыслящим сообществом.

Опять же... за синтакис языка описания чего идет речь? Или мы за синтаксис вообще?

---
С уважением, Сиваков Константин.

От:	VladD2	www.nemerle.org
Дата:	15.10.08 16:35
Оценка:	12 (1) +3

От:	samius	http://sams-tricks.blogspot.com
Дата:	15.10.08 15:08
Оценка:

	От:	Mr.Cat
	Дата:	16.10.08 10:24
	Оценка:	3 (1) +2

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	20.10.08 17:53
Оценка:	+1

	От:	Mr.Cat
	Дата:	17.10.08 12:28
	Оценка:	1 (1) -1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	16.10.08 23:15
Оценка:	-1

От:	mkizub	http://symade.tigris.org
Дата:	18.10.08 14:19
Оценка:	2 (1)

От:	eao197	http://eao197.blogspot.com
Дата:	15.10.08 15:11
Оценка:	+1

От:	Курилка	http://kirya.narod.ru/
Дата:	21.10.08 15:37
Оценка:

От:	thesz	http://thesz.livejournal.com
Дата:	16.10.08 19:53
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	20.10.08 03:36
Оценка:

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	20.10.08 12:41
Оценка: