Yoda писал(а):
Да, байт потерял, пардон. Это должно работать на принципах элементарной оптимизации. Если компилятор видит использование старших значащих разрядов (а после сложения этот разряд хранится в переносе, это компилятор обязан знать), он их просто использует в следующей операции.
Мне что-то не нравится, но я пока не могу понять, что именно. Могли бы Вы написать оператор сложения полностью правильно для int72 (на любом языке, который можно понять без лишних пояснений)? При этом, если Вы пользуетесь int128 для промежуточных результатов, то нужно описать и его.
Yoda писал(а):
Так ведь ТеХ использует plain-text в основе! Это и есть отказ от визуального представления в пользу текста. Визуальное представление получается в результате (условно говоря) компиляции текста в графическое представление.
Совершенно верно, однако есть визивиг (wysiwyg) редакторы для TeX, которые оставляют скрытым plain-text, лежащий в основе. (К сожалению, все известные мне визивиги для TeX обладают той формой школоподобия, при которой работать с ними (лично мне) неприятно). Над тем же думал и я, когда писал про внутренний и внешний форматы. Внутренний формат используется компилятором, а внешний - это визуальное отображение внутреннего. При этом будет ли это плагин к редактору, как предлагалось выше, либо что-то другое, сейчас это не важно. Пользователь может писать как на внутреннем формате, так и на внешнем. Оба формата следует продумать удобными. Я вообще подозреваю, что TeX такой именно потому, что раньше, в те времена, были только текстовые редакторы. Мыслить о быстрой и удобной графике никто особо не смел.
Yoda писал(а):
Когда будет ясно, что стремянка не упадёт, ей можно будет безопасно пользоваться.
Вы не ответили на мой вопрос о том, какие по-Вашему символы в UTF-8 следует считать устоявшимися. Или вопрос некорректен?
Yoda писал(а):
Именно так делает Python.
Да, я знаю, но данная идея пришла мне в голову до моего знакомства с Python, как и многие другие, впрочем. Хотя это даже приятно, что уже кто-то такое сделал.
Yoda писал(а):
Но здесь есть своя засада - символ табуляции!
Я предлагаю запретить символ табуляции и назначить на эту кнопку что-то другое в моём редакторе, а ещё считать данный символ синтаксической ошибкой. Ведь, например, в C++ многие символы будут синтаксической ошибкой, и если в новом языке добавить в этот список tab, то ничего по сути не изменится. Просто 9-й символ будет восприниматься таким же запрещённым, как, например, 31-й. В моём редакторе я бы даже сделал так, что tab раскрывается в ёмкое ругательное выражение большими красными буквами. Причём при каждом нажатии выдаются разные фразы : ) Я отказываюсь проверять программы своих учеников, если при открытии их в моём редакторе я вижу хоть одно неправильное выравнивание (неправильное - это не то же самое, что "не как у меня", это когда в одной программе отступы разные, не поддающиеся единому стилю оформления или какой-то другой простой логике, это почти всегда происходит, когда ученик использует tab). Я просто возвращаю программу на доработку. Ибо нефиг. И здесь я совершенно радикально настроен против табуляции как способа выравнивания кода, если есть хоть один шанс перепутать её с пробелами (если такой шанс есть, он обязательно выпадает). Сам я нажимаю tab регулярно, но мои редакторы всегда превращают его в нужное число пробелов без каких-либо вариантов, этот символ остался только в моих старых программах, когда я ещё был полон иллюзий и оптимизма. Единственное исключение - makefile, но там и перепутать нельзя, не скомпилируется.
Yoda писал(а):
А пока так, то и блоки нужны. Но я согласен, что при отсутствии табуляции обозначение уровня вложенности могло бы определяться отступами.
Можно альтернативный вариант: во внутреннем plain-формате скобки для блоков кода есть, а во внешнем формате их нет. При этом в качестве скобок для внутреннего формата брать не именно скобки, а что-то типа __begin__ / __end__ или то, о чём пишет
SII (if / end if ).
Я, кстати, вообще против ключевых слов, но об этом позже.