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

22

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

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

Я не считаю удобство для автора компилятора важным для конечного пользователя языка. В наши дни компьютеры достаточно мощны, чтобы иметь возможность выводить значения из контекста. При написании романа не более, чем писателю нужно помечать существительные, глаголы и тому подобное, почему программист должен маркировать функции и переменные с помощью function x() {}или set x = 1или и var x = 1т. Д .; когда я могу вывести из контекста операторов, что это объявление функции или вызов или что метка является присваиванием значению или ссылкой на это значение метки?

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

Объявление функции

sum3(a,b,c) -> a + b + c.

Вызов функции

x = sum3(1,2,3).

Анонимная функция с именем x

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

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

theory languages

8

Forth довольно практичен, и у него нет никаких ключевых слов.

— SK-logic

4

@JamesAnderson, нет, это просто слова, как и все остальные слова. Никакого особого значения вообще.

— SK-logic

7

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

— Эмилио Гаравалья

2

@ СК-логика: обычно. Но что такое «идентификаторы», если вы еще не разбили токены? Так как токен является «любым распознаваемым sting», «int», «myvalue» и «+» не различаются до того, как было дано правило синтаксиса. Если «+» не определен как оператор, это может быть просто имя для чего-то похожего на любую другую строку символов Unicode. Операторы, с точки зрения чистого синтаксиса, являются не чем иным, как «односимвольными ключевыми словами».

— Эмилио Гаравалья

2

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

— Дэвид Торнли

12

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

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

— Мировой инженер
источник

2

+1 за «Ключевые слова помогают авторам компилятора легче выполнять синтаксический анализ». Я думаю, что это в значительной степени так. Ключевые слова были изобретены для сокращения объема контекста, который парсер должен хранить в памяти, когда весь компилятор вместе с его рабочим набором помещался в дюжину КБ ОЗУ.

— Йорг Миттаг

2

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

— Джеймс Андерсон

2

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

— Джеймс Андерсон

6

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

— Blrfl

@Blrfl В этом суть J, K и Q. Все они в той или иной степени соответствуют APL в ASCII.

— мировой инженер

9

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

Это приводит к простому (но непростому) синтаксису и является одной из вещей, которые позволили Лиспу иметь такую мощную систему макросов. С другой стороны, часто говорят, что Лисп трудно читать. APL и MUMPS, тем более, я видел, как оба описали как на полпути к Brainf * ck. Ключевые слова помогают в этом отделе и облегчают чтение кода для нас, людей.

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

— scrwtp
источник

1

IIRC Lisp не имеет ключевых слов. Специальные формы должны обрабатываться компилятором специально, но их имена являются обычными символами.

— Ян Худек

2

Ключевые слова - это особенность синтаксиса, которого нет в Лиспе. Я даже не думаю, что имеет смысл говорить о ключевых словах в Лиспе.

— Йорг W Mittag

2

Я согласен с Йоргом. Я думаю, что можно говорить о ключевых словах, когда в языке есть токены, которые должны быть явно определены как особые, чтобы их можно было отличить от токенов с похожей структурой. Разные токены приводят к разным синтаксическим деревьям. Например, ifв C был бы действительный идентификатор, если бы он не был определен как специальный (ключевое слово). Это означает, что ifэто не идентификатор и if = 10выдает синтаксическую ошибку. Если я не ошибаюсь, минимальный синтаксис Lisp не выделяются defunиз f, x, yи +в (defun f (x y) (+ x y)).

— Джорджио

@Giorgio, в частности, if является допустимым именем переменной в Common Lisp (и других Lisp-2) (defparameter if nil), ничего не сломает, и его можно использовать в таких формах, как(unless if (setf if t))

— tobyodavies

На той же ноте, правда, не (defun if ...)получится. Принимал заметки из комментариев к учету и редактировал ответ. Я могу согласиться с тем, что специальные формы не являются ключевыми словами на том же уровне, что и в C, например, тем не менее, они наиболее близки к Lisp.

— scrwtp

8

