Yoda писал(а):
Проблем с написанием функций целиком на ассемблере я не вижу, главное - соблюдать соглашения о вызовах и писать соответствующие прототипы функций в заголовочных файлах.
Проблема, о которой я говорил, так это несовместимость объектных файлов, получаемых каким-то компилятором с тем, что даёт выдаёт ассемблер. Например, я потратил какое-то время на то, чтобы объединить VS и ассемблер. В результате, объединить студию удалось только с vsyasm. Не буду утверждать, что приложил все усилия, но сам факт наличия проблемы, разрешающейся неочевидным для рядового программиста образом, огорчает. Хотя мне лично тоже больше нравится отдельные функции целиком писать на ASM. В VS уже давно запретили Inline-assembler.
Yoda писал(а):
Int72 - не вижу проблем. Умножения отбрасывают лишние разряды, сложения/вычитания добавляют перенос после операции с 64 битами к 8 битным операндам.
Я имею в виду, как Вы заставите компилятор применить adc в нужном месте? Допустим, мы определяем класс class int72 { int32 l, h; int8 hh; }; Мы не хотим плодить кучу функций умножения и сложения с разным размером операндов и результатом int72, поэтому решили написать один оператор, который на входе и на выходе имеет дело с int72 (т. е. компилятор не получит подсказки в виде разных размерностей операндов и результата). Как может выглядеть реализация такого оператора на Вашем языке, чтобы компилятор сообразил, что нужен adc? Я вижу лишь один подходящий вариант: определить в языке оператор, скажем #, который для базовых типов (int32, int64) гарантированно превращается в adc, при этом не вносит между серией add / adc никаких других команд, сбрасывающих флаг переноса. Например (псевдокод):
Код:
int72 operator + ( int72 a, int72 b ) {
Result . l = a . l + b . l;
Result . h = a . h # b . h;
Result . hh = a . hh # b . hh;
}
Компилятор, увидев это, гарантирует, что менять порядок не будет и разбавлять чем-нибудь тоже.
Как же тогда обозначить аналог SBB? : )
Yoda писал(а):
Я всегда выступал с резкой критикой функциональных языков.
Да и мне они кажутся слишком неестественными. Зато там есть идеи, которые заслуживают внимания. Те же лямбды, и вообще определение функции как объекта. Бывает удобным в C++.
Yoda писал(а):
Собс-но, я не к тому, что это пара пустяков, но не стоит преувеличивать сложность создания рабочего компилятора даже по самым продвинутым стандартам. Основная сложность заключается в разработке оптимизации. Это - да, может отнять много человеко-лет.
Ну, я это и имел в виду, оптимизирующий компилятор. Как-то неоптимизирующий и в голову мне не приходил.
Yoda писал(а):
Да, мне тоже сложно себе представить набор программ в таком виде. По крайней мере, про текстовые редакторы придётся забыть.
Да, я думаю, что придётся. Ведь раньше были перфокарты и не совсем просто было представить, что можно сделать текстовый редактор. Теперь текстовый редактор для целей программирования не очень-то многими используется, хотя я на протяжении многих лет писал все программы на всех языках в обычном редакторе Far, а кто-то для тех же целей использует vim. Я в нём вообще всё писал, даже письма, книги, диссертацию и т. д. Но, должен сказать, что был бы нормальный редактор кода для того же TeX, я бы им пользовался. Сейчас многие редакторы уже выглядят пристойно для набора программ в привычном смысле и вот, кто-то уже и не мыслит, что можно написать код в обычном MS-блокноте. А в ряде учреждений не знают ничего кроме MS-Word, и когда делаешь работу в TeX, принося им PDF, они не знают, что с ним делать. Тенденция такова, что обычный текстовый редактор постепенно заменяется необычным, а затем и вовсе уйдёт в прошлое, как перфокарты.
Может показаться, что всё плохо, ведь программу нельзя отредактировать другим редактором:
Yoda писал(а):
В вашем случае потребуется визуальный редактор и программу невозможно будет редактировать в любом другом стандартном текстовом редакторе.
Но давайте посмотрим на вещи иначе. Если нет компилятора, то нельзя скомпилировать программу. Так отчего же мы будем сокрушаться, что у нас нет визуального редактора, чтобы её написать? В моём представлении компилятор и среда программирования должны идти вместе, хотя никто не будет запрещать создавать другие визуальные редакторы, подобно тому, как для одного и того же языка существуют различные IDE. Не совсем понятно, почему следует держаться за редакторы обычного plain-текста так сильно. Только потому что большинству это кажется удобным в силу привычки? У большинства вообще редко привычки бывают разумными. Это сложно, но вполне возможно изменить любые привычки любого человека. Главное, чтобы идея оказалась на самом деле лучше, а для этого нужно очень хорошо её продумать. Есть вещи, которые нужно перестать тащить за собой как мусор. Обычные текстовые редакторы и текстовые графические режимы вполне могут оказаться таким мусором, как и древние кодировки. Это я весьма категорично высказался, я понимаю, но раз высказался, значит есть личные причины.
Yoda писал(а):
Сначала кажется, что использование UTF-8 облегчает эту задачу. Однако, если покопать, открывается куча подводных камней. ОС Windows заточена под использование кодировки Win-1251, поэтому переносимость сразу теряется. А разновидности виндовс - это подавляющий процент рынка, забить на него нельзя.
Не совсем ясно, почему теряется переносимость. Винвовс поддерживает utf-8. Кроме того, бывают случаи, когда общество вынуждает пересмотреть ошибки прошлого.
Yoda писал(а):
Далее, символы в юникоде разные, есть, например, пробел, разные тире. Как отличать, что относится к идентификаторам?
Это непростой вопрос, но я над ним думал уже. Решение вижу в подсветке синтаксиса. Графические редакторы позволяют самым разным способом раскрасить и выделить разные языковые конструкции (кому не нравятся разные цвета, то можно настроить оттенки серого).
Yoda писал(а):
Современные стандарты С/С++ разрешают использование символов UTF-8 в именах идентификаторов, однако при этом используется куча дополнительных регламентирующих таблиц.
По поводу идентификаторов можно придумать разные варианты. Например, запретить использовать в них какие-то нелатинские буквы. Меня однажды напрягла одна тупая ошибка, обнаружив которую я очень удивился, так как в те далекие времена почти никогда не ошибался при написании программ. Там в названии функции была русская буква «с» вместо латинской «c». Компилятор при этом выдавал что-то невнятное.
Yoda писал(а):
В общем, это тот самый случай, когда за 30-40 лет накопился ком проблем, который пока не очень понятно, с какого конца раскручивать. Лично я пока что для себя решил так: национальные символы запрещены. Собс-но, это не означает, что они запрещены навсегда. Разрешить их использование потом - не проблема. А вот менять что-то в уже использующихся кодах - может превратиться в очередную головную боль и до ужаса кривые стандарты. Лучше перетерпеть лет 10 и не гнаться за прогрессом вместе с толпой, эта толпа может завести не туда.
Вы имеете в виду, не гнаться за utf-8? Подождать другую кодировку? Или подождать, пока эта устоится?
Yoda писал(а):
Нет уж, инструмент должен быть достаточно удобен, чтобы им без проблем мог начать пользоваться новичок.
Сейчас дети в два-три года пользуются телефоном лучше, чем я, опытный пользователь ПК : ) Не думаю, что они будут испытывать какие-то сложности с графическим редактором, а скорее будут криво смотреть на текстовой как на пережиток прошлого, о котором они даже ничего толком не знают. Так я смотрю на перфокарты, например, на БЭСМ-6 тоже так смотрю. Даже на своих преподавателей, которые всего-то лет на 5-10 меня старше я вынужден смотреть как на людей, безнадёжно отставших от методологии разработки высокопроизводительных программ, я очень рад, что мне удалось без большой крови работать в своём стиле, а не в их. Хотя «подраться» пришлось.
Yoda писал(а):
Нет, почему же? Это надо понимать скорей так: Zealint понимает, что он не будет самостоятельно заниматься разработкой языка (и тем более написанием компилятора), т.к. не обладает соответствующими навыками и необходимым временем, но из этого не следует, что никто другой не создаст новый язык. Я прав, Zealint?
Скорее правы, чем нет. Я могу быть частью команды, которая разрабатывает язык. Думаю, что многим дам фору в вопросах тестирования продукта и реализации сложных алгоритмов для его библиотек. Могу также поделиться опытом размышлений такого плана, которым делюсь вот в этой теме. А сам компилятор вряд ли напишу правильно, никогда этого не делал и теорию знаю лишь на уровне общих университетских курсов. Книгу дракона даже не полностью ещё изучил, хотя пока ничего нового там для себя не обнаружил. Язык невозможно создать без правильной идеи, мне будет достаточно, если в этой объемлющей идее будут и мои мысли.