Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Описание языка

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

Правила языка записаны в форме, напоминающей БНФ или входной язык генератора распознавателей YACC/Bison. Разница с БНФ ззаключается в меньшем количество служебных символов и в несложной раскраске, облегчающей восприятие. Правила являются, в отличие от традиционной БНФ, гипертекстом: любой нетерминальный символ, встречающийся в правой части правила, является гиперссылкой, по которой можно перейти в то место, где это правило описано, то есть встречается в левой части правила.

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

Условные обозначения


 Это комментарий к правилам 

 [ нечто ] — встречается 0 или 1 раз

 { нечто } — встречается 0 и более раз, число повторений ограничено 
 длиной лексем

 { нечто }1 — встречается как минимум 1 раз, число повторений
 ограничено длиной лексем

 нечто | нечто   — одно из перечисленных

 ( нечто | нечто )   — одно из перечисленных

 Терминальный символ  — символ, входящий в алфавит языка

 Ключевое слово  — ключевое или зарезервированное слово

 Нетерминальный символ  — описание правила языка
   (слева от знака равенства)

 Ссылка на нетерминальный символ — ссылка справа от знака
   равенства на ранее определённое правило. По ссылке можно
   перейти

 Контекстная зависимость  — зависимость от предыдущего
 или последующего констекста, не имеющая формального описания

Примеры


Двоичная цифра
 
 =  0  |  1 

Десятичная цифра
 
 = Двоичная цифра

 |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9 

Шестнадцатиричная цифра
 
 = Десятичная цифра

 |  A  |  a  |  B  |  b  |  C  |  c 

 |  D  |  d  |  E  |  e  |  F  |  f 

 |  А  |  а  |  Б  |  б  |  Ц  |  ц 

 |  Д  |  д  |  Е  |  е  |  Ф  |  ф 

Опубликовано: 2012.09.25, последняя правка: 2023.04.24    09:28

ОценитеОценки посетителей
   ████████████████ 8 (36.3%)
   ██████████ 5 (22.7%)
   ████████ 4 (18.1%)
   ██████████ 5 (22.7%)

Отзывы

✅  2015/02/19 23:35, rst256          #0 

Как насчет начать с философии, как у Питона?

Мне кажется использование внешнего имени функции в рекурсивном вызове не есть гуд:
int foo0(int bar){ //must get 100-bar recursive calls
if( bar > 100 ) return 0;
return foo0(bar+1); /* => return me(bar+1); */
}

int fooO(int bar){ //must get 200-bar recursive calls
if( bar > 200 ) return 0;
return foo0(bar+1); /* => return me(bar+1); */
}

✅  2015/02/20 11:11, Автор сайта          #1 

А какие есть «противопоказания» у вызова функции, когда имя вызываемой и вызывающей функции совпадают? Какие недостатки в этом кроются? В чём будет выигрыш, если функция будет вызывать саму себя по какому-то ключевому слову типа «me»?

✅  2015/02/22 06:16, rst256          #2 

А какие различия между х=0 и х=NULL? Именно по таким же соображениям и рекурсия я считаю должна иметь явный вид. К тому же человеку не надо будет менять код внутри функции при изменении её имени. А так же к такому вызову в последствии легче будет приделать, если надо, другой функционал. В зависимости он парадигмы, конечно. Например, вызов «me» также как точка доступа к переменным, замкнутым на уровне только этой рекурсии.
me.count++;me(...)
а не
func(.., count+1)
а нюансы изоляции этих переменных задача компилятора — тривиальная задача, если язык обладает встроенными конструкциями для работы с потоками. Не говоря у же о том, что хорошо проработанный компилятор даже сможет развернуть такое в нерекурсивный код при указании, например, специального атрибута или автоматически, если возможно (но я предпочитаю указывать явно)

✅  2015/02/22 16:42, Автор сайта          #3 

В чём-то Ваша идея логична, конечно. Хотя даже в Haskell, где рекурсия сидит на рекурсии и рекурсией погоняет, такого нет. Но Вы, конечно, ведёте речь о прямой рекурсии, а не косвенной.

✅  2015/03/15 08:27, rst256          #4 

Ну даже не знаю насчет haskell, а для него есть статические анализаторы кода, потому что я не нашел. На нем написанных целую кучу нашел, а для него нет.
Может хорошему языку они и не нужны?

