Как гибкость влияет на синтаксис языка?

Question

В настоящее время я работаю над написанием своего собственного языка ( бесстыдный плагин ), который основан на гибкости. Я пытаюсь сделать практически любую часть синтаксиса языка доступной для обмена с помощью таких расширений / плагинов. Когда я пишу все это, это заставляет меня задуматься. Мне интересно, как такая гибкость может повлиять на язык.

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

Мой вопрос: как гибкий синтаксис может повлиять на интуитивность и удобство использования языка? Я знаю основные «люди могут быть смущены при изменении синтаксиса» и «семантический анализ будет трудным». Это то, что я уже начинаю компенсировать. Я ищу более концептуальный ответ на плюсы и минусы гибкого синтаксиса.

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

Edit: Я просто хотел уточнить вопрос, который задавал. Где именно гибкость в синтаксисе языка, с точки зрения теории языка? Мне действительно не нужны примеры или проекты / языки с гибкостью, я хочу понять, как это может повлиять на читаемость языка, его функциональность и тому подобное.

Answer 1

Common Lisp позволяет изменить способ его анализа - см. Макросы читателя.Racket позволяет модифицировать свой парсер, см. Языки ракеток.

И, конечно, вы можете иметь гибкий, динамически расширяемый синтаксический анализ наряду с мощными макросами, если вы используете правильные методы синтаксического анализа (например, PEG).Взгляните на пример здесь - в основном синтаксис C, но расширяемый как синтаксическими, так и семантическими макросами.

Что касается приоритета, PEG действительно хорошо сочетается с Pratt.

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

Так что я могу поделиться только своими волнистыми анекдотами - гибкими синтаксическими языкамиоблегчает построение eDSL, и, на мой взгляд, eDSL - единственный способ устранить ненужную сложность кода, чтобы сделать код реально поддерживаемым в долгосрочной перспективе.Я считаю, что негибкие языки - это одна из самых больших ошибок, допущенных в этой отрасли, и ее необходимо исправить любой ценой, КАК МОЖНО СКОРЕЕ.

Answer 2

Гибкость позволяет манипулировать синтаксисом языка.Например, макросы Lisp могут позволить вам писать программы, которые пишут программы и манипулируют вашим синтаксисом во время компиляции для корректных выражений Lisp.Например, Loop Macro:

(loop for x from 1 to 5
      do(format t "~A~%" x))

1
2
3
4
5
NIL

И мы можем видеть, как код был переведен с помощью macroexpand-1:

(pprint(macroexpand-1 '(loop for x from 1 to 5
                 do (format t "~a~%" x))))

Затем мы можем увидеть, как переводится этот макрос:

  (LET ((X 1))
(DECLARE (TYPE (AND REAL NUMBER) X))
(TAGBODY
 SB-LOOP::NEXT-LOOP
  (WHEN (> X '5) (GO SB-LOOP::END-LOOP))
  (FORMAT T "~a~%" X)
  (SB-LOOP::LOOP-DESETQ X (1+ X))
  (GO SB-LOOP::NEXT-LOOP)
 SB-LOOP::END-LOOP)))

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

(defmacro backwards (expr)
   (reverse expr))
BACKWARDS
CL-USER> (backwards ("hello world" nil format))
"hello world"
CL-USER> 

Очевидно, что приведенный выше код может стать сложным, поскольку:

 ("hello world" nil format)

не является допустимым выражением Lisp.

Answer 3

Perl - самый гибкий язык, который я знаю. Если взглянуть на Moose , постмодернистскую объектную систему для Perl 5. Ее синтаксис сильно отличается от синтаксиса Perl, но все же очень сильно отличается от Perl.

ИМО, самая большая проблема с гибкостью - приоритет в инфиксной нотации. Но ни один из тех, кого я знаю, не позволяет типу данных иметь собственный синтаксис инфикса. Например, взять наборы. Было бы неплохо использовать ⊂ и ⊇ в их синтаксисе. Но не только компилятор должен будет распознавать эти символы, но и должен быть указан их порядок приоритета.

Answer 4

Спасибо SK-logic за то, что указал мне в направлении Алана Блэквелла. Я послал ему электронное письмо с вопросом о его позиции по этому вопросу, и он ответил совершенно замечательным объяснением. Вот оно:

Итак, человек, который ответил на ваш вопрос StackOverflow, сказав этот гибкий синтаксис может быть полезен для DSL, безусловно, правильно. На самом деле было довольно распространено использовать препроцессор C для создать альтернативный синтаксис (который будет превращен в обычный синтаксис в начальная фаза компиляции). Многие ранние esolangs были построены в этом способ.

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

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

На данный момент этого достаточно для объяснения, которое я искал. Если кому-то кажется, что у него есть лучшее объяснение или что-то, что можно добавить, не стесняйтесь связаться со мной.