Как обычно комментируются комментарии?

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

Например, должен ли комментарий, встроенный в токен, «вмешиваться» в токен или нет? Как правило, это что-то вроде:

Sys/* comment */tem.out.println()

действует?

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

stuff stuff /* this is comment
this is still comment */more stuff 

следует рассматривать как

stuff stuff more stuff

или

stuff stuff
more stuff

?

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


Мой конкретный контекст является вики-подобной разметкой.

31 голос | спросил ArtB 29 +03002015-10-29T19:35:22+03:00312015bEurope/MoscowThu, 29 Oct 2015 19:35:22 +0300 2015, 19:35:22

5 ответов


40

Обычно комментарии сканируются (и отбрасываются) как часть процесса токенизации, но до разбора. Комментарий работает как разделитель токенов даже в отсутствие пробелов вокруг него.

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

Содержание комментариев игнорируется, поэтому разрывы строк внутри многострочных комментариев не влияют. Языки, которые чувствительны к разрыву строк (Python и Visual Basic), обычно не имеют многострочных комментариев, но одним исключением является JavaScript. Например:

return /*
       */ 17

Является эквивалентным

return 17

не

return
17

Одиночные комментарии сохраняют разрыв строки, т. е.

return // single line comment
    17

эквивалентно

return
17

не

return 17

Поскольку комментарии сканируются, но не анализируются, они, как правило, не гнездятся. Так

 /*  /* nested comment */ */

является синтаксической ошибкой, так как комментарий открывается первым /* и закрывается первым */

ответил JacquesB 29 +03002015-10-29T20:07:58+03:00312015bEurope/MoscowThu, 29 Oct 2015 20:07:58 +0300 2015, 20:07:58
8

Чтобы ответить на вопрос:

  

существует ли общий консенсус, что обычно ожидается с помощью метки?

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

Как правило, комментарии следует рассматривать так же, как пробелы. Любое место, которое было бы действительным, чтобы иметь посторонние пробелы, также должно иметь встроенный комментарий. Единственным исключением могут быть строки:

trace("Hello /*world*/") // should print Hello /*world*/

Было бы довольно странно поддерживать комментарии внутри строк и ускользнуть от них утомительно!

ответил Connor Clark 29 +03002015-10-29T20:12:54+03:00312015bEurope/MoscowThu, 29 Oct 2015 20:12:54 +0300 2015, 20:12:54
7

В языках с незащищенными пробелами игнорируемые символы (т. е. пробелы или те, которые являются частью комментария) ограничивают токены.

Итак, например Sys tem - два токена, а System - один. Полезность этого может быть более очевидной, если вы сравните new Foo() и newFoo(), один из которых построит экземпляр Foo, в то время как другие вызовы newFoo

Комментарии могут играть ту же роль, что и пробег пробелов, например. new/**/Foo() работает так же, как new Foo(). Конечно, это может быть более сложным, например. new /**/ /**/ Foo() или еще что-то.

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

Теперь, что из чувствительных к белому пространству языков?

Python приходит на ум, и он имеет очень простой ответ: никаких комментариев блока. Вы начинаете комментарий с помощью #, а затем парсер работает точно так же, как если бы остальная часть строки не существовала, а была просто новой линией .

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

body
  //-
    As much text as you want
    can go here.
  p this is no longer part of the comment

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

ответил back2dos 29 +03002015-10-29T20:25:23+03:00312015bEurope/MoscowThu, 29 Oct 2015 20:25:23 +0300 2015, 20:25:23
2

В прошлом я превратил комментарии в один токен как часть лексического анализа. То же самое касается строк. Оттуда жизнь легко.

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

Следствием этого является то, что в примере, который вы отправили с комментарием в середине идентификатора, идентификатор не был бы единственным идентификатором - это ожидаемое поведение на всех языках (из памяти) ve работал с.

Случай комментария в строке должен быть неявно обработан лексическим анализом. Правила обработки строки не интересуются комментариями, и поэтому комментарий рассматривается как содержимое строки. То же самое относится к строке (или цитируемому литералу) в комментарии - строка является частью комментария, которая явно является единственным токеном; правила обработки комментария не интересуются строками.

Я надеюсь, что это имеет смысл /помогает.

ответил user202190 30 +03002015-10-30T08:34:38+03:00312015bEurope/MoscowFri, 30 Oct 2015 08:34:38 +0300 2015, 08:34:38
1

Это зависит от того, в чем состоит ваш парсер. Если вы пишете синтаксический анализатор для построения дерева синтаксического анализа для компиляции, то комментарий не имеет семантического значения, помимо потенциального разделения токенов (например, method / comment /(/ comment /)). В этом случае его обработанные подобные пространства.

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

Также, если у вас есть метаинформация в комментариях, и вы особенно заботитесь о комментариях, например, при создании API-документации, такой как JavaDoc, комментарии очень важны.

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

Идея аннотации токенов без комментариев с комментариями заключается в том, чтобы вообще удалить комментарии из грамматики.

После того, как у вас есть дерево разбора, некоторые AST начинают распаковывать комментарии, представляющие каждый токен, своим собственным AST-Element, но прикрепляются к другому AST-Element наряду с обычными сословными отношениями. Хорошая идея - проверить все реализации парсера /АСТ для исходных языков, доступных в среде с открытым исходным кодом.

Одна очень хорошая реализация - это инфраструктура компилятора Eclipse для языка Java. Они сохраняют комментарии во время токенизации и представляют комментарии в АСТ - насколько я помню. Кроме того, реализация этого анализатора /AST сохраняет форматирование.

ответил Martin Kersten 26 TueEurope/Moscow2017-12-26T13:02:45+03:00Europe/Moscow12bEurope/MoscowTue, 26 Dec 2017 13:02:45 +0300 2017, 13:02:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132