Контекстно-зависимость в синтаксисе ЯП

Сила.

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

Ты что, операторы сдвига это ← и →.

это не сдвиг, а левый правый поворот.

Кстати, когда мне понадобились разные виды математических скобок при вводе алгебраических выражений, я взял синтаксис питона и добавил его вот такими штуками (%...%), [%...%], {%...%}, <%...%>, |%...%| — оказалось афигенно удобно. Можно и для шаблонов и пр. че то такое ввести.

Как бы вы сделали эту часть грамматики контекстно-свободной, если бы дизайнили ЯП с нуля? Ваши идеи?

Выбирал бы между двумя вариантами:
* не делать операторы «больше» и «меньше» (нафиг они не сдались, чтобы под них кракозябру ещё резервировать)
* не делать скобок на угловых скобках (вообще лучше бы в коде поменьше кракозябр, в том числе и скобок)

Или, ещё лучше, оба варианта осуществить одновременно.

с точки зрения чистой семантики актуализация шаблона есть s выражение вида

(apply_template template_name param1 param2 ...)

что обозначает - специализируем template_name c параметрами …

любые формы тождественные этой будут правильными.

например заменим apply_template на @ и получим

@template_name(param1, param2, ...)

например вызов темплейтной функции будет таким

@template_fun(int, int)(1,2,3)

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

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

Поэтому если синтаксис не предусматривает запись template_fun(1,2,3) вместо @template_fun(int, int)(1,2,3), то задача не решена.

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

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

Можно запретить некоторые одноранговые операторы без скобок.

Типа запретить больше одного присваивания, сравнения и т д в выражении. Если программист хочет их так использовать, пусть явно расставляет скобки для приоритета. Это автоматически уберёт путаницу с шаблонами, ибо там два оператора сравнения на одном уровне в одном выражении.

Если сложение, вычитание, умножение и некоторые другие операции используются в C++ так же как и в математике, то то же сравнение нет. В математике есть a > b > c, в C++ это будет сравнение с булева результатом сравнения, что чаще является ошибкой, чем желаемым поведением.

Как бы вы сделали эту часть грамматики контекстно-свободной, если бы дизайнили ЯП с нуля? Ваши идеи?

Есть символы для обозначения шаблонов, есть символы для обозначения операций. Символы совпадают и это вызывает проблему. Решение - используйте разные символы, они совпадать не будут и проблема не возникнет.

foo«a»(b); // шаблон  
foo<a>(b); // сравнение  

UPD: прочитал тему, это уже трёхкратный баян

То ли это шаблонная функция foo<a>, вызываемая с аргументом b.
То ли это выражение (foo < a) > b.

Что-то мало вариантов.

Эти варианты какие-то кривые. В первом foo<a> b не было.

«Нормальный препроцессор» есть только в лиспе, и на убогие недоязыки типа сишечки не цепляется. И если его добавить в язык, язык автоматически становится диалектом лиспа.

Elixir — это тоже диалект лиспа?

в эликсире говно, а не «нормальный препроцессор»

Тогда вот сдвиг:

a ≪ b ≫ c

А вот шаблон

foo«a»

И если его добавить в язык, язык автоматически становится диалектом лиспа.

Процедурные макросы в расте равномощны лисповым макросам (даже чуть мощнее за счёт гигиены).

Это конечно, не так

А в чём разница? В обоих случаях макрос = функция, получающая на вход список токенов и возвращающая список токенов.