Content deleted Content added
No edit summary |
connection to Arrows |
||
Line 134:
It is interesting to note the difference between the block diagram and the generated C++ code.
As already said, the key idea here is not to compile the block diagram literally, but the mathematical function it denotes. Modern C/C++ compilers too don’t compile programs literally. But because of the complex semantic of C/C++ (due to side effects, pointer aliasing, etc.) they can’t go very far in that direction. This is a distinctive advantage of a purely functional language: it allows compilers to do very advanced optimisations.
==Connection to Arrows==
The Faust semantics is almost the same as that of [[Haskell (programming language)|Haskell]]'s [[Arrow (computer science)|Arrows]] type class.
However, the Arrow type class is not bound to signal processors.
{| class="wikitable"
|+ Equivalences between FAUST and Arrow combinators
| <code>f~g</code> || <code>loop ((\(a,b) -> (b,a)) ^>> f >>> id &&& (delay>>>g))</code> where <code>delay</code> is not a method of the <code>Arrow</code> type class, but is specific to signal processing arrows
|-
| <code>f,g</code> || <code>f***g</code>
|-
| <code>f:g</code> || <code>f>>>g</code>
|-
| <code>f<:g</code> || <code>f>>^h>>>g</code> with appropriate function <code>h</code> (or <code>&&&</code> in special cases)
|-
| <code>f:>g</code> || <code>f>>^h>>>g</code> with appropriate function <code>h</code>
|}
The Arrow combinators are more restrictive than their FAUST counterparts,
e.g. the nesting of parallel composition is preserved
and inputs of the operands of <code>&&&</code> must match exactly.
This allows to assign types to Arrow combinators
and it prevents users from accidentally combining signal processors that do not match.
In contrast to that, FAUST's split and merge operators automatically fill missing channels.
==References==
| |||