Императивный vs Функциональный

Balancer>> я-то как раз Форт позиционирую как "гиперимперативный" язык

OSland> можно и как императивный Word1 Word2 Word3
OSland> а можно как функциональный Word3(Word2(Word1))

OSland> это как глянуть..

так и глянуть Функциональный язык подразумевает определение порядка вычислений самим языком (транслятором или рантаймом) и независимость результата от порядка вычислений. Это, кстати, и делает их весьма привлекательными для будущих мультиядерных систем и параллельных вычислений.

Императивный язык подразумевает последовательное выполнение конструкций языка, заданное программистом.

В этом смысле большинство современных императивных языков более "функциональны", чем Форт, ибо у них иногда есть некоторое размазывание порядка выполнения.

Форт же в этом плане сверхжёсткий.

...

А в каком синтаксисе писать то или другое - это дело десятое Вон, Хаскелл вполне императивную нотацию может иметь:



Но порядок вычислений нигде не задан

Кстати, функциональные языки очень интересны применительно к вычислителям "на иных принципах".

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

Татарин> С функциональными тоже не все просто

Общую мысль уловил, но практический подход вообще не представляю. Даже в теории

Мой трёп был вырван из контекста предыдущей темы - что не есть гуд..

Естественно "чистый" Форт сам по себе мягко говоря трудно назвать фунциональным языком - взять хотя бы отсутствие "высоких" фунций, но никто не мешает самому программисту работать в этом стиле..
Форт кстати и не ООП - но кто мешает?

насчёт порядка выполнения, распараллеливания и т.п. - ИМХО, не этом отличия между этими стилями программирования

OSland> но никто не мешает самому программисту работать в этом стиле..

Для реализации функционального подхода на Форте требуется написание виртуальной машины. Которая по сложности будет намного превосходить сам транслятор Форта. Таким образом... от Форта уже ничего не останется Из метазяыка он превратится в функционально ориентированный.

Пример грубый, но это то же самое, что O'Caml написать на GCC. Однако от этого GCC никто не назовёт функциональным

Изначальная идеология Форта - крайне выраженная императивность. Строжайшая последовательность исполнения и даже отсутствие забегания вперёд по потоку за очень редкими исключениями.

OSland> Форт кстати и не ООП - но кто мешает?

А вот ООП в рамках Форта сделать никто не мешает. ООП - это вообще другая плоскость. Точно также, как есть императивные языки как с ООП, так и без неё, есть и функциональные ООП и "чистые". Пример функционального ООП языка - O'Caml (собственно - Objective Caml).

OSland> насчёт порядка выполнения, распараллеливания и т.п. - ИМХО, не этом отличия между этими стилями программирования

А в чём? Вот формальное определение:

В языках функционального программирования основными конструктивными элементами являются функции. Основное отличие от императивных языков программирования заключается в декларативности описаний функций. Тексты программ на функциональных языках программирования описывают «как решить задачу», но не предписывают последовательность действий для решения.

// Язык функционального программирования — Википедия


Императивное программирование (англ. Imperative programming) — это парадигма программирования, которая в отличие от декларативного программирования описывает процесс вычисления в виде инструкций, изменяющих состояние программы. Императивная программа очень похожа на приказы, выражаемые повелительным наклонением в естественных языках, то есть это последовательность команд, которые должен выполнить компьютер.

// Императивное программирование — Википедия

 

