FRP - Fluxos de eventos e sinais - o que se perde ao usar apenas sinais?

Nas implementações recentes do Classic FRP, por exemplo, banana reativa, existem fluxos e sinais de eventos, que são funções de etapa (a banana reativa os chama de comportamentos, mas são funções de etapa). Percebi que o Elm usa apenas sinais e não diferencia entre sinais e fluxos de eventos. Além disso, reactive-banana permite ir de fluxos de eventos a sinais (editado: e é meio possível agir sobre comportamentos usando reactimate ', embora isso não seja considerado uma boa prática), o que significa que, em teoria, poderíamos aplicar todo o fluxo de eventos combinadores em sinais / comportamentos, primeiro convertendo o sinal em fluxo de eventos, aplicando e depois convertendo novamente. Portanto, como é geralmente mais fácil usar e aprender apenas uma abstração, qual é a vantagem de ter sinais e fluxos de eventos separados? Há algo perdido no uso de apenas sinais e na conversão de todos os combinadores de fluxo de eventos para operar com sinais?

edit: A discussão tem sido muito interessante. As principais conclusões que tirei da discussão são que comportamentos / fontes de eventos são necessários para definições recursivas mutuamente (feedback) e para que uma saída dependa de duas entradas (um comportamento e uma fonte de eventos), mas só causa uma ação quando uma um deles muda (<@>).

questionAnswers(4)

yourAnswerToTheQuestion