Почему языки программирования не допускают пробелов в идентификаторах?

это может показаться глупым вопросом, но я все еще не знаю ответа.

Почему языки программирования не разрешают пробелы в именах (например, имена методов)?

Я понимаю, что это облегчает ( позволяет ) разбор, и в какой-то момент было бы невозможно разобрать что-либо, если бы были разрешены пробелы.

в настоящее время мы настолько привыкли к нему, что норма не вижу пробелов.

для пример:

 object.saveData( data );
 object.save_data( data )
 object.SaveData( data );
 [object saveData:data];

etc.

может быть записан в виде:

 object.save data( data )  // looks ugly, but that's the "nature" way.

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

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

редактировать

Я в порядке с идентификаторами в целом (как пример fortran) - плохая идея. Сужаясь к языкам OO и конкретно к методам, я не вижу ( я не имею в виду, что их нет ) причины, почему это должно быть так. Ведь все . и "первый"!--5--> может быть использован.

и забыть saveData метод , учитывайте это один:

key.ToString().StartsWith("TextBox")

as:

key.to string().starts with("textbox");
6
language-agnostic language-design

10 ответов

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

a = 1.2423 / (4343.23 * 2332.2);

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

5

быть, потому что я twoul д makepa rsing hcode успе reallydif сложную.

49

я использовал реализацию Алгол (c. 1978), который-чрезвычайно раздражающе-требовал цитирования того, что теперь известно как зарезервированные слова, и допустил пробелы в идентификаторах:

  "proc" filter = ("proc" ("int") "bool" p, "list" l) "list":
     "if" l "is" "nil" "then" "nil"
     "elif" p(hd(l)) "then" cons(hd(l), filter(p,tl(l)))
     "else" filter(p, tl(l))
     "fi";

кроме того, FORTRAN (заглавная форма означает F77 или ранее) был более или менее нечувствителен к пробелам. Так что это можно было написать:

  799 S = FLO AT F (I A+I B+I C) / 2 . 0
      A  R E  A = SQ R T ( S *(S - F L O ATF(IA)) * (S - FLOATF(IB)) *
     +     (S - F LOA TF (I C)))

, который был синтаксически идентичен

  799 S = FLOATF (IA + IB + IC) / 2.0
      AREA = SQRT( S * (S - FLOATF(IA)) * (S - FLOATF(IB)) *
     +     (S - FLOATF(IC)))

С таким видом истории злоупотребления, зачем делать разбор затруднен для людей? Не говоря уже о усложнении компьютерного анализа.

14

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

8

Проверьте классику Страуструпа обобщение перегрузки для C++2000.

4

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

мы просто не можем ждать еще 50 лет, прежде чем наш код будет работать снова. :-)

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

4

такое изменение сделало бы для двусмысленного языка в лучшем случае. Например, на языке, подобном C99:

if not foo(int x) {
    ...
}

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

  1. определение функции foo, который возвращает значение типа ifnot:

    ifnot foo(int x) {
    ...
}

  2. вызов функции notfoo с переменной с именем intx:

    if notfoo(intx) {
    ...
}

  3. отрицательный вызов функции foo (с С99 это not что означает !):

    if not foo(intx) {
    ...
}

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

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

4

использование пространства как части идентификатора делает разбор действительно мутным (это синтаксическое пространство или идентификатор?), но такое же поведение "естественного чтения" достигается с помощью аргументов ключевых слов. object.save(data: something, atomically: true)

1

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

Я не думаю, что есть реальная причина.

1

на TikZ язык для создания графики в LaTeX позволяет пробелы в именах параметров (также известный как "ключи"). Например, вы видите такие вещи, как 

\shade[
  top color=yellow!70,
  bottom color=red!70,
  shading angle={45},
]

в этом ограниченном параметре списка пар ключ-значение, разделенных запятыми, нет трудностей с разбором. На самом деле, я думаю, что это гораздо проще читать, чем альтернативы, такие как topColor, top_color или topcolor.

0