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

Question

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

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

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

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

Например:

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

и т.д..

Может быть записано как:

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

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

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

EDIT

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

И забудьте о методе saveData, рассмотрите этот:

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

как:

key.to string().starts with("textbox");

Answer 1

Потому что я готов сделать успехи действительно трудно.

Answer 2

Я использовал реализацию ALGOL (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)))

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

Answer 3

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

Answer 4

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

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

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

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

   ifnot foo(int x) {
       ...
   }
   

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

   if notfoo(intx) {
       ...
   }
   

3. Отрицательный вызов функции с именем foo (с C99 not, что означает !):

   if not foo(intx) {
       ...
   }
   

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

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

Answer 5

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

a = 1,2423 / (4343,23 * 2332,2);

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

Answer 6

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

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

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

Answer 7

Ознакомьтесь с классической записью Страуструпа Обобщающая перегрузка для C ++ 2000 .

Answer 8

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

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

Answer 9

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

Answer 10

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

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

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