Кроме того, это не стили программирования. Это разные подходы. На чистом функциональном языке ты не можешь писать императивно, даже если захочешь. На том же Хаскелле. Хотя, безусловно, есть функциональные языки с частичными императивными возможностями (O'Caml) или императивные с зачатками функциональности (тот же Python). Но языков, смешивающих эти подходы, скажем, в соотношении 50/50, т.е. где ты можешь спокойно переключаться с одного стиля на другой я просто не знаю

При небольшом раздумье над определениями из Википедии - можно согласиться что они достаточно убедительны, но лично для меня отличие между имп. и функ. совершенно не в описании последовательности действий.. а в способе описания..

Я тоже как то пытался своё ООП сделать, но понял что мне это особо то и не нужно при решении моих задач..
просто создал некоторую структуру "REP" которая помогала мне генерить необходимое количество однотипных объектов - этого оказалась вполне достаточно. Ну и словари конечно же..

P.S.
кстати с помошью этого самого "REP" оказалось удобно липить определяющие слова вроде vars conts vectors..
скажем так:
vars A B C D
вместо
variable A
variable B
variable C
variable D

Balancer>Для реализации функционального подхода на Форте требуется написание виртуальной машины. Которая по сложности будет намного превосходить сам транслятор Форта

ИМХО, достаточно будет текстового препроцесинга для перевода из функционального в императивное - VM то зачем трогать?
Я вообще очень очень многие задачи решал развитым текстовым препроцессингом - это одна из самых сильных сторон Форта по моему мнению.. куда там несчастному Си..с его препроцом.

Татарин>> С функциональными тоже не все просто
Balancer> Общую мысль уловил, но практический подход вообще не представляю. Даже в теории
Например квантовый комп может быть "термодинамически обратимым" (спорить о применимости термина не будем, важно, что результат - тот же) в пределах когерентной транзакции.
То есть: записал значения в регистр, развернул вектор состояния на угол фи, потом развернул на пси, потом выполнил несколько CNOT и снял значения с регистра. Редукция ВФ происходит единыжды: лишь в момент, когда ты снимаешь значения, они становятся определенными; лишь тогда тратится и-или выделяется энергия.
До того момента ты можешь манипулировать вектором сколько угодно теоретически БЕЗ затрат энергии вообще (ну, во временных рамках, определяемых физикой компа).

Функциональный язык, в принципе, позволяет сформировать оптимальную операцию, которая будет проведена в одну транзакцию. С императивным - сложнее, ибо если ты не имеешь гарантии независимости от порядка вычислений, то тебе во многих случаях остается лишь пошагово и тупо записывать-проводить операцию-считывать, возможно, теряя при том саму суть и выгоду квантовых операций.
Ну и энергию, конечно.

OSland> ИМХО, достаточно будет текстового препроцесинга для перевода из функционального в императивное - VM то зачем трогать?

Потому что это будет иначе уже не Форт, а просто транслятор ЯФП, написанный на Форте. Я, вон, уже приводил примеры Бейсика на Форте и Си на Форте. От этого, н Бейсик, ни Си, Фортом не становятся.

OSland> Я вообще очень очень многие задачи решал развитым текстовым препроцессингом - это одна из самых сильных сторон Форта по моему мнению.. куда там несчастному Си..с его препроцом.

Если ты средствами Форта будешь просто транслировать чужую нотацию в Форт - это не будет ничем отличаться от написания того же Форта на Си. Соответственно, при таком подходе можно сказать, что Си имеет всю мощность Форта.

Бред, в общем, выходит.

Форт в том виде, в каком он называется Фортом, является языком не просто императивным, а ортодоксально императивным. Возможность написания на нём "функционального транслятора" - то же самое, что возможность написания на Си Хаскелла - не сделает Си языком функциональным.

Аналогично, скажем, O'Caml генерирует при компиляции своей программы GCC-код. От этого ни O'Caml не становится императивным, ни GCC - функциональным.

Форт тут отличается от более "чистых" случаев только тем, что способен не только транслировать функциональный код в свой, но и делать это прямо по тексту программы, не запускаясь в виде чистого транслятора. Но это - просто особенность его трансляции входного потока.

Не знаю насчёт бреда или не бреда - а по моему если человек написав в начале исходника нечто похожее на "include funсtion.f" и получив в своё распоряжение средства создания и работы со списками (множествами), особо подчеркну наличие функций высшего порядка вроде питоновских "map", "filter" и т.п. начинает писать свои программы в фунциональном стиле - то какая ему разница что там происходит в run-time и какой там может быть порядок вычислений процессором? Просто человек начинает мыслить при описании задачи не циклами и присваиваниями данных, а другими категориями - такими как обход списка, применить фунцию к множеству и т.п.

мнение моё - возможно что и ошибочное - но моё.
OSland

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

Реконструктор> Все это буду писать на Си.

ИМХО, по описанные тобой задачи заточен лучше других Haskell Но подробности не спрашивай, никогда им не занимался.

Реконструктор>> Все это буду писать на Си.
Balancer> ИМХО, по описанные тобой задачи заточен лучше других Haskell Но подробности не спрашивай, никогда им не занимался.
Нет, Хаскель - это не то.

Если принять задачу, как она описана - то совсем не то.

Татарин> Нет, Хаскель - это не то.
Татарин> Если принять задачу, как она описана - то совсем не то.

Здрасьте. Как раз, на сколько я знаю, его основной "сахар" в метапрограммировании разных языковых концепций и виртуальных машин. С разными идеологиями. Хотя, м.б., я задачу плохо понял

Татарин>> Нет, Хаскель - это не то.
Татарин>> Если принять задачу, как она описана - то совсем не то.
Balancer> Здрасьте.
Привет!

Balancer> Как раз, на сколько я знаю, его основной "сахар" в метапрограммировании разных языковых концепций и виртуальных машин. С разными идеологиями. Хотя, м.б., я задачу плохо понял
Обрати внимание на понятие кадра у Реконструктора.

Впрочем, может, он сам скажет?

То? или не то?

Из этой ссылки:

Pure functional programming languages typically enforce referential transparency, which is the notion that 'equals can be substituted for equals': if two expressions have "equal" values (for some notion of equality), then one can be substituted for the other in any larger expression without affecting the result of the computation. For example, in

y = f(x) * f(x);

a compiler can factor out f(x) if it is pure, transforming the program to

z = f(x);
y = z * z;

and eliminating the second evaluation of the (possibly costly) call to f(x). This optimization is called common subexpression elimination.

 

Вроде такое мне надо.

Это называется выносом общих подвыражений. Старая техника оптимизации. Работает на дереве вычислений программы, где каждому узлу присваивается сложность. Ищются одинаковые поддеревья, и, если суммарная сложность выше той, что у предпологаемой замены, то вводится новое поддерево, а все вхождения заменяются на него. Возможны модификации. Только надо быть осторожным с side effects — т.е. их надо учитывать при составлении функции равенства (notion of equality).

Mishka> Только надо быть осторожным с side effects — т.е. их надо учитывать при составлении функции равенства (notion of equality).

В подавляющем большинстве языков, в основном - почти во всех императивных, side effects в этих случаях учесть вообще практически невозможно. Поэтому - и оптимизация такая реально использоваться не может. В Хаскелле - пожалуйста. А вот уже в том же O'Caml - вряд ли (насколько я понимаю, там даже глобальные переменные водятся...) Про всяких Си с Фортами и Явами я вообще молчу

Mishka>> Только надо быть осторожным с side effects — т.е. их надо учитывать при составлении функции равенства (notion of equality).
Balancer> В подавляющем большинстве языков, в основном - почти во всех императивных, side effects в этих случаях учесть вообще практически невозможно. Поэтому - и оптимизация такая реально использоваться не может. В Хаскелле - пожалуйста. А вот уже в том же O'Caml - вряд ли (насколько я понимаю, там даже глобальные переменные водятся...) Про всяких Си с Фортами и Явами я вообще молчу

Можно. Только полностью систему программирования надо свою делать. Когда Алголом 68 занимался, то так и было. У нас был оптимизатор на разных стадиях, в том числе и линковщик свой — оптимизирующий. А у каждой процедуры был паспорт, её описывающий. Строились сложные зависимости перекомпеляции в том числе и на основе паспорта. Ктсати, паспорт в каком-то виде доходил и до кода в "Самсоне" — там на микропрограммном уровне (команда возврата и очистки стека с восстановлением регистров) производилось сохранение и восстановление только тех регистров, что были нужны вызывающей программе. А количество потраченных регистров в вызываемой процедуре помогало оценить сложность процедуры и переопределить порядок выполнения таким образом, чтобы наиболее сложные процедуры выполнялись в последнюю очередь — тогда излишнее восстановление регистров не выполнялось столь часто, можно было наводить индуктивные и временные переменные.