Yoda писал(а):
Zealint писал(а):
Любой алгоритм, если он работает долго, выполняет какой-то набор шагов, которые условно можно разделить на ряд блоков, итераций или каких-то ещё структурных элементов. По запросу пользователя система просто обязана выдать позицию, на которой находятся вычисления.
Увы, это нереально. Наилучший выход - вставить в нужные места своей программы вывод информационно-диагностических сообщений типа "выполнено 999 итераций из 1000". А значит и поддержку info_level нужно делать самостоятельно.
Да, я и имел в виду самостоятельную реализацию
info_level, но хотелось бы иметь в языке или в библиотеке этого языка нечто более удобное, чем
#define,
#ifdef и т. д. Причём желательно, как я уже говорил, организовать работу запущенной программы так, чтобы уровень вывода сообщений можно было менять в «горячем» режиме. Будет ли это сделано в виде команд интерпретатора или с помощью каких-то сторонних инструментов, которые посылают в программу нужные команды, это детали. Важно, чтобы можно было вставлять в код программы (в нужные места) команды, которые умели бы принимать сообщения извне и менять свои настройки.
Yoda писал(а):
тЁплицева. Привычка вместо Ё писать Е (особенно в собственных именах) уже привела к массе недоразумений, например, искажению имён: Рёнтген, Депардьё, Рёрих, Чебышёв...
Спасибо. Да, увы, во многих местах написано через «е», тогда как я стараюсь использовать «ё», где разрешают. Часто запрещают, и даже пример «страна передохнёт холода» мало кого убеждает.
Yoda писал(а):
Значит другие СКА сделаны ещё хуже!
Так вот это меня и удивляет. Как можно сделать хуже? Я как-то развлекался с товарищами, мы выдумывали худший алгоритм сортировки, но чтобы он был обоснованным, там не было бы «очевидно-лишних» действий. Так вот, победив в этом коротком состязании, я всё равно не знаю, как можно ещё сильнее загадить ту функцию поиска соотношения. Тут я шучу немного, конечно, но очень удивлён.
Yoda писал(а):
Тут я бы разделил понятия. "Команды" - не совсем удачное определение. Есть синтаксические свойства языка, а есть библиотеки функций. То, о чём вы сейчас пишете, касается качества реализации библиотек, но это не завязано непосредственно на синтаксис. Хотя да, я полностью согласен, что реализации стандартных библиотек (а для СКА это, безусловно, математические библиотеки) необходимо уделать не меньшее внимание, чем самому языку.
Тут есть, как Вы верно намекаете, косвенная связь. Дело в том, что определённые особенности реализации библиотек могут довольно сильно зависеть от того, какие синтаксические конструкции предоставляет язык. Привожу пример: в C++ не было «лямбд», зато были извращения с разнообразными и трудночитаемыми указателями на функции, прописать полное определение которых можно было только в несколько строк. Теперь стало проще. Другой пример: раньше не было возможности вернуть из функции локальный объект без лишних операций создания копий, приходилось возвращать большие объекты по ссылкам, делая дополнительные параметры при вызове функции и прочие неестественные для современного стиля извращения. Теперь, когда появились R-value references, ситуация стала куда лучше. Так вот, я бы хотел, чтобы синтаксис был продуман настолько, чтобы не возникало подобных неудобств, заставляющих многие естественные для математика операции выполнять неестественным образом.
Yoda писал(а):
Ряд ваших пожеланий (например, безопасность и точки восстановления) касаются не языка, а интерактивной среды. В рамках неё такие механизмы, полагаю, могли бы быть реализованы.
Аналогично, тут есть косвенная связь с тем, какие будут средства, максимально упрощающие создание контрольных точек и то, как компилятор будет генерировать код восстановления программы из файла. В общем, при разработке языка нужно держать в голове и это.
Yoda писал(а):
Мой подход заключался бы в полном запрете на использование ассемблерных вставок. Машинно-оптимизированный код необходимо создавать в виде функций, полностью реализованных на ассемблере и компилируемых отдельно в объектные файлы.
Тогда желательно, чтобы компилятор умел нормально объединяться с известными ассемблерами. Это далеко не всегда обеспечено. Ещё один вариант - так называемые intrinsics функции.
Yoda писал(а):
Как быть с переносами в подобных примерах кода. Я вижу выход в разной размерности операнда и результата. Например, операция умножения может иметь 32-битные операнды и возвращать 64-битный результат (если таковой потребуется). Аналогично и с остальными операциями, кроме деления. Встречаясь с таким использованием, компилятор относительно легко мог бы понять смысл и оптимизировать код до пары ADD/ADC.
Как Вы видите свою идею для реализации, например, типа данных Int72? Даже если так, всё равно доступ к флагу переноса бывает нужным сам по себе, без ADC. Конечно ADC rax, 0 может выдать нам этот флаг, но уж больно это по-инвалидски. Тем более, это вынуждает использовать константу 0, которую а ассемблере как-то редко принято использовать в таком контексте, если только речь не идет об адресах и смещения или просто для красоты (когда идёт серия подряд add rax, [rdi + 0*4], add rax, [rdi + 1*4] и т. д.)
Yoda писал(а):
Вот тут, пожалуй, не совсем соглашусь, хотя направление мысли мне очень понятно. Действительно, если мы говорим про эффективность работы, то взаимозависимость полная - новая архитектура вряд ли сможет работать эффективно без поддержки со стороны инструментов программирования, а ЯВУ вряд ли смогут создать [значительно] более быстрый быстрый код для старых систем. Но есть одно "но". Если от архитектуры польза может быть оценена только по критерию скорости работы, то ЯВУ имеет и другие приоритетные факторы, такие как эффективность написания кода, защищённость языка от случайных ошибок, удобство его использования для разных задач. В этом смысле язык, обладающий новыми свойствами, мог бы послужить "паровозом" для новой архитектуры. А вот наоборот сделать сложно.
Хорошо, но я рассуждаю вот как. Есть жёсткие функциональные языки, однако они слабо повлияли на создание и популяризацию архитектуры ЭВМ, которая была бы чем-то похожа на такую парадигму. Напротив, популярные архитектуры скорее похожи на императивные языки. Эти языки развивались под действием этой архитектуры и вообще образа алгоритмического мышления в виде последовательности команд. Иными словами, раз у нас архитектура x86 или любая на неё концептуально похожая, то и язык должен быть уже императивным. Не вполне уверен, что декларативный язык (в т. ч. функциональный) будет хорошо ложиться на такую архитектуру, то есть нет смысла, например, сажать свинью в стойбище и, наоборот, коня в свинарник - им там будет «некомфортно». Хотя декларативная концепция может быть удобной для «чистых» математиков. Но у них есть Haskell, Miranda и у кого-то даже CL, их устраивает. А мне что-то неймётся.