OberonCore

Не надо пытаться делать короткие идентификаторы.
Так и сделай ИЛИЕСЛИ, пусть длинно, но понятно!

Хорошо) Первое существенное замечание по форме)
Кто ещё за ИЛИЕСЛИ?))
Я бы ещё присмотрелся к форме ИНЕСЛ -- ИНАЧЕ ЕСЛИ. Тут по логике оно поближе будет?..
ИЛИЕСЛИ, имхо -- длинно получается.

ДЕК ИНК — кальки с английского, тогда уж используй УВЕЛИЧ УМЕНШ или ДОБ ВЫЧ

Как у Федора Васильевича, кстати?

ДОБ и ВЫЧ -- вот это годный вариант. Принимается!))

Ещё какие мысли будут?)

Позвольте поинтересоваться, топикстартер, какую задачу решаем?
Одной строкой, если можно.

Сейчас это больше похоже на троллинг.

UTF-8 - стандарт де-факто. Если не работаете на рынках с иероглифами (там надо UTF-16) и заявляете о кросс-платформенности, то будьте добры поддерживать работу в UTF-8. Все практически используемые системы и их консоли спокойно работают в Utf-8, не говоря уже о любых редакторах.

Лексер для многобайтной кодировки не такой уж и сложный, если мы говорим не о теоретической реализации, а о практической. Пробельных символов реально немного, порядка 20 штук (я понимаю, что их больше, но вы навскидку сможете сказать, как вводится, скажем, полукруглая шпация с клавиатуры и ее код?)

Я не участвовал в дискуссиях о переводе на русский язык идентификаторов и ключевых слов, не могу высказаться ни за, ни против. Но один довод у меня все же имеется. Вас не смущает, что математические тексты используют и греческий, и латинский и еще Бог знает какие алфавиты, а не только (столько?) русский. Это использование символического аппарата дает существенное сокращение семантики. Когда я вижу в тексте VAR, мне не надо знать, как это переводится или расшифровывается. Я знаю, что под этими буковками должны идти переменные. Сделайте русскоязычные идентификаторы, пускай будут. Но ключевые слова и устоявшиеся операторы пусть будут на английском, чем плохо то? Просто опорные, реперные если хотите, точки.

Решаемая задача #1 : освобождение ресурса мозга от перевода смыслов с одного языка на другой. При переводе смыслов происходит неизбежное смещение, и как следствие -- снижение качества кода. В личном разделе Ткачёва "Словарик" почитайте до конца. Станет более понятно.
Решаемая задача #2: никакие РЫНКИ мне не интересны по определению. Впрочем, как и индексы цитирования, научные бананы, и как следствие: мне не нужна научная смелость или сильная позиция в научной стае)) Речь идёт о предоставлении инструмента который может выполнить поставленную задачу здесь и сейчас. Это прекрасно, что сразу у Вас появляются мысли о мировом масштабе, но нет.
Поэтому. следствие #1 из решения #2: кодировка никак не влияет на смыслы, если это русская кодировка. И уж тем более, способность писать исходный текст на английском языке. Просто берите и пишите VAR. Кто мешает-то?))
Вы внимательно прочитали прилагаемую документацию?))
И следствие #2 из решения #1: я выше написал, что попробую что-то придумать с кодировкой при +1 голос за изменение кодировки. Вы в курсе, что ВСЕ программы под Windows пишут в консоль в cp866? И тут ради одного калечного компилятора я кодировку консоли поменяю во что-то другое! Все остальные программы закончат нормальный читаемый вывод?! Мне кажется, это очень спорное решение, или я ошибаюсь?
И следствие #3: я уже написал, что можно все исходники сохранить в UTF-8 (если это так надо), и компилятор должен собраться! (ещё и модно) . Поддержка русского языка сломается, но английский он будет переваривать влёт!

Что касается математики/физики, которые используют греческие/латинские буквы -- это, простите, другая кафедра. Мне за 24 года, что я имею дело с компьютерами не довелось НИ РАЗУ увидеть собственными глазами использование в тексте программ греческие буквы. А вот латинские -- сколько угодно. Что какбэ намекаэ, что русский язык в программе -- это не менее полноценный эквивалент английского, с учётом адекватной передачи смыслов.

В качестве аргумента, могу привести вот это: в тексте компилятора есть функция getvar. Попробуйте угадать, что она означает? А она означает "вернуть размер стека в байтах"!!! Вот это реальный, мощный троллинг!!!)))

То есть ВЗЯТЬПЕР() будет понятнее, я правильно понимаю?
С сохранением семантики!

Неправда. Почти все программы под Windows пишут в консоль в текущей кодировке.

Странная логика в постановке задачи и попытке ее решать. Зачем тогда все это? Кто потребитель / пользователь?


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