✅  2015/06/26 14:37, Иван          #5 

Мое предложение не играет роли, но, как мне кажется, лучше уж тогда зарезервировать слово «self», а не «me».
function factorial(n) {
... self(n - 1) ...
}

✅  2015/06/26 18:45, Автор сайта          #6 

Для начала надо решить, нужно ли вообще рекурсивный вызов как-то особо выделять. А придумать ключевое слово — это уже технический момент. Кстати, в некоторых языках «self» аналогичен «this» C++.

✅  2016/01/25 21:41, Сергей          #7 

Ребята, привет! А на каком, собственно, этапе продвижение проекта? Честно скажу, UI этого сайта — непонятен и лично для меня не способствует участию в обсуждении соответствующих вопросов. Если проект жив, то https://vk.com/grechkosergeyolegovich или sergio.yacovlev@yandex.ru. Готов принять активное участие в проекте, есть достойные соображения.

✅  2016/01/26 18:28, Автор сайта          #8 

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

✅  2016/07/25 09:06, Michael          #9 

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

✅  2022/08/01 23:04, some          #10 

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

✅  2022/08/02 23:59, Автор сайта          #11 

Есть масса проектов, которые меня «опередили». Мне же не хотелось бы работать над языком, который не мог бы предложить ничего нового. Да, некоторых это не смущает. Именно поэтому список языков, на который сослался, так велик. Если Вас разочаровывает скорость появления нового языка, который тут анонсирован, то попытайте своего счастья в собственной разработке. Может, у Вас получится.

✅  2023/05/17 21:39, Вежливый Лис          #12 

Как сделать максимально плохой язык — http://plana.mybb.ru/viewtopic.php?id=2086
1) динамическая типизация
2) выделять и не освобождать память
3) рекурсивный спуск
4) словари вместо массивов
5) структуры, поля и операция обращения к полю по имени
Кажется, что время создания самого языка (но не программ на нём) будет минимально

✅  2023/05/18 00:06, Автор сайта          #13 

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

Если какие-то пункты можно понимать двояко, то рекурсивный спуск — это точно не про создание языка. Это исключительно про реализацию компилятора. А перечисленные выше пункты местами смахивают на классификацию Борхеса.

Метод рекурсивного спуска — это не про плохой или хороший язык, это про один из методов реализации компилятора. Этот метод имеет как плюсы, так и минусы. Есть хороший материал на эту тему: «Рекурсивный спуск в современных компиляторах», хотя и не исчерпывающий. Из плюсов я бы отметил
  • возможность реализации нетривиального синтаксиса,
  • возможность выдачи максимально детальных сообщений об ошибках,
  • возможность держать всё в своих руках и не зависеть от сторонних технологий типа YACC (да, в эпоху санкций это актуально).
Минусы тоже есть, я их могу перечислить, если хотите. Сам метод нельзя считать «отсталым», достаточно посмотреть на список компиляторов, построенных этим методом: GCC, Clang, RustC, Go, Swift, Kotlin, D и т. д.

Процитирую раннюю статью:

вот другое мнение, мнение практика, который не только разрабатывал компиляторы (Zortech C++, D), он ещё и автор языка D. Это Уолтер Брайт. Из интервью с ним:
Вопрос:
Еще раз касательно вашего вышесказанного комментария про ошибки программирования, анализаторы YACC LALR нелюбимы за получаемые сообщения типа «где-то тут есть ошибка, но я не уверен, где именно». Ruby особенно плох в этом плане — вы хотите сказать, что D использует лучший «мешок фокусов» чем YACC?
Уолтер Брайт
Я никогда не использовал YACC; все сделанные мной лексеры и анализаторы полностью самодельные. Хорошее диагностирование ошибок, хорошее восстановление после ошибок для того, чтобы анализ мог быть продолжен без генерации моря ложных сообщений, — всё это в большей степени искусство, чем наука.

Что же касается остальных пунктов, то зачем им Ваше внимание? Вы же не собираетесь создавать какой-то язык или писать компилятор. Значит, можно просто пройти мимо этой темы.

Ну не нравится Вам динамическая типизация. Но как это скажется на судьбе языков — как настоящих, так и будущих? Если Вы не создаёте языки и компиляторы с учётом изложенных пунктов, то слова так и останутся словами.

✅  2023/05/18 12:06, MihalNik          #14 

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

