В общем, когда математика используется для изучения некоторого X , сначала требуется модель X , а затем разрабатывается теория, набор результатов об этой модели. Я предполагаю , что теория может быть названа «теоретической основой» для X . Теперь установите X = вычисление. Существует много моделей вычислений, многие из которых связаны с «состоянием». Каждая модель имеет свою «теорию», и иногда ее можно «переводить» между моделями. Я считаю, что трудно сказать, какая модель является более «базовой» - они просто разработаны с разными целями.
Машины Тьюринга были разработаны, чтобы определить, что вычислимо . Таким образом, они составляют хорошую модель, если вы заботитесь о том, существует ли алгоритм для определенной проблемы. Эта модель иногда злоупотребляли для изучения эффективности алгоритмов или твердости проблем, под тем предлогом , что это достаточно хорошо, по крайней мере , если вы заботитесь только о Полином / неполиномиальным. Модель оперативной памяти ближе к реальному компьютеру и, следовательно, лучше, если вы хотите точного анализа алгоритма. Чтобы поставить нижние оценки твердости проблем, лучше неиспользуйте модель, которая очень похожа на современные компьютеры, потому что вы хотите охватить широкий спектр возможных компьютеров, но при этом быть более точной, чем просто полиномиальный / неполиномиальный. В этом контексте я видел, например, модель сотового зонда.
Если вы заботитесь о правильности , тогда вам пригодятся и другие модели. Здесь у вас есть операционная семантика (которую я бы назвал аналогом лямбда-исчисления для вычислений с полным состоянием), аксиоматическая семантика (разработанная Хоаром в 1969 году на основе индуктивных утверждений Флойда от 1967 года, которые популяризируются Кнутом в «Искусстве компьютерного программирования» , том 1) и др.
Подводя итог, я думаю , что вы после моделей вычислений. Существует много таких моделей, разработанных с различными целями, и многие из них имеют состояние, поэтому они соответствуют императивному программированию. Если вы хотите узнать, можно ли что-то вычислить, посмотрите на машины Тьюринга. Если вы заботитесь об эффективности, посмотрите на модели RAM. Если вы заботитесь о правильности, посмотрите на модели, которые заканчиваются на «семантику», например, на операционную семантику.
Наконец, позвольте мне упомянуть, что в Интернете есть большая книга о моделях вычислений Джона Сэвиджа. В основном это эффективность. Для корректности я рекомендую начать с классических работ Флойда (1967) , Хоара (1969) , Дейкстры (1975) и Плоткина (1981) . Они все очень крутые.
Простейшей теоретической моделью императивной программы является сама машина Тьюринга. У него есть оба важных компонента императивной программы: неограниченное изменяемое состояние и конечный автомат, который работает с ним.
Вы также можете превратить императивное программирование в функциональное программирование, рассматривая программы как композиции монадических операций, которые передают и возвращают измененные версии глобального состояния, как это делается на языке программирования Haskell.
источник
Короче говоря, я бы сказал, что императивное программирование возникло из машинного языка и практики программирования. С другой стороны, монады предоставляют подходящую семантическую структуру для описания семантики функций императивного языка программирования. В статье « Понятия вычислений и монад » Могги заложены формальные основы. Фил Уодлер популяризировал эту идею и внес существенный вклад в то, что она стала ключевым способом включения императивных функций в язык программирования Haskell. Недавняя работа Плоткина и степенные понятия вычислений определяют монады идет другой путь, утверждая, что некоторые, но не все, понятия (императивного) вычисления на самом деле дают монаду, что означает, что монады очень существенно соответствуют императивным (и другим) понятиям вычисления.
источник
Если вы ищете строгую математическую трактовку императивного языка программирования, в качестве примера можно привести книгу Винскеля «Формальная семантика языков программирования» (1993).
В книге он определяет императивный язык программирования, называемый IMP, и предоставляет его операционную, денотационную и аксиоматическую семантику.
источник
Я подхожу к этому вопросу поздно, но это увлекательный вопрос. Итак, вот мои взгляды.
Когда я был студентом, у нас был великий профессор математики, который давал нам лекции по истории и развитию математики. По его словам, математика развивалась волнами «расширения» и «консолидации». На этапе расширения были рассмотрены и исследованы новые идеи, которые ранее были неизвестны. Затем, на этапе консолидации, новые теории были интегрированы в существующую совокупность знаний. Однако, по его словам, в 20-м веке расширение и консолидация идут параллельно.
Императивное программирование в настоящее время является расширением деятельности по математике. Это было ранее "неизвестно". (Это может быть не совсем верно. Хоар говорит нам , что Евклид занимался чем-то вроде императивного программирования в своей геометрии. Но математика потеряла к ней интерес, к лучшему или к худшему.) Математики по-прежнему не заинтересованы в императивном программировании. Так много потерь для них. Но я рассматриваю всю информатику как раздел математики в абстрактном смысле. Мы изучаем это, расширяем математику в процессе.
Поэтому мне было бы все равно, есть ли априорная теоретическая основа для императивного программирования. Если его нет, пойдем и найдем его. То, что мы уже знаем, говорит нам, что императивное программирование фантастически глубоко и красиво. Функциональное программирование меркнет в сравнении. Но у нас много работы, чтобы донести всю эту теорию до людей.
источник
Функциональное программирование имеет четкую основу в математике, потому что функциональные языки программирования развивались параллельно с соответствующей математикой, и их разработчики обычно высоко ценили математику. Сильные и прямые отношения - самоисполняющееся пророчество.
Императивное программирование имеет значительно более сложную историю, которая гораздо теснее связана с бизнесом и инженерными проблемами и исторически гораздо больше была связана с производительностью компиляторов и генерируемого ими кода, чем с соблюдением математических формализмов.
Многие люди пытались объяснить императивное программирование в (традиционно) функциональных терминах. Это может быть ближе всего к тому, что вы ищете, но эти попытки неизменно неуклюжи, утомительны, криминалистичны. Я почти уверен, что предпочел бы оторвать глаза от лица, чем прочитать доказательство прогресса / сохранения для CLR.
Обычно, если вы подходите к концу достойного учебника по PL (например, «Типы и языки программирования» Пирса), вы начнете видеть формальное моделирование императивных языковых функций. Это может быть интересно для вас.
источник
An Axiomatic Basis for Computer Programming
АВТОМОБИЛЕМhttp://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.8553&rep=rep1&type=pdf
источник
Во-вторых, Александр сказал, что машина Тьюринга обеспечила оригинальную теоретическую основу для императивного программирования. В той степени, в которой организация императивных языков программирования отражает архитектуру машины, я думаю, что работа Джона фон Неймана также будет ключевой частью их теоретических основ.
источник
Если вы имеете в виду «основание» в историческом смысле, я думаю, что не существует «эквивалентной математической основы». Однако, хотя императивное программирование возникло из практических соображений, существует несколько способов всесторонней характеристики значения императивного программирования способами, которые могут оказаться «полезными для моделирования», такими как логика Хоара .
источник
посты, которые упоминают логику Хора и логику разделения, являются правильными в этом вопросе. Логика Hoare позволяет вам указывать свойства всей конфигурации кучи программы, а логика разделения - это более современный родственник, который позволяет вам использовать «разделяющее соединение», которое позволяет вам указывать в качестве условий до и после того сегмента кода, для которого предназначены свойства часть кучи, которой программный сегмент будет манипулировать при количественном определении по остальной части кучи.
Ответ относительно монад не является строго точным, потому что в haskell монада используется только потому, что это абстракция, которая позволяет кодировать порядок ограничений оценки и явно отслеживать свойство «возможно использовать IO».
Стоит указать и на то, что логику хора / разделения можно рассматривать как монады, и что существует ряд современных проектов, таких как проект ynot в Гарварде, которые изучают эти темы.
исследование логики разделения - это постоянная и активная область.
источник
Я подойду к этому вопросу еще позже, но я в равной степени очарован этим.
Почему теория императивного программирования считается менее обоснованной, чем теория функционального программирования, уклоняется от меня. Вероятно, он начал серьезно относиться к Скотту и де Баккеру в 1969 году, когда они проанализировали значение рекурсии на простом императивном языке [1]. Когда императивный язык приобретает черты, история становится немного грязнее, но это всего лишь цена, которую нужно заплатить за то, чтобы быть ближе к металлу. Чтобы назвать одно из более всеобъемлющих усилий, в 1980 году де Баккер, де Брюин и Цукер написали монографию на эту тему [2]. Другие были упомянуты выше. Эти ссылки, конечно, предшествуют логике разделения, но [2], тем не менее, затрагивают массивы и взаимно рекурсивные процедуры.
[1]: неопубликованный в 1969 году, но появился как Джако де Баккер и Дана С. Скотт. Теория программ , стр. 1-30. В Klop et al. JW де Баккер, 25 лет семантик. КРИ, Амстердам, 1989. Liber Amoricum.
[2]: Якобус В. де Баккер, Арье де Брюин, Джеффри Цукер: Математическая теория правильности программы. Прентис Холл 1980.
источник
Вскоре после того, как вы задали свой вопрос, Марк Бендер из Университета МакМастер опубликовал диссертацию: « Исчисление заданий: чистый язык императивных рассуждений» (8 сентября 2010 г.) Этот тезис описывает простой императивный язык, соответствующий лямбда-исчислению.
Тезис Марка Бендера продолжает исследовать варианты, расширенные с ленивой оценкой, возвратом, составлением процедуры. Это похоже на исследование лямбда-исчисления с использованием небольших расширений.
В целом, тезис дает относительно прямой ответ на вопрос ОП.
источник