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. существуют ли языки, не калькирующие этот маразм?

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

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

Lincor
() автор топика

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

newKingOfTheBlock
()

нужно еще ограничение на запрещение писать код некоторым товарищам встроенным в ЯП

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

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

Lincor
() автор топика

Это и правда идиотизм. Но зачем постить его на ЛОР? Вместо этого можно было бы почитать книг по основам ЯП и в будущем казаться умнее.

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

эта конструкция тоже должна быть валидной! даже несмотря на то, что она бессмысленна — зачем приравнивать переменную самой себе?

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

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

Unicode4all ★★★★★
()

Если бы таких ограничений и не было, всё равно в гайдах по стилю прописали бы правила, и начинающих программистов били бы линейками по рукам за такой говнокод. А так сам компилятор предостерегает тебя от написания нечитаемого, неподдерживаемого говна. Тебе perl понравится, с его $_, $., $,, $$ и $# всякими.

amomymous ★★★
()

Напиши нормальный компилятор для такого бреда, а потом поговорим...

Я писал для C урезанный, там еще можно...

А Ç++ это вообще жесть жестянная со всем этим синтаксическим сахаром и прочем. У меня визуальный подчеркиватель netbeans блюет всеми цветами радуги на валидный код.

fornlr ★★★★★
()

маразм

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

Debasher ★★★★★
()

в выражении ; = 0; ровным счётом никакого труда не составляет определить, что ; — это, блджад, имя переменной, просто по расположению этого символа.

По какому расположению? Ты в курсе, что ;;;;; — валидно в C? Что перевод строки не обязателен?

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

По какому расположению?

очевидно же: по тому, что это lvalue в операции присваивания.

Ты в курсе, что ;;;;; — валидно в C? Что перевод строки не обязателен?

конечно в курсе, я сам так иногда пишу. и что дальше?

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

в 1958 году распарсить идентификатор с пробелом ни у кого сложностей не составляло

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

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

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

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

Ну, например, Io, там почти вообще нет ограничений. Лиспы некоторые, тикль.

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

очевидно же: по тому, что это lvalue в операции присваивания.

А может, это не операция присваивания, а переменная с именем «=».

Nervous ★★★★★
()
int ==0, ===1,<=2,<<=3,<==4,<===5;
cout<<=====||====<<||<====;

Какой результат?

Quickern ★★
()
Последнее исправление: Quickern (всего исправлений: 1)

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

Пруфы будут, или как это обычно для development, мысленный поток дерьма вместо треда?

ровным счётом никакого труда не составляет определить

Сделай свой язычок и определяй, сколько влезет.

Deleted
()

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

thesis ★★★★★
()

Я не понял, анонiмус что-ли тебя покусал? Откуда столько тупняка?

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

очевидно, это надо парсить как присваивание значения 0 переменной "return ;". а вот это:

return;
return ; = 0;
следует парсить как «возврат из функции и затем (когда, лол?) присваивание значения 0 переменной "return ;"».
или нет. подождите-ка...

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

короче всё ясно, нереально это парсить. понял после return; return; = 0;, где нельзя отличить, где кейворды, а где начинается и заканчивается имя переменной. выходит, какие-то пределы всё таки должны быть.
благодарю x3al и извиняюсь за тупняк.

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

А обратная сторона медали в том, что не-дебилам становиться невыносимо прогать на этом патриаршьем говне. Но истиные мотивы «патриархов» на самом деле, не в этом, а в том что так проще пейсать езыки. Если пипл хавает, зачем писать лучше? Тем более эти ваши карриганы с ричами вряд ли и смогли бы.

newKingOfTheBlock
()

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

Vala?

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

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

setSlot(";", 1)
getSlot(";") println
setSlot("return", 1)
getSlot("return") println

block(x, return writeln(x + 1); "I will never be shown" println) call(1)
1
1
2

Парсят же люди как то?:)

Что касается си, там все ясно, но вот в JS, например, кейвордная параша реально напрягает, там она совершенно лишняя:) А в пистоне этого говна, кажись, еще больше.

newKingOfTheBlock
()

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

Common Lisp, Scheme, Tcl. Там ограничения минимальны.

hateyoufeel ★★★★★
()

ровным счётом никакого труда не составляет определить, что ; — это, блджад, имя переменной

Нужно новый тег вводить - идиот.

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

Когда это инструкция процессора ret стала процедурой?

return - это вам не ret

compile-time operator

просто оператор (или операция)

anonymous
()

зачем так сделано?

Потому что всем наплевать на двух с половиной педантов, ратующих за непротиворечивый синтаксис в никому не нужных corner cases и излишне stateful парсеры. Как видишь, сишкоподобные языки отъели огромную нишу и до сих пор не собирается её отдавать вопреки подобным проблемам.

L29Ah
()

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

buddhist ★★★★★
()

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

Miguel ★★★★★
()

основном регулярна

Иди почитай, что это значит.

просто по расположению этого символа. ошибка на return = 0; — это вообще позор, неужели так сложно отличить переменную от ключевого слова?

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

odd =: #~2&|
even =: #~0:=2&|
anonymous
()
Ответ на: комментарий от Lincor

я сам так иногда пишу.

ну и дурак

anonymous
()
int x;; // переменная x или переменная x;?
Waterlaz ★★★★★
()
  1. про пробелы: имхо, правильно, затрудняет чтение кода. если идентификатор без них, выглядит хреново. например:
    my very long variable = another long variable + a bit shorter variable.a field with very very long name + short variable;
    // читабельнее, чем
    my_very_long_variable = another_long_variable + a_bit_shorter_variable.a_field_with_very_very_long_name + short_variable;
    

    а остальные символы — по разным причинам. например:

    x = a/b*c; // expression "a / b * c" or variable "a/b*c"?
    
    ...
    
    int return = 228;
    
    void f(){
        global_variable = another_global_variable;
        if (global_variable == 1488) return; // a variable or a keyword?
        global_variable = third_global_variable;
    }
    

  2. в некоторой мере лишпики, там можно называть символы почти как угодно. но твоих любимых пробелов в названии и там нет.
f1u77y ★★★★
()
Ответ на: комментарий от newKingOfTheBlock

Иди ты нахуй, пидор, со своим js и полиморфизмом. Идиот

anonymous
()

Мне сложно читать код автора, так что все правильно сделали.

hlebushek ★★
()
racket@> (define return "return")
racket@> (define \; ";")
racket@> (define an\ int "an int")
racket@> return
"return"
racket@> (set! return 0)
racket@> return
0
racket@> \;
";"
racket@> (set! \; 0)
racket@> \;
0
racket@> an\ int
"an int"
racket@> (set! an\ int 0)
racket@> an\ int
0
lazyklimm ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.