Не все так просто. Язык связан с особенностями работы вычислительных устройств — в нашем случае людей и ЭВМ.
Физические ограничения никто не отменял. Комбинаторная сложность может затруднить создание языка, компилятора, время компиляции, изучения или написания программ.

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

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

Из плюсов я бы отметил возможность реализации нетривиального синтаксиса

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

максимально плохой язык — http://plana.mybb.ru/viewtopic.php?id=2086
1) динамическая типизация
2) выделять и не освобождать память
3) рекурсивный спуск
4) словари вместо массивов
5) структуры, поля и операция обращения к полю по имени
Кажется, что время создания самого языка (но не программ на нём) будет минимально

Это не обязательно так. Например, с 1-2 и 4 скорее многие программы писать часто быстрее, но 4 реализовать в языке может оказаться сложнее. Скорость написания программ в общем случае будет зависеть от возможности использования готового.
Т.е. у транспиляторов в популярнейшие ЯП или интерпретаторов на них будут несомненные преимущества.

✅  2023/05/19 22:18, Автор сайта          #15 

Язык связан с особенностями работы вычислительных устройств — в нашем случае людей и ЭВМ.

Вообще-то все позиционируют свои языки как универсальные, машинно-независимые, подчёркивают их всеядность и независимость от «особенностей». Помните девиз Java: «работает везде»? LLVM тоже была сделана с целью работать везде и поддерживать эту всеядность тем компиляторам, которые генерируют код в LLVM. Язык Си (без плюсов) является чемпионом по числу платформ, на которых он работает. А ведь когда-то говорили о его низком уровне и машинной зависимости. Да нет же, Си вполне успешно абстрагируется от машины. Конечно, есть машинно-ориентированные языки, но они явно об этом предупреждают.

Комбинаторная сложность может затруднить создание языка, компилятора,

В своё время Алгол-68 долго существовал только на бумаге, потому что оказался настолько сложным, что разработка компилятора для него заняла годы. Это ещё раз напоминает о том, что создание языка и разработка компилятора — разные задачи.

Язык вполне может специально создаваться под рекурсивный спуск

Опять же — никто не декларирует привязанности языка к какой-то определённой схеме разбора. Да, бывают языки, которые проще воплотить в компилятор определённым способом (например, «подглядывая» в тетрадку к соседу по парте в Гитхаб 😅). Но это не отвергает возможности сделать это по-другому, может более трудоёмко или медленнее. Те же виртовские языки ввели моду на синтаксические диаграммы, намекая на способ реализации. У Кладова в AL-IV есть эти диаграммы. Но это не ставит крест на остальных методах: они вполне применимы и эффективны в отношении виртовских языков.

Рекурсивный спуск — простой, но ограниченный механизм.

А вот тут хотелось бы поподробнее с приведением ссылок на авторитетные источники, в чём же эта ограниченность. Я же процитирую статью «Рекурсивный спуск в современных компиляторах»:

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

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

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

Метод рекурсивного спуска даёт почти полную свободу рук, в отличие от табличных методов разбора. Когда мне надо было сделать разбор длинных комментариев, то это легко решилось императивно с хранением состояний. А вот как посчитать количество звёздочек регулярными грамматиками — декларативным языком без хранения состояний — это большой вопрос. И так во многом. Так что сложность у рекурсивного спуска варьируется в широких пределах.

Возможно, отступление от LL(1) или LL(k)-грамматик в сторону контекстно-зависимых лишает метод разбора права называться рекурсивным спуском. Но он ведь всё равно сверху вниз? Да. Всё равно рекурсивный? Да. Ну тогда назовём его расширенным методом рекурсивного спуска.

Давайте рассмотрим такую грамматику: идущие рядом символы преобразуются в другие символы по такому правилу: берутся коды символом слева, складывается, а потом получившаяся сумма раскладывается на множители в порядке их возрастания. Например:
  !* -> 3,5,5
// символ с кодом 33 и символ с кодом 42;
// сумма кодов — 75;
// множители числа 75 — 3, 5, 5
Разве получится описать такую грамматику с помощью регулярных выражений или БНФ? (Миллион в студию тому гению, у кого это получится!) А вот разобрать это алгоритмически несложной функцией — запросто, на раз-два. Студенты справятся. На мой взгляд, метод рекурсивного спуска (с возможной поправкой расширенный) ограничен алгоритмической разрешимостью и фантазией разработчика. Но Вы имеете право на своё мнение.