TCL не имеет ключевых слов, и в действительности только 12 правил синтаксиса. хотя он не так популярен, как раньше, он имеет свою нишу с ожиданиями и встроен в ECAD и маршрутизаторы, поэтому, на мой взгляд, он считается практичным.

Я также думаю, что это может показать, почему многие языки не идут по этому пути. Да, вполне возможно написать синтаксический анализатор TCL (возможно, проще, чем многие другие языки), однако вы не можете написать очень полезную грамматику BNF для языка, и многие люди, кажется, испытывают проблемы с изучением языка. Я подозреваю, что это хотя бы частично из-за отсутствия ключевых слов.

— JK.
источник

2

В этом отношении Tcl очень похож на Lisp, за исключением того, что вместо «все является списком» он имеет «все является строкой». Список - это просто строка с пробелами в нем, а вызов процедуры - это просто список, первый элемент которого интерпретируется как имя процедуры, а остальные - как ее аргументы. По сути, это S-выражение Lisp.

— Йорг Миттаг,

да, они оба используют польские обозначения и являются гомо-иконическими, поэтому имеют довольно схожую семантику

— jk.

5

В наши дни компьютеры достаточно мощны, чтобы иметь возможность выводить значения из контекста.

Означает ли это, что вам нужна грамматика, не зависящая от контекста? Удачи.

Вопрос не в том, могущественен он или нет. Есть вечные, неизменные правила о языках - математические. Это и тот факт, что язык программирования должен быть синтаксически легким, заставят CFG управлять в течение нескольких десятилетий.

Кстати, в Haskell, как синтаксис, вы просто пишете что-то вроде

f x y = (x+1)*(y-1)

определить функцию. Но обратите внимание, что «ключевое слово» в этом случае - «=». Если вы пропустите это, в парсере произойдут ужасные вещи.

Но это тот момент, когда я согласен с вами, я нахожу это гораздо более интуитивным, чем все ключевые слова def, dcl, fun, fn, function или what-not, которые вводят функции в других языках.

Тем не менее, эта грамматика может быть написана простым старым LALR (1), здесь нет никакого значения, «выведенного из контекста».

— Инго
источник

1

+1 за решение этого утверждения (в наши дни компьютеры достаточно мощные, чтобы иметь возможность выводить значения из контекста). Я думаю, что причина, по которой грамматики CFG являются предпочтительными, заключается в том, что они позволяют определять структуру программы индуктивно. Я не понимаю, почему кто-то хотел бы изменить это даже через 100 лет, может быть, мне просто не хватает воображения?

— Джорджио

2

CFGs довольно мертвы и были мертвы десятилетиями. JavaScript внутри HTML, даже строки формата C внутри C, даже вложенные комментарии, скажем, в OCaml - все это не является контекстно-свободным. И почему вы хотите ограничить себя таким произвольно выбранным формализмом сейчас, в эпоху PEG и GLR?

— SK-logic

1

@ Да, да, ты прав, неправильный выбор примера. Я имел в виду смешанные и расширяемые (то есть, высокого порядка) грамматики, которые не являются CFG.

— SK-logic

2

@ SK-логика: я не знаю, где вы получили информацию о том, что CFG довольно мертв. Я разговаривал с моим бывшим коллегой, который преподавал конструирование компиляторов в течение последних 20 лет, и CFG, похоже, далеко не мертвы.

— Джорджио

1

@Ingo: Насколько я помню, аспекты не CF обрабатываются впоследствии путем семантического анализа дерева разбора. Например, { int x = 0; x = "HELLO"; }должно генерироваться дерево разбора, но когда компилятор ищет x во втором присваивании, он видит, что оно было объявлено как int, и выдает ошибку типа. Таким образом, программа отклоняется, даже если ее структура CF правильная.

— Джорджио

4

Насколько я знаю, Smalltalk - это язык с наименьшим количеством ключевых слов (если я не считаю такие языки, как Brainfuck). Smalltalk ключевые слова true, false, nil, self, superи thisContext.

