OSDev

Этот момент решается очень просто – маскированием символов внутри строковой константы, например так:

И, кстати, в данном случае вложенность комментариев не играет никакой роли, такая конструкция ломает и невложенный комментарий.
Хуже обстоит дело с так называемыми raw strings, там где вся предварительная обработка отключена, но они в целом и так представляют собой кошмар лексического анализатора.
ЕМНИП, я пытался оставить свои комментарии на вашем сайте, но почему-то они не оставлялись.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Ещё можно использовать слияние строк
char x[] = "*" "/";

По поводу elseif:

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

И так может продолжаться долго. Иногда switch/case не применим, например, когда условия в цепочке сложные, касаются разных переменных, или когда идет не просто проверка на числа. И это будет ужас.
Возможно имеет смысл сделать единственный случай отсутствия операторных скобок - наличие if после else. Это, конечно, несколько идет вразрез с обсуждаемой концепцией, но во всяком случае поможет избежать вышеописанной ситуации.
А слово elseif мне не нравится по самому смыслу - это ж склейка двух уже существующих ключевых слов в третье, причем какое-то противоестественное, да еще и так сказать создающее новый тип блока ветвления.

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

Идею спецразметки для нерабочего кода я нахожу годной, рассматриваю вариант реализации. В Канторе это наверняка будет еще один DSL -- разбираемый синтаксическим анализатором Кантора в /dev/null. Нужно только символ придумать.


Я уже на это напоролся. Вначале принял опрометчивое решение, заменив elsif совмещением else if, а теперь его приходится исправлять, чтобы не возвращать уродца в синтаксис.

Да, действительно, неоднозначность ввиду отсутствия открывающих операторных скобок - проблема. Похоже, что при сохранении else и if отдельными словами решить эту проблему могут только строгие отступы (конкретно, else if - это тот самый elseif, а else \r\n if - это уже новая команда в блоке, требующем отдельного end). Хотя это все равно несколько нарушает концепцию и не есть комильфо.

Не совсем понимаю, о чём вы. Можно маскировать автоматически в IDE, это делается довольно просто - достаточно парсить все строковые и символьные константы и заменять последовательности */ на *\/, семантика от этого не меняется. Может это делать и программист, особенно удачно совмещается с подсветкой синтаксиса, – после комментирования участка кода случайно оставшаяся часть будет подсвечена как код. В конце концов, не проблема столкнуться с синтаксической ошибкой – это будет мгновенно обнаружено при ближайшей компиляции. Проблема – столкнуться с ситуацией, когда синтаксических и грамматических ошибок не возникнет, и код начнёт компилироваться с другой семантикой. Такая ситуация здесь практически исключена, т.к. закрывающая кавычка превратится в открывающую и чтобы сохранить компилируемость, надо сильно извратиться с содержимым строки, последующими комментариями и кодом вокруг этого участка.


Я эту проблему давно решил для себя даже в C/C++ следующим образом:

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Чтобы не смешивать управляющие символы с выражениями, можно применить ограничение, запрещающее управляющие символы в середине строки, а только в начале и в конце. Можно так
/* ... */
или так
/* ...
...
... */
так же можно
/*
...
*/
а так нельзя
... /* ... */ ...

Извините, а зачем вы вообще суете в комментарии код, они же не для этого? что-то надо выкинуть из программы, но возможно вернуть или просто временно отключить?
Есть такая вещь как Система управления версиями, удалил что не надо сделал коммит. не понравилось вернул.
Разумеется можно внести в блок токенизатора, обходящий комментарии, обработку строковых констант, и даже вложенные обработать (только если используется формат begin-end здесь /*...*/) это вообще то тривиально.
и можно дальше продолжать спокойно есть свой суп вилкой.

Идея в том, чтобы иметь в языке синтаксическое средство для гарантированного комментирования нерабочего кода, безо всяких там случайностей. Во время творческого процесса программист не должен отвлекаться на мелочи. А то тут компромисс, там компромисс, на авось понадеялись... и знакомое УГ вышло.

Многие редакторы умеют комментировать и раскомментировать множество строк в выделенном блоке путём построчной вставки хвостового комментария типа //. Тоже хороший вариант.