Что касается 5 пунктов, как сделать плохой язык, то похожая тема затрагивалась в «признаках устаревшего языка».

✅  2023/05/20 12:58, MihalNik          #16 

Опять же — никто не декларирует привязанности языка к какой-то определённой схеме разбора.

Декларируют. И не только для виртовских языков. Вот разработчик Котлина прямо сказал, что тернарного условного оператора нет, потому что его нельзя туда легко и удобно добавить. Да-да, язык местами прямо сделан под компилятор и во многом — под среду разработки. И разработчик Алфора тоже прямо писал, что его язык заточен под простейший текстовый редактор. А еще, о ужас, почти все ЯП во многом сделаны под клавиатуры, вплоть до конкретных раскладок тех или иных спецзнаков на них.

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

Это в теории. А в реальном времени для всего существует трудоемкость.

Возможно, отступление от LL(1) или LL(k)-грамматик в сторону контекстно-зависимых лишает метод разбора права называться рекурсивным спуском.

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

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

Наоборот, он ограничивает фантазию разработчика, которому приходится следить, чтобы компиляция занимала приемлемое время и памяти хватало. Еще раз — рекурсивный спуск плохо дружит с комбинаторикой, т.е. используя его вряд ли кто-то в принципе станет создавать ЯП, в котором, например, сотня вариантов истолкования большого исходника, идущая почти от начала, разрешается где-то к самому его концу. Хотя что такое сотня вариантов? Какие-нибудь 4 ветвления 2х2х5х5.

Это не значит, что способ какой-то плохой: он отлично подходит для каких-то языковых конструкций и не очень подходит для других. Исторически в популярных ЯП довольно мало несовместимого с этим подходом — они все ограничены весьма небольшими отклонениями от него. По существу нужно говорить о конкретных конструкциях, а не подходе вообще. Вон в Обероне все прекрасно укладываются в рекурсивный спуск и они есть почти во всех ЯП.

Но это не ставит крест на остальных методах: они вполне применимы и эффективны в отношении виртовских языков.

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

✅  2023/05/21 14:29, Автор сайта          #17 

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

Посмотрел в Википедии страницы Оберона, Паскаля, Котлина — ничего нет ничего про заточенность на определённые методы разбора. Видимо, это не является существенным моментом и им можно пренебречь. Кстати, я прикинул алгоритм, как распознать тернарное сравнение x < y < z и не перепутать его с бинарным. А вот как записать такое распознавание в БНФ — даже не представляю (может попробуете? с удовольствием посмотрел бы). Сдаётся мне, что это тот случай, когда простенький алгоритм удобнее формального определения.

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

Редкие языки заточены под что-то иное. С какими языками нельзя работать в текстовом редакторе?

почти все ЯП во многом сделаны под клавиатуры

О да, это так. Можно констатировать, что все языки машинно ориентированы: они заточены под конкретное оборудование — клавиатуру. Тут в логике Вам не откажешь.

Это в теории. А в реальном времени для всего существует трудоемкость.

Отсюда:

Андрей Хохлов, разрабатывая свой язык Context, для одних версий компилятора применял Flex и Bison, для других нет. На вопрос «как легче, с Flex и Bison или без них», он ответил, что особой разницы в трудозатратах он не заметил.

Но, думаю, генераторы компиляторов созданы не зря. Алексей Недоря, комментируя работу на своим языком Тривиль, пишет:

все таки, это 5-й проектируемый мной язык

Он начал работу, если не ошибаюсь, в декабре 22-го, а закончил в марте 23-го. Знание инструментария и опыт применения здорово ускоряют работу.

Рекурсивный спуск — это ручная работа. Она имеет большой разброс в качестве: может получиться шедевр, а может откровенная халтура. А генераторы компиляторов — это конвейер, обеспечивают более-менее стандартное качество.

Приведу аналогию: первый Pentium проектировался то ли в VHDL, то ли Verilog, то есть не вручную. Работал он на частоте 60 — 90 МГц. Примерно в это время DEC проектировала свой процессор Alpha и проектировала вручную. Это позволило учесть очень тонкие моменты типа взаимных наводок проводников на высоких частотах. В итоге процессоры Alpha работали на в два раза большей частоте при тех же технологических нормах. Дать ссылку не могу, давно это было.

