Например, благодаря огромному количеству внедрённого контента, каждый сайт имеет уникальную сигнатуру запросов к DNS при просмотре. Для каждого из запрещённых сайтов эта сигнатура хорошо известна. Было б желание сопоставить.
Судя по fpc, я был прав в отношении Windows и OS/2:
class procedure TThread.Yield;
begin
ThreadSwitch;
end;
...
ThreadSwitch :=@SysThreadSwitch;
...
// Windows
procedure SysThreadSwitch;
begin
Sleep(0);
end;
// OS/2
procedure SysThreadSwitch;
begin
DosSleep(0);
end;
Однако, при этом в Linux:
// Linux
procedure SysThreadSwitch; {give time to other threads}
begin
pthread_yield;
end;
а там, в свою очередь:
int pthread_yield (void)
{
return sched_yield ();
}
Как-то всё очень запущено в этом кроссплатформенном инструменте.
Я вообще не уверен, что в винде такая есть. Так как ядро винды - отдалённое наследие OS/2, то там это поведение, думаю, регулируется через классы приоритетов.
Впрочем, мы очень удалились от темы. Я только хотел сказать, что опасно предполагать семантику по созвучию синтаксиса.
В конечном итоге компьютер делает только одно - заменяет одни значения битов другими по таблице. А императивное и функциональное программирование - просто семантические абстракции, то есть наш способ упрощённо думать об этом процессе, не запоминая огромных таблиц подстановки битов. Исходя из этого, разницы нет. Но в удобстве для человека в тех или иных случаях разница есть.
выполнять параллельно с уверенностью в заведомой невозможности возникновения конфликтов между параллельно выполняемыми экземплярами
Это очевидно невозможно в общем случае в связи с тем, что некоторые феномены параллельного выполнения имеют сущностный характер, а не просто являются следствием неоптимальной организации кода. Когда у вас на реальном складе один экземпляр товара, то никакое ФП не позволит его одновременно продать два раза и не сесть за это.
Поэтому внешнее окружение меняется, в том числе иногда меняется и кодом программы, чего бы ни хотелось адептам чистоты функций. Другое дело, что без нужды так делать не нужно. В Лиспе и его наследниках изменяемые элементы внешнего окружения (глобальные переменные) принято по соглашению о стиле выделять в коде звёздочками, чтобы сразу было заметно.
Но сущностно (и в ФП программе) таких случаев очень немного в общей массе кода, а в императивной программе они повсеместны.
ФП в вашем изложении начинает выглядить настолько всеобъемлюще,
Оно и есть всеобъемлющее. Это теоретический фундамент программирования вообще.
что в целом становится неотличиным от императивного программирования.
Ну как неотличимым? По коду сразу видно. А результат, конечно, тот же самый.
А это и есть псевдоним правой части, коль скоро нет побочных эффектов. Имя является псевдонимом значения, а значение является псевдонимом способа своего вычисления.
Я посмотрел вскользь книжку Филда и Харрисона. Как я и подозревал, они просто излагают невнятно. Когда они пишут, что функции не могут изменить среду вычислений, то подразумевают при этом внешнюю для конкретной функции среду, то есть отсутствие побочных эффектов. Это никак не мешает функции менять среду внутри себя, что они и иллюстрируют оператором letсвоего языка Hope.
Макбук очень сложно заставить работать с закрытой крышкой, а кроме того, он не предназначен для работы с постоянной значительной нагрузкой. Будет нагреваться, шуметь и тормозиться.
Я говорил о программировании с помощью функций, как про это рассказано в первых главах старой (1987, русский перевод - 1993) книжке Филда и Харрисона "Функциональное программирование".
Не читал эту книжку, поэтому не могу никак прокомментировать. Вообще, многие академические издания зачастую страдают оторванностью от реальности и собственным языком, понятным только авторам.
Чтобы придать содержательность, ответьте на пару вопросов:
Является ли состояния окружения изменякмым?
Может ли программа изменять состояние своего окруженния?
Является и может, конечно. Простейшим способом изменения окружения является само по себе применение функции (в просторечии – функциональный вызов). Когда мы пишем:
((lambda (x) expr) 1)
то здесь в окружении выражения expr значение символа x меняется на 1. Это и есть самая основа лямбда-исчисления, бета-редукция (с несущественной для нас точностью до порядка вычислений).
Тождественно то же самое (немедленное применение лямбда-выражения) для удобочитаемости можно записать в форме:
(let
((x 1))
expr)
что уже очень напоминает присваивание в императивных языках.
Другое дело, что в ФП не принято злоупотреблять изменением нелокального окружения, то есть, в частности, неограниченно длящимся присваиванием. Хотя само по себе определение функции как раз и является примером изменения внешнего окружения – присваиванием имени функции в (чаще всего) глобальном контексте значения, представляющего собой её тело:
(define (f) expr)
то же самое, что
(define f (lambda () expr))
или
(define f)
(set! f (lambda () expr))
то есть самое настоящее определение переменной и присваивание значения.
Если оба ответа - "да", то в чем тогда состоит функциональность ФП?
В том, что связь исходных данных и результата (т.е. программа) представляется как суперпозиция применения функциональных форм.
И, в частности, по второму вопросу: надо ли отделять сотояние окружения от состояния программы - где польза в таком разделении?
Состояние окружения – это формально определённый теоретический термин, а состояние программы – практический программистский. Разница между ними всё же есть, потому что к состоянию окружения относятся также данные, внешние по отношению к программе – содержимое файлов, состояние внешних устройств, действия пользователя и т.п.
Может, в таком случае лучше говорить о "реактивном программировании" (тут на Хабре, кстати, совсем недавно была очередная статья - нынтье на тему React).
Я не специалист в области реактивного программирования, поэтому могу что-то изложить неверно. В моём понимании, реактивное программирование – это парадигма операционной семантики, то есть способа выполнения программы. В своей основе реактивное программирование запросто может опираться на функциональное программирование, как парадигму денотационной сематики (т.е. описания связи между входом и выходом). Само по себе ФП не подразумевает какую-то конкретную последовательность действий.
потому, что ФП реально накладывает чрезмерные ограничения на допустимый синтаксис: например, в нем AFAIK концептуально нет переменных, хранящих состояние программы, и нет оператора присвоения значения таким переменным. Так?
Тут мы увязаем в тонкостях формулировок. Смотря что вы понимаете под переменными и оператором присваивания. В таком виде, как в императивном программировании, их нет (точнее, их не принято применять в функциональном стиле – примерно как с goto). Вместе с тем, чем вам описанная выше форма let хуже переменных с присваиванием? Скажу сразу, что ничем не хуже, так как именно лямбда-исчисление является теоретическим фундаментом любого программирования, в том числе и императивного.
А я вижу: разница - в назначении. Код (в фон-Неймановской архитектуре) - это данные, предназначенные для интерпретации их процессором, и изменения в процессе этой интерпретации других данных (код, который не меняет других даннных есть вещь в себе, для стороннего наблюдателя он бесполезен).
Код также может быть исходными данными для рефлексии. Например, в компиляторе, анализаторе кода или самомодифицирующейся программе.
Впрочем, двоемыслие - это форма диалектики, но эта тема уже далеко выходит за пределы дискуссии о ФП.
Возможно, в данном конкретном случае в компиляторе C++, векторизация и не будет выполняться. Но это несущественно вне рамок изучения машинно-зависимой оптимизации, то есть гораздо более глубокого и узкого знания. Я считаю, что обучающимся на первом этапе нужно сосредоточиться на денотационной семантике, то есть на том, что, собственно, они хотят получить. На основных паттернах кодирования в выбранном языке. А уж потом в деталях разбираться, как это происходит.
Всё подобные вещи - это циклы с условиями и никак по-другому их выразить нельзя
Можно выразить через переходы, можно через рекурсию, можно через аппликацию (макроподстановку). Да хоть через какой-нибудь аналоговый регулятор. Я студентам как раз объяснял возможность выражения алгоритма разными способами.
Вы себе можете, конечно, представлять семантику этого процесса в виде цикла, но никакого цикла там нет. Есть действия над структурой данных, которые можно представить элементарной операцией, а можно повторяющимися переходами, циклом, рекурсией и бог весть как ещё. Вы с детства познакомились с циклом, как конструкцией структурного программирования, и представляете там его себе, но его там нет ни на каком уровне рассмотрения (разве что, может, какая-то конкретная реализация стандартной библиотеки может быть написана на C/C++, и там в исходном коде будет цикл). С тем же успехом можно себе представлять рекурсию.
Какой-то компилятор в определённых условиях может подставить одну векторную операцию.
Историю поиска уже с изъятого телефона можно приобщить.
Например, благодаря огромному количеству внедрённого контента, каждый сайт имеет уникальную сигнатуру запросов к DNS при просмотре. Для каждого из запрещённых сайтов эта сигнатура хорошо известна. Было б желание сопоставить.
Судя по fpc, я был прав в отношении Windows и OS/2:
Однако, при этом в Linux:
а там, в свою очередь:
Как-то всё очень запущено в этом кроссплатформенном инструменте.
Я вообще не уверен, что в винде такая есть. Так как ядро винды - отдалённое наследие OS/2, то там это поведение, думаю, регулируется через классы приоритетов.
Впрочем, мы очень удалились от темы. Я только хотел сказать, что опасно предполагать семантику по созвучию синтаксиса.
Почему не Кобол тогда?
Я предполагаю, что дельфийский yield представляет собой обёртку над WinSleep(0) (или как там она называется в винде).
sched_yield так и задуман, он предназначен для задач реального времени. Поменяйте на sleep(0).
Остановит процессор до окончания кванта диспетчеризации или другого прерывания.
Метод не элегантный, но рабочий.
В конечном итоге компьютер делает только одно - заменяет одни значения битов другими по таблице. А императивное и функциональное программирование - просто семантические абстракции, то есть наш способ упрощённо думать об этом процессе, не запоминая огромных таблиц подстановки битов. Исходя из этого, разницы нет. Но в удобстве для человека в тех или иных случаях разница есть.
Это очевидно невозможно в общем случае в связи с тем, что некоторые феномены параллельного выполнения имеют сущностный характер, а не просто являются следствием неоптимальной организации кода. Когда у вас на реальном складе один экземпляр товара, то никакое ФП не позволит его одновременно продать два раза и не сесть за это.
Поэтому внешнее окружение меняется, в том числе иногда меняется и кодом программы, чего бы ни хотелось адептам чистоты функций. Другое дело, что без нужды так делать не нужно. В Лиспе и его наследниках изменяемые элементы внешнего окружения (глобальные переменные) принято по соглашению о стиле выделять в коде звёздочками, чтобы сразу было заметно.
Но сущностно (и в ФП программе) таких случаев очень немного в общей массе кода, а в императивной программе они повсеместны.
Оно и есть всеобъемлющее. Это теоретический фундамент программирования вообще.
Ну как неотличимым? По коду сразу видно. А результат, конечно, тот же самый.
А это и есть псевдоним правой части, коль скоро нет побочных эффектов. Имя является псевдонимом значения, а значение является псевдонимом способа своего вычисления.
Наверняка там сам ассерт определён специфически.
Я посмотрел вскользь книжку Филда и Харрисона. Как я и подозревал, они просто излагают невнятно. Когда они пишут, что функции не могут изменить среду вычислений, то подразумевают при этом внешнюю для конкретной функции среду, то есть отсутствие побочных эффектов. Это никак не мешает функции менять среду внутри себя, что они и иллюстрируют оператором
letсвоего языка Hope.Макбук очень сложно заставить работать с закрытой крышкой, а кроме того, он не предназначен для работы с постоянной значительной нагрузкой. Будет нагреваться, шуметь и тормозиться.
Я, вроде, не возражал против обучения типам. Я говорил о декларации типов переменных в языках вроде Паскаля и Си.
Не читал эту книжку, поэтому не могу никак прокомментировать. Вообще, многие академические издания зачастую страдают оторванностью от реальности и собственным языком, понятным только авторам.
Является и может, конечно. Простейшим способом изменения окружения является само по себе применение функции (в просторечии – функциональный вызов). Когда мы пишем:
то здесь в окружении выражения
exprзначение символаxменяется на1. Это и есть самая основа лямбда-исчисления, бета-редукция (с несущественной для нас точностью до порядка вычислений).Тождественно то же самое (немедленное применение лямбда-выражения) для удобочитаемости можно записать в форме:
что уже очень напоминает присваивание в императивных языках.
Другое дело, что в ФП не принято злоупотреблять изменением нелокального окружения, то есть, в частности, неограниченно длящимся присваиванием. Хотя само по себе определение функции как раз и является примером изменения внешнего окружения – присваиванием имени функции в (чаще всего) глобальном контексте значения, представляющего собой её тело:
то же самое, что
или
то есть самое настоящее определение переменной и присваивание значения.
В том, что связь исходных данных и результата (т.е. программа) представляется как суперпозиция применения функциональных форм.
Состояние окружения – это формально определённый теоретический термин, а состояние программы – практический программистский. Разница между ними всё же есть, потому что к состоянию окружения относятся также данные, внешние по отношению к программе – содержимое файлов, состояние внешних устройств, действия пользователя и т.п.
Я не специалист в области реактивного программирования, поэтому могу что-то изложить неверно. В моём понимании, реактивное программирование – это парадигма операционной семантики, то есть способа выполнения программы. В своей основе реактивное программирование запросто может опираться на функциональное программирование, как парадигму денотационной сематики (т.е. описания связи между входом и выходом). Само по себе ФП не подразумевает какую-то конкретную последовательность действий.
Тут мы увязаем в тонкостях формулировок. Смотря что вы понимаете под переменными и оператором присваивания. В таком виде, как в императивном программировании, их нет (точнее, их не принято применять в функциональном стиле – примерно как с
goto). Вместе с тем, чем вам описанная выше формаletхуже переменных с присваиванием? Скажу сразу, что ничем не хуже, так как именно лямбда-исчисление является теоретическим фундаментом любого программирования, в том числе и императивного.Код также может быть исходными данными для рефлексии. Например, в компиляторе, анализаторе кода или самомодифицирующейся программе.
А я и не стал бы спорить с этим утверждением.
Хорошая задача в том плане, что по глубине ответа на вопрос “почему так происходит?” можно делать определённые выводы.
Ещё можно было бы спросить, с какими дробями такое сравнение гарантированно будет работать.
Возможно, в данном конкретном случае в компиляторе C++, векторизация и не будет выполняться. Но это несущественно вне рамок изучения машинно-зависимой оптимизации, то есть гораздо более глубокого и узкого знания. Я считаю, что обучающимся на первом этапе нужно сосредоточиться на денотационной семантике, то есть на том, что, собственно, они хотят получить. На основных паттернах кодирования в выбранном языке. А уж потом в деталях разбираться, как это происходит.
Можно выразить через переходы, можно через рекурсию, можно через аппликацию (макроподстановку). Да хоть через какой-нибудь аналоговый регулятор. Я студентам как раз объяснял возможность выражения алгоритма разными способами.
Вы себе можете, конечно, представлять семантику этого процесса в виде цикла, но никакого цикла там нет. Есть действия над структурой данных, которые можно представить элементарной операцией, а можно повторяющимися переходами, циклом, рекурсией и бог весть как ещё. Вы с детства познакомились с циклом, как конструкцией структурного программирования, и представляете там его себе, но его там нет ни на каком уровне рассмотрения (разве что, может, какая-то конкретная реализация стандартной библиотеки может быть написана на C/C++, и там в исходном коде будет цикл). С тем же успехом можно себе представлять рекурсию.
Какой-то компилятор в определённых условиях может подставить одну векторную операцию.
Форт – это язык для обучения студентов написанию интерпретатора форта на другом языке :)