> here was an hidden vibe from the PLT research guys that DAGs were limiting compared to a usual functional programming language. I never knew why, and now I'm even more curious.
I think the key insight is that in a functional programming language functions need to be able to be values that flow through the graph and that can be dynamically created. Supporting lazy evaluation and expressing data-flow is insufficient to make a language truly functional.
The challenge I would give a data-flow language to see if it is truly functional is this: can you create a general "compose function" or "partial apply" node in these packages that works based on run-time inputs.
I hear you, but since many FP languages are turned into DAGs before compilation, I always thought CGI software just didn't think about 'first class' graphs and thus no meta level operators. It would be very interesting to try though.
Comments
I think the key insight is that in a functional programming language functions need to be able to be values that flow through the graph and that can be dynamically created. Supporting lazy evaluation and expressing data-flow is insufficient to make a language truly functional.
The challenge I would give a data-flow language to see if it is truly functional is this: can you create a general "compose function" or "partial apply" node in these packages that works based on run-time inputs.
I hear you, but since many FP languages are turned into DAGs before compilation, I always thought CGI software just didn't think about 'first class' graphs and thus no meta level operators. It would be very interesting to try though.