А вывод такой: всегда есть конкурирующие варианты, и это хорошо.

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

Спору нет, но как для непростых языков сделать простой компилятор? Я уже приводил пример тернарного сравнения. Эта конструкция сложна для компилятора, а вот для человека она проста и потому желательна в языке.

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

Время компиляции для меня уже многие годы приемлемо, настолько выросла производительность компьютеров. И памяти всё больше и больше.

Они просто избыточны.

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

Подводя итог, скажу, что мнения изложены, услышаны и, возможно, в будущем в какой-то мере учтутся.

✅  2023/05/21 18:51, MihalNik          #18 

С какими языками нельзя работать в текстовом редакторе?

С любыми в нетекстовом формате. Например, у Лаптева такой точно был. И можно — не значит удобно. А степень удобства может быть разной. С Питоном удобнее чем с Лиспом каким-нибудь, если рассматривать простейший инструмент без возможности подсветки синтаксиса, авторасстановки переносов и прочего.

Спору нет, но как для непростых языков сделать простой компилятор? Я уже приводил пример тернарного сравнения. Эта конструкция сложна для компилятора, а вот для человека она проста и потому желательна в языке.

Проблема не в компиляторе, а в концепции, в данном случае в понятии "тернарный оператор", которое не нужно. Чем "a<b<c" сложнее "a,b,c"?

Рекурсивный спуск — это ручная работа. Она имеет большой разброс в качестве: может получиться шедевр, а может откровенная халтура. А генераторы компиляторов — это конвейер, обеспечивают более-менее стандартное качество.

Генераторы требуют ввода не меньшего кол-ва информации. БНФ вообще избыточнее рекурсивного спуска, потому что варианты в ней неупорядочены. Оттого работать не наглядно и неудобно. Весь предел экономического эффекта у качества — миллионные доли копейки на разработчика. А значит, это теоретический мусор.

Но, думаю, генераторы компиляторов созданы не зря.

Как только люди бюджеты не осваивают.

Время компиляции для меня уже многие годы приемлемо

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

✅  2023/05/21 23:35, Автор сайта          #19 

Проблема не в компиляторе, а в концепции, в данном случае в понятии "тернарный оператор", которое не нужно.

Чем эта концепция не угодила? Она живёт во многих языках. В плохом не замечена.

Чем "a<b<c" сложнее "a,b,c"?

Тем, что это синтаксис прогибает под себя. Так можно и до Форта дойти. Ведь 2 2 + тоже ведь не сложно? И это не сложно, не правда ли?
 A B < IF D ELSE E ENDIF
Как только люди бюджеты не осваивают
Освоение бюджетов лучше обсуждать на других сайтах.

✅  2023/05/22 10:01, MihalNik          #20 

Чем эта концепция не угодила? Она живёт во многих языках.

Вообще не факт. Мало ли чего и где живет. В ЯП вообще навалом разного мусора. Даже в Оберонах. Да и внешний вид обманчив. Возможность записи a<b<c не означает наличия в языке отдельной концепции и реализации тернарного оператора сравнения, никто же никогда не говорит о тернарном операторе сложения, хотя запись a+b+c есть почти в любом императивном ЯП.

✅  2023/05/22 21:45, Неслучайный читатель          #21 

В Питоне есть тернарная операция сравнения — она в русле математической традиции. Тернарного сложения в языках нет, потому что оно делает то же самое, что и бинарное. А можно ли тернарное сравнение заменить бинарным? Допустим, сперва делаем бинарное сравнение чисел a и b, результат будет логического типа. А потом делаем бинарное сравнение логической переменной и числовой (c). Но это же ерунда получается — сравнивать кислое с пресным. Тернарное сравнение можно заменить бинарным, только понадобится дополнительная логическая операция:
a < b && b < c
Но в Питоне сделали короче. Наверное, время компиляции увеличилось. Но никто этого не заметил, раз его популярность растёт.

✅  2023/05/22 22:59, MihalNik          #22 

В Питоне есть тернарная операция сравнения — она в русле математической традиции.

В Питоне нет отдельной тернарной операции сравнения (как нет и в учебниках математики) — Питон переваривает цепочки сравнений произвольной длины:
a < b <= c < d

✅  2023/05/23 17:53, Неслучайный читатель          #23 

