Используется ли FС++ для любых проектов с открытым исходным кодом?

Библиотека FC++ обеспечивает интересный подход к поддержке концепций функционального программирования на С++.

Краткий пример из FAQ:

take (5, map (odd, enumFrom(1)))

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

Я видел недавнюю статью об этом, и она была кратко упомянута в некоторых ответах на stackoverflow, но я не могу найти никаких использование его в дикой природе.

Есть ли какие-либо проекты с открытым исходным кодом, активно использующие FС++? Или любая история проектов, которые использовали ее в прошлом? Или у кого-то есть личный опыт?

Здесь есть раздел "Клиенты" на веб-сайте, но единственная активная ссылка - на другую библиотеку тех же авторов (LС++).

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

Я знаю, что библиотеки STL и Boost уже обеспечивают поддержку многих концепций FP - это может быть более практичным подходом. Я также знаю о других перспективных подходах к генерации кода аудио DSP-кода из функциональных языков, таких как FAUST или Haskell пакет синтезаторов.

Ответ 1

Я являюсь основным оригинальным разработчиком FС++, но я не работал над ним более шести лет. В то время я не поддерживал С++/boost, поэтому я не знаю, как сейчас сравнивает FС++. Новый С++ стандарт (и реализации, как VС++) имеет немного вещей, как лямбда и типа вывода помощи, что делает некоторые из того, что в там тоо. Тем не менее, могут существовать полезные бит, такие как ленивые типы списков и комбинаторы типа Haskell (и аналогично названные). Поэтому я предполагаю попробовать и посмотреть.

(Поскольку вы упомянули в реальном времени, я должен упомянуть, что в списках используется подсчет ссылок, поэтому, если вы отбросите "длинный список", в деструкторе может быть нетривиальное ожидание, так как все подсчеты ячеек идут до нуля. Я думаю, что в сценариях потоковой передачи с бесконечными потоками/списками это не проблема, так как обычно вы просто tail входите в поток и только освобождаете вещи node за раз, когда вы поток.)

Ответ 2

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

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

Пример из FС++:

struct Insert : public CFunType<int,List<int>,List<int> > {
   List<int> operator()( int x, const List<int>& l ) const {
      if( null(l) || (x > head(l)) )
         return cons( x, l );
      else
         return cons( head(l), curry2(Insert(),x,tail(l)) );
   }
};

struct Isort : public CFunType<List<int>,List<int> > {
   List<int> operator()( const List<int>& l ) const {
      return foldr( Insert(), List<int>(), l );
   }
};

Я считаю, что это пытается выразить следующий код Haskell:

-- transliterated, and generalized
insert :: (Ord a) => a -> [a] -> [a]
insert x [] = [x]
insert x (a:as) | x > a = x:a:as
                | otherwise = a:insert x as

isort :: (Ord a) => [a] -> [a]
isort = foldr insert []

Я оставлю вас судить о сложности подхода по мере роста вашей программы.

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