Спасибо. Зачем это здесь? (* все тут в курсе, на всякий случай. Забавно, и на этом всё *)

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

Кросс-платформенность важна для купи/продай. НЕЧЕГО ПРОДАВАТЬ. И НЕЗАЧЕМ. Вот когда хоть что-то будет, кроме такого милого эксперимента -- вот тогда можно о чём-то говорить.

Итого, из 20 сообщений -- два по форме и половина одного по сути. Хм... На мой взгляд, ситуация близка к катастрофе))

Правильное название процедуры, Димыч, будет:
СтэкРазм_Получ():РАЗМЕРБАЙТ;

Почувствуй разницу.

Валяется у меня в старых заметках вот такой отрывок с какого-то форума (не то Delphikingdom, не то еще откуда-то. Автор тоже утерялся, может, кто-то вспомнит):
------------------------------------------------------------
Для русских программистов англоязычные ключевые слова скорее благо чем зло. Почему?
Если встречаешь слово, например, ПРОЦЕДУРА, то к нему у нас прилеплено в сознании много чего — типа "неприяная процедура", "процедура удаления зуба" и т.п… — мало ли какой опыт жизненный у человека был. Все эти ассоциации хочешь-не хочешь, а подымаются из памяти, когда читаешь текст и так или иначе засоряют пространство сознания вещами, не имеющими отношения к делу. С английскими ключевыми словами бытовых ассоциаций у русского человека нет или почти нет, поэтому к ним относишься сразу как к знакам (иероглифам, в каком-то смысле) именно с тем смыслом, который они имеют в языке программирования, а не в жизни. От этого восприятие должно быть легче и соответственно мышление — быстрее. IMHO — так оно и есть.
При этом обратите внимание: Вирт — швейцарец, по английски говорит классно, но язык этот для него не родной. Как и для его студентов, для которых он, собственно и языки придумывает. Потому для него как раз хорошо ипользовать BEGIN/END — легко запомнить. Сами же американцы, как иногда кажется, из кожи вон лезут, чтобы избежать употребления реальных слов в программных текстах в качестве ключевых. Сишный синтаксис, который активно переиспользуют и в Java и в C# — по-моему тому хорошее подтверждение.
------------------------------------------------------------

Почувствовал, проникся. Это ж реинкарнация Глагола -ГЛАГОЛ В2, или лучше Сказ-Р и пусть весь мир охнет

Прекрасный комментарий, Кемет! Концептуальный! Глубокий!)) Практически все твои фразы исполнены логики и смысла, о наш Великий Кормчий!))

Не смею требовать от тебя ещё более развёрнутых ответов!)) Ты и так уже почтил честью эту ветку своею бескрайною мудростью!)))

По предложению Ивана заменил ДЕК на ВЫЧ и ИНК на ДОБ.

В описании КП/О7 встречается такая форма записи:
INC(v)
INC(v, 2)

Если в первом случае INC вполне логичен, то во втором случае -- это уже что угодно, но только не инкремент. Так что, находка Фёдора Васильевича куда более адекватна.
Может быть, я не знаю каких-то тонкостей английского языка, но прямая передача смысла через английский эквивалент откровенно неудачна. Николай Вальтерович, ничего личного, это трудности перевода))

А глубже не осмысливали? На тему нужно ли INC вообще, и не стоит ли избавиться от частных случаев
a := a + 1

Или такой вариант - "+:=" рассматривали? По-моему, более понятно, чем ДОБ.

Или отказаться от сокращений и писать честно ДОБАВЬ

"+:=" - привет криптосинтаксису
Альтернатива "ВЫЧ" "ДОБ" - "УВЛЧ"(увеличить), "УМНШ"(уменьшить); а вообще
v := v + _сколько_надо; (* и никаких сусликов *)

От себя лично: хотелось бы компилятора для ARM-mode (тот который не Thumb, Thumb2).

Вариант с "+:=" не рассматривается, как семантически бессмысленный и вредный.
ДОБАВЬ длиннее в два раза. Именно поэтому INC у Вирта, а не INCREMENT -- это длиннее в ТРИ РАЗА.

Чтобы писать ДОБАВЬ должен быть ещё один оператор, похожий на ДОБ. Нет таких, а значит не нужно.
ДОБ() необязательно, но это фактически прямая машинная инструкция. И первая, и вторая. Скажем так: мусорок, с которым можно мириться.

Одна из задач разделить: анализатор - построитель AST - сборщик кода.
Идея подключить построитель кода для ARM есть. Тем более, что Александр, я надеюсь, будет не против.
По поводу "+:=" уже высказался выше, и по сути согласен. ВЫЧ и ДОБ -- тоже отписал, позиция похожа.