В последнем случае операция сравнения фактически обладает арностью 4. Имеет смысл говорить об одной операции, а не о нескольких бинарных, потому что у операций сравнения нет ни левой ассоциативности
 ( (a < b) <= c) < d
ни правой
 a < (b <= (c < d) )
в отличие от арифметических операций.

✅  2023/05/24 12:46, MihalNik          #24 

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

( (a < b) <= c) < d

ни правой

a < (b <= (c < d) )

в отличие от арифметических операций.

Что имеет смысл, а что нет — решать разработчику языка и/или компилятора. Язык, например, может существовать и только в виде последнего. А то, чего в нём не будет, можно считать притянутым за уши. Краткость — основной ограничитель среди бесконечного множества абстрактных теорий. Решит, что нужно понятие операторных цепочек, — и будет разбирать "a,b" "a<b<c" или "a+b+c+d" одной функцией с необходимыми параметрами, шаблонной или виртуальной. И какая-то другая система абстракций, в которой попытаются исходник истолковывать, может оказаться чересчур сложной, избыточной. А бывает и наоборот — захочет отдельный оператор неравенства для логических значений, к примеру, и все пользователи будут его отдельно учить и даже могут за всю жизнь не узнать про избыточность абстракции.

✅  2023/05/24 21:38, Неслучайный читатель          #25 

Что имеет смысл, а что нет — решать разработчику языка и/или компилятора.
Так и есть. Неоднократно встречал в том или ином виде такую мысль: «Что вы спорите, какой язык лучше? Сделайте себе свой. С каждым годом это сделать всё легче. Инструментарий для этого есть, литературы достаточно. Делайте, как считаете нужным. Вперёд!»

✅  2023/05/24 22:11, Ильдар          #26 

О рекурсивном спуске и скорости компиляции. Компилятор TinyCC в 9 раз быстрее GCC. TinyCC сделан, вероятнее всего, с помощью Flex и Bison, а GCC — рекурсивным спуском. TinyCC компилирует Си, а GCC — C++, куда более сложный язык. Это как бы подтверждает аргументы MihalNik — медленная компиляция рекурсивным спуском сложного языка. С другой стороны, у GCC на порядки больше пользователей, что подтверждает аргументы оппонентов :)

По теме рекурсивного спуска лучше сделать другую ветку форума и перенести обсуждение туда.

✅  2023/05/25 01:12, Автор сайта          #27 

По теме рекурсивного спуска лучше сделать другую ветку форума
Тут не форум, а несколько другой формат. Сделано как статьи и комментарии под ними. Делать комментарии к отсутствующей статье не есть хорошо. Что-то написать своё — пока нет достаточного количества того, чем хочется поделиться. Если у Вас есть что-то — пишите, Ваше авторство обязательно будет отмечено.
Делайте, как считаете нужным. Вперёд!
Пока что не у каждого программиста есть свой язык. Но это не точно :)

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

Описание языка

●  Философия языка

●  Правила языка: алфавит

●  Правила языка: строки, комментарии

●  Правила языка: скобки и их согласование

●  Правила языка: идентификаторы

●●  Правила языка: встроенные типы

●  Правила языка: числовые типы и числовые константы

●  Правила языка: строковые литералы

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/11/02 02:09 ••• Иван
Энтузиасты-разработчики компиляторов и их проекты

2024/11/01 12:11 ••• ИванАс
Русской операционной системой должна стать ReactOS

2024/10/28 00:00 ••• alextretyak
Продолжение цикла и выход из него

2024/10/27 21:54 ••• ИванАс
Новости и прочее

2024/10/27 14:01 ••• Автор сайта
О русском ассемблере

2024/10/19 23:12 ••• Автор сайта
Русский язык и программирование

2024/10/25 01:34 ••• Владимир
Оценка надёжности функции с несколькими реализациями

2024/09/29 23:40 ••• Автор сайта
Десятка худших фич C#

2024/09/29 13:10 ••• Автор сайта
ЕС ЭВМ — это измена, трусость и обман?

2024/09/22 21:08 ••• Вежливый Лис
Бесплатный софт в мышеловке

2024/09/05 17:44 ••• Автор сайта
Правила языка: алфавит

2024/09/04 00:00 ••• alextretyak
Циклы

2024/09/02 22:24 ••• Автор сайта
Постфиксные инкремент и декремент