LINUX.ORG.RU

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

 , , ,


1

1

мой баттхёрт от мейнстримных языков программирования продолжается. сегодня я подумал о сабже и взбугуртил так, что мне совершенно расхотелось писать на C (но всё равно пришлось).
возьмем, к примеру, такой код:

int return; // переменная с именем return
int ;; // переменная с именем ;
int an int; // переменная с именем an int
return = 0; // error
; = 0; // error
an int = 0; // error
, который не является валидным. и тут появляется вопрос: а ПОЧЕМУ он не является валидным?
грамматика C в основном регулярна, в выражении ; = 0; ровным счётом никакого труда не составляет определить, что ; — это, блджад, имя переменной, просто по расположению этого символа. ошибка на return = 0; — это вообще позор, неужели так сложно отличить переменную от ключевого слова? ну а про идиотию с запретом пробела в идентификаторах даже и говорить не хочется, особенно учитывая, что в Алголе-58 это было разрешено, а в потомках выпилили — нинужна, видите ли!
точно такая же петрушка имеет место и в других популярных языках: C++, Java, педон и остальная пыхоплеяда... хорошо хоть запрет иметь идентификаторы с одинаковым именем, но разными типами потихоньку уходит в прошлое (и то в основном только для функций).

у меня, собственно, остаётся только два вопроса:

  1. зачем так сделано?
  2. существуют ли языки, не калькирующие этот маразм?

Ответ на: комментарий от Kuzy

А что конкретно не устраивает?

Вот мы пишем сначала по предикату на каждое выражение

self-evaluating?

lambda?

quoted?

application?

и так далее

в SICP, допустим, дается такое, типо, определение


(define (self-evaluating? expr)
  (cond ((number? expr) true)
        ((string? expr) true)
        (else false)))

Но это ведь в некотором роде демагогия:) number? и string? уже есть на уровне языка, а если нам нужен свой синтаксис? значит у нас должен этому предшествовать синтаксический разбор. Допустим, строка у нас будет не лисповская, а тиклевская, что мы будем делать? Можем например, по регулярке опрределить /\{[^}]\}/ строку. Дальше то же самое, только сложней. Соответственно, все начинается с разбора, от него идут предикаты, а дальше по предикатам мы определяем, во что мы будем транслировать каждое из выражений, и какова будет промежуточная обработка. Что не так?

newKingOfTheBlock
()
Ответ на: комментарий от newKingOfTheBlock

(define mydefine define)

Ну, во-первых это уже невалидно by design(special forms, вот это всё), и я подозреваю, что ты это знаешь. А (define define 1), тем не менее, работает как и просил ТС.

lazyklimm ★★★★★
()
Ответ на: комментарий от lazyklimm

хотя конечно, можно обойти использованием оставшихся sf, но тоже неспортивно (потому что все не обоидёшь)

lazyklimm ★★★★★
()

Чтобы Си не был похож на Перл

Ваш КО

d_Artagnan ★★
()
Ответ на: комментарий от newKingOfTheBlock

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

И правильно делают! Когда один погромист пишет в одном стиле, второй - во втором, а третий - вообще без стиля и т.д. - код становиться абсолютно нечитаемым.

Ты вообще кроме наколенных поделок что-то писал, в крупных проектах работал?

drull ★☆☆☆
()
Ответ на: комментарий от x3al

Я бы тоже не называл возможность вставить себе кляп в рот и избить себя кожанной плеткой по яйцам чем-то хорошим. А вот newKingOfTheBlock видимо такое нравится.

drull ★☆☆☆
()
Ответ на: комментарий от newKingOfTheBlock

Лол, в sicp нету синтаксиса вообще, там сразу s-expr-ы интерпретируются.

Штука, которая делает из строчки s-expr (в случае лиспа) называется парсер. Неважно, в каком виде была исходная строка, это может быть какой-нибудь json, например. На выходе парсера будет s-expr-а. Дальше, ты можешь делать с ней что угодно, но все это не будет относиться к синтаксису (вот это вот в sicp есть).

Kuzy ★★★
()

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

blexey ★★★★★
()

грамматика C в основном регулярна

ахахах лол

anonymous
()

Я вот сейчас как раз разбираюсь с подходом к идентификаторам в языках программирования. Поддержка Юникода в идентификаторах тащит за собой ещё один вопрос, про который вообще часто забывают, но который приходится как-то решать: нормализация.

В плане, «й» (U+0439) и «й» (U+0438 U+0306), «ō̧» (U+006F U+0304 U+0327) и «о̧̄» (U+043E U+0327 U+0304), «ℋ» (U+210B) и «H» (U+0048), «f» (U+0066) и «f» (U+FF46), а также куча других вариантов — это всё разные идентификаторы или одинаковые? А если они упоминаются в строке? А если из-за визуальной неразличимости или различимости будет дыра в безопасности? А если идентификатор используется для поиска по файловой системе?

Регистронезависимых уродцев языков это касается вдвойне и приносит ещё кучу специфичных проблем.

ilammy ★★★
()
Ответ на: комментарий от Lincor

И что я там должен увидеть? Тот же UAX#31 предоставляет целый веер вариантов (включая вариант «делай что хочешь, только задокументируй»), из которых приходится выбирать.

ilammy ★★★
()
Ответ на: комментарий от ilammy

Непонятно, в чем проблема. Идентификаторы - это же слова, они для человека. «йуг» и «йуг» для читающего одно и то же?

Регистронезависимых уродцев

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

anonymous
()
Ответ на: комментарий от anonymous

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

В общем, появляется соблазн просто забить, приняв или «нельзя ничего, кроме ASCII», или «если это не ASCII, то пиши что хочешь, я всё равно буду тупо сравнивать байтики».

Это всё к вопросу, почему разработчики языков программирования не позволяют называть идентификаторы как угодно. Если наплевать на корректность или обратную/прямую совместимость, то всё естественно и элементарно.

ilammy ★★★
()

Это сделано для упрощения разбора текста программы.

Legioner ★★★★★
()

ПЛ/1 когда-то был самым что ни на есть мейнстримом, и там можно было писать такие извращения с идентификаторами

dave ★★★★★
()
Ответ на: комментарий от dave

да тут вообще выясняется, что в старых языках (Алгол, FORTRAN, PL/I, BCPL etc.) разных ограничений было на порядок меньше.

Lincor
() автор топика
Последнее исправление: Lincor (всего исправлений: 1)

Потому что неявность.

int i = 5, + = 10;
int j = ++i;

Что будет в j?

anonymous
()
Ответ на: комментарий от Lincor

И в итоге оди сгинули. К чему бы это?

anonymous
()

Хаскель не пробовал изучать?

rupert ★★★★★
()

идентификатор |почему в языки программирования вводят искусственные ограничения для идентификаторов?| на Common Lisp.

тред не читал.

anonymous
()
18 ноября 2015 г.

переменная с именем ;

Это пустой оператор.

ТС — идиот.

</thread>

contra_sperm_spero
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.