c++ - opensource - sistemas open source

¿FC++ es utilizado por cualquier proyecto de código abierto?

Question

La biblioteca FC ++ proporciona un enfoque interesante para admitir conceptos de programación funcional en C ++.

Un breve ejemplo de las preguntas frecuentes :

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

FC ++ parece tomar mucha inspiración de Haskell, hasta el punto de reutilizar muchos nombres de funciones del preludio de Haskell.

He visto un artículo reciente al respecto, y se ha mencionado brevemente en algunas respuestas sobre stackoverflow, pero no puedo encontrar ningún uso de él en la naturaleza.

¿Hay algún proyecto de código abierto que use activamente FC ++? ¿O algún historial de proyectos que lo usaron en el pasado? ¿O alguien tiene experiencia personal con eso?

Hay una sección de Clientes en el sitio web, pero el único enlace activo es para otra biblioteca de los mismos autores (LC ++).

Como antecedente: estoy buscando escribir complementos de audio de baja latencia usando las API C ++ existentes, y estoy buscando herramientas que me permitan escribir código conciso en un estilo funcional. Para este proyecto, quiero utilizar una biblioteca C ++ en lugar de utilizar un lenguaje separado, para evitar la introducción de enlaces FFI (debido a la complejidad) o la recolección de basura (para mantener el límite superior de latencia en el rango de menos de milisegundos).

Soy consciente de que las bibliotecas STL y Boost ya brindan soporte de muchos conceptos de PF: este puede ser un enfoque más práctico. También conozco otros enfoques prometedores para la generación de códigos de código DSP de audio a partir de lenguajes funcionales, como el proyecto FAUST o el paquete de sintetizador Haskell.

Answer 1

Esta no es una respuesta adecuada a su pregunta, pero mi experiencia con la incrustación de estilo funcional en lenguajes imperativos ha sido horrible. Si bien el código puede ser casi tan conciso, conserva la complejidad del razonamiento que se encuentra en los idiomas imperativos.

La complejidad de la incrustación generalmente requiere el conocimiento más íntimo de los detalles y casos de esquina del idioma. Esto aumenta en gran medida el costo de la abstracción, ya que estas cosas siempre deben tenerse en cuenta cuidadosamente. Y con un costo de abstracción tan alto, es más fácil simplemente poner una función de efecto lateral en un generador de flujo diferido y luego morir de errores sutiles.

Un ejemplo de FC ++:

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 );
   }
};

Creo que esto está tratando de expresar el siguiente código 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 []

Lo dejaré para juzgar la complejidad del enfoque a medida que su programa crezca.

Considero que la generación de código es un enfoque mucho más atractivo. Puede limitarse a un subconjunto minúsculo de su idioma de destino, lo que facilita el acceso a un idioma de destino diferente. El costo de la abstracción en un lenguaje funcional honesto es casi cero, ya que, después de todo, fueron diseñados para eso (al igual que la abstracción sobre el código imperativo en un lenguaje imperativo es bastante barata).

Answer 2

Soy el principal desarrollador original de FC ++, pero no he trabajado en él en más de seis años. No me he mantenido al día con C ++ / boost mucho en ese momento, así que no sé cómo se compara FC ++ ahora. El nuevo estándar de C ++ (y las implementaciones como VC ++) tiene un poco de cosas como lambda y la ayuda de inferencia de tipo que hace que algo de lo que está allí sea discutible. Sin embargo, aún puede haber bits útiles, como los tipos de lista diferida y los combinadores similares a Haskell (y con nombres similares). Así que supongo que pruébalo y mira.

(Como mencionas en tiempo real, debo mencionar que las listas usan recuento de referencias, por lo que si "descartas" una lista larga puede haber una espera no trivial en el destructor ya que todos los recuentos de ref de las celdas van a cero. Creo que normalmente en los escenarios de transmisión con infinitas secuencias / listas esto no es un problema, ya que normalmente estás simplemente yendo a la corriente y solo desasignando elementos de un nodo a la vez mientras transmites).