Я разработал язык, вдохновленный smalltalk, в котором не было ключевых слов. Но после некоторого времени использования я добавил несколько ключевых слов, в основном для синтаксического сахара.

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

— дель-мальчик
источник

Если бы Smalltalk имел поддержку для отправки сообщений с неявным получателем, то, по крайней мере true, falseи nilмог бы быть определен как методы для этого неявного получателя, и, учитывая возможности отражения, возможно, что остальные три также.

— Йорг W Mittag

1

Это не ключевые слова, они псевдопеременные. «Псевдо», потому что true, falseи nilявляются общеизвестными значениями, предоставленными средой и self, superи thisContextявляются переменными, которые вы не можете установить, но чьи значения изменяются в результате выполнения.

— Фрэнк Ширар

3

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

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

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

Кроме того, не пренебрегайте концепциями, которые облегчают работу компилятора. Чем проще разобрать, тем быстрее будет компилироваться ваш код, что означает, что циклы edit-build-debug становятся быстрее, а значит, ваша производительность повышается.

Если у вас большая и сложная кодовая база, это может привести к нетривиальной разнице в производительности. Например, там, где я работаю, у нас есть работающая программа, которая насчитывает около 4 миллионов строк Delphi. У нас есть еще один модуль, который содержит около 300 000 строк C ++. Они оба занимают примерно одинаковое время для компиляции. (Около 3 минут.) Если бы у нас было 4 миллиона строк C ++, сборка могла бы занять час!

— Мейсон Уилер
источник

Все отличные баллы. +1

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

@JarrodRoberson: Конечно, было бы, но код не роман. Естественные языки очень отличаются от языков программирования. Естественный язык понимается интуитивно, тогда как язык программирования имеет формальную семантику. Методы, используемые для его прочтения и понимания его смысла, очень разные, и попытка приравнять их, как и вы, - ошибка.

— Мейсон Уилер

Я сказал компилятор, который отличается от компилятора . Компиляторы работают быстрее на более быстром оборудовании, авторы компиляторов - люди, мы не придерживаемся закона Мура!

кодовые базы, с которыми я склонен работать, на несколько порядков длиннее романов, большинство из них> 1 000 000+ строк кода, большинство самых длинных романов - <2 000 000 слов ! И как романы, которые они читают людьми, на самом деле больше времени тратится на чтение кода, чем на его написание! Учитывая, что кодовая база> 10 лет и более 1 000 000 строк, число раз, которое разработчики читают за 10 лет, превосходит время, затраченное на создание.

2

Есть несколько редких примеров.

APL использует только символы - но их много! Вам нужна специальная клавиатура, чтобы использовать язык.

Смотрите эту статью в Википедии

CORAL 66 - имел ключевые слова, но распознавал их, только если они были заключены в одинарные кавычки.

В PL / 1 также были ключевые слова, но вы также можете использовать их в качестве имен переменных или процедур.

В целом, хотя ваш вопрос немного напоминает вопрос: «Почему в разговорных языках есть слова?».

— Джеймс Андерсон
источник

Просто добавлю, что если вам нравится внешний вид APL, но вы не хотите покупать новую клавиатуру, то J - это то, что нужно.

— AakashM

0

Основная причина в том, что и людям, и компьютерам легче разбирать. Устранение неоднозначности сложного языка без ключевых слов потребовало бы много символов в качестве синтаксиса, и это было бы массово и излишне запутанно. Это намного легче читать, functionчем $!{}. И контекст не решает всех двусмысленностей.

— DeadMG
источник

1

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

1

@Jarrod Roberson: Леонардо да Винчи: «Простота - высшая изощренность», Антуан де Сент-Экзюпери: «Кажется, что совершенство достигается не тогда, когда нечего добавить, а когда нечего отнять».

— Джорджио

1

@Jarrod: Все многозначительно выразительные компьютерные языки сложны.

— DeadMG

1

@DeadMG: Схема очень проста и в то же время очень выразительна. К сожалению, насколько мне известно, в нем нет стандартизированной библиотеки.

— Джорджио

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