Skip to content

Instantly share code, notes, and snippets.

@reznikmm
Created March 12, 2023 16:44
Show Gist options
  • Save reznikmm/20c5c9473e79621294393b0535372dcc to your computer and use it in GitHub Desktop.
Save reznikmm/20c5c9473e79621294393b0535372dcc to your computer and use it in GitHub Desktop.
Перевод "STEELMAN"

Требования для компьютерных языков программирования высокого уровня "Steelman".

Предисловие

Программа "Общий высокоуровневый язык" была создана Министерством обороны США в 1975 году. Ее целью было создание единого высокоуровневого языка программирования, который можно было бы использовать для встраиваемых компьютерных систем военного ведомства. Для этого была создана рабочая группа, которая определила требования к языку, оценила уже существующие языки и внедрила минимальный набор языков для использования в Министерстве обороны. В рамках административной инициативы Министерства обороны, Директива 5000.29 требует, чтобы все новые системы обороны использовали один из высокоуровневых языков, утвержденных и централизованно контролируемых Министерством. Согласно Инструкции 5000.31 Министерства обороны, предварительный список утвержденных языков включает COBOL, FORTRAN, TACPOL, CMS-2, SPL/1, JOVIAL J3 и J73. Различные оценки выгоды от более широкого использования языков высокого уровня показали, что быстрое внедрение единого современного языка значительно увеличит экономический эффект. Для создания единого языка, выработанные требования были предложены для обсуждения военному и гражданскому сообществу. В ходе диалога требования уточнаялись и приняли данный вид. В процессе разработки требований было определено, что полученный единый набор требований, является необходимым и достаточным для всех основных областей применений Министерства обороны. Была проведена формальная оценка десятков существующих языков, в результате которой было установлено, как то, что ни один из существующих языков не может быть принят в качестве единого общего высокоуровневого языка Министерства обороны, так и то, что язык, удовлетворяющий практически всем требованиям, может быть создан и очень желателен. Для разработки конкурирующих проектов-прототипов были профинансированы четыре команды. После анализа их проектов количество команд проектирования было сокращено до двух. По завершении обоих проектов будет выбран один язык. Дальнейшие шаги в программе будут включать тестирование и оценку языка, реализацию компиляторов и других инструментов разработки и поддержки программного обеспечения, контроль за языком и проверку компиляторов. Компиляторы и другой инструментарий, оплаченный правительством, как и система тестирования компиляторов, будут общедоступны, недороги и обеспечены поддержкой.

Технические требования

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

В этой версии были внесены следующие изменения. Было обращено внимание на то, чтобы номера абзацев оставались такими же, как и в прошлой версии. Были внесены несколько изменений в терминологию и множество изменений в формулировках, чтобы улучшить понимание и точность требований. Несколько требований были переформулированы более общим образом, чтобы убрать ограничения на предполагаемый механизм реализации. Требования для встроенных комментариев (2I), неупорядоченных перечисляемых типов (3-2B), спецификации ассоциативных операторов (7D), динамических псевдонимов к элементам массива (10B) и множественных представлений данных (11B) были удалены, поскольку они оказались не нужными или недостаточно обоснованными. Минимальный набор символов исходного языка был сокращен до 55 символов, чтобы сделать его совместимым с большинством существующих устройств ввода (2A). Модель "делать вместе" для параллельной обработки оказалась неадекватной для встроенных компьютерных приложений и была заменена требованием параллельных процессов (раздел 9). Предварительные версии продемонстрировали необходимость дополнительных требований к явным преобразованиям типов (3B), ограничениям подтипов (3D), переименований (3-5B), разделение открытых и закрытых областей видимости (5G), а также возможности, предпочтительно без специальных механизмов, передавать данные между параллельными процессами (9H), формулировать непроверяемые утверждения (10F), ожидать нескольких сигналов одновременно (9J) и помечать общие переменные (9C).

Структура описания требований схожа с ожидаемой структурой документа, определяющего язык программирования. Раздел 1 содержит общие критерии проектирования, которые устанавливают основные цели, влияющие на выбор более конкретных требований в последующих разделах и обеспечивают основу для принятия решений по проектированию языка, которые иначе не рассматриваются в этом документе. Разделы с 2 по 12 дают более конкретные ограничения на язык и его трансляторы. Steelman требует включения функций для удовлетворения конкретных потребностей в проектировании, реализации и поддержке военного программного обеспечения, указывает как общие, так и конкретные характеристики, желательные для языка, и требует исключения некоторых нежелательных характеристик. Раздел 13 описывает некоторые намерения и ожидания относительно разработки, контроля и использования языка. Предполагаемое использование и окружение для языка сильно влияет на требования и должно влиять на проектирование языка.

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

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

  • должен: указывает на требование, предъявляемое к языку программирования или транслятору
  • желательно: указывает на желаемую цель, но для которой нет объективного теста
  • должен попытаться: указывает на желаемую цель, но одновременно может быть недостижимой в свете текущего уровня технологии или может быть в противоречии с более важными требованиями
  • должен требовать: указывает на требование, которое предъявляется пользователю языка и его трансляторов (язык является объектом)
  • должен разрешать: указывает на требование, предъявляемое к языку для предоставления пользователю опции (язык является объектом)
  • обязан: указывает на требование, которое предъявляется пользователю языка и его трансляторов (пользователь является объектом)
  • может: указывает на требование, предъявляемое к языку для предоставления пользователю опции (пользователь является объектом)
  • будет: указывает на последствия, которые ожидаются, или на намерение МО, но само по себе не ограничивает проектирование языка
  • трансляция: относится к любой обработке, которую применяют к программе хост- или объектной машиной перед выполнением; включает лексический анализ, проверку синтаксических ошибок, анализ программы, оптимизацию, генерацию кода, сборку и загрузку
  • выполнение: относится к обработке объектной машиной для выполнения действий, предписанных программой.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment