Используется ли 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 []
Я оставлю вас судить о сложности подхода по мере роста вашей программы.
Я считаю создание кода более привлекательным. Вы можете ограничить себя миниатюрным подмножеством целевого языка, что упрощает перенос на другой целевой язык. Стоимость абстракции на честном функциональном языке почти равна нулю, поскольку в конце концов они были разработаны для этого (так же, как абстрагирование по императивному коду на императивном языке довольно дешево).