Как это работает

Да, foldp хранит какое-то внутреннее состояние. Сохранение всей истории было бы расточительным и не делается.

Если вы используете foldp несколько раз в своем коде, выполняя разные действия или получая разные входные сигналы, то каждый экземпляр будет сохранять свое собственное локальное состояние. Пример:

import Keyboard

plus  = (foldp (\dir presses -> presses + dir.x) 0 Keyboard.arrows)
minus = (foldp (\dir presses -> presses - dir.x) 0 Keyboard.arrows)
showThem p m = flow down (map asText [p, m])
main  = lift2 showThem plus minus

Но если вы дважды используете результирующий сигнал от foldp, в вашей скомпилированной программе будет только один экземпляр foldp, результирующие изменения просто будут использованы в двух местах:

import Keyboard

plus  = (foldp (\dir presses -> presses + dir.x) 0 Keyboard.arrows)
showThem p m = flow down (map asText [p, m])
main  = lift2 showThem plus plus

Главный вопрос

Если это действительно так, то не является ли это нарушением принципов функционального программирования, поскольку main теперь поддерживает внутреннее состояние (или, по крайней мере, foldp)?

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

Но что такое изменчивое состояние? Что такое изменяемое значение? Это значение внутри программы, которое можно изменить. То есть может измениться. Это могут быть разные вещи в разное время. Ах, но мы же знаем, как Elm называет значения изменяющимися с течением времени! Это Signal.
Так что на самом деле Signal в Elm — это значение, которое может меняться со временем, и поэтому его можно рассматривать как переменную, изменяемое значение или изменяемое состояние. Просто мы очень строго управляем этим значением, разрешая только несколько хорошо выбранных манипуляций с Signals. Такие Signal могут быть основаны на других Signal в вашей программе, или поступать из библиотеки, или поступать из внешнего мира (подумайте о таких входных данных, как Mouse.position). И кто знает, как внешний мир дошел до этого сигнала! Таким образом, разрешить вашим собственным Signals основываться на прошлом значении Signals на самом деле нормально.

Заключение / TL;DR

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

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

Не думайте, что main оценивается многократно, каждый раз возвращая разные результаты. Signal концептуально представляет собой бесконечный список значений. main принимает бесконечный список стрелок клавиатуры в качестве входных данных и переводит его в бесконечный список элементов. Учитывая один и тот же список стрелок, он всегда будет возвращать один и тот же список элементов без побочных эффектов. Таким образом, на этом уровне абстракции это чистая функция.

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

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

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

Функциональные языки с переформулированными ограничениями могут свободно использовать изменяемые объекты, если они моделируются с использованием чистых функций. Отвечая на ваш вопрос, программы elm построены из чистых функций, поэтому, вероятно, это функциональный язык. Elm использует специальную структуру данных Signal для моделирования взаимодействия с внешним миром и внутреннего состояния, как и любой другой функциональный язык.