Documentation
This data type is for parameters of parameterized signal generators and causal processes.
It is better than using plain functions of type p > a
since it allows for numeric instances
and we can make explicit,
whether a parameter is constant.
We recommend to use parameters for atomic types.
Although a parameter of type T p (a,b)
is possible,
it means that the whole parameter is variable
if only one of the pair elements is variable.
This way you may miss optimizations.
Arrow T 

Category T 

Monad (T p)  
Functor (T p)  Useful for splitting 
Applicative (T p)  Useful for combining 
Eq a => Eq (T p a)  
Fractional a => Fractional (T p a)  
Num a => Num (T p a)  
Show a => Show (T p a)  
C a => C (T p a)  
C a => C (T p a)  
C a => C (T p a)  
C a => C (T p a)  
C a => C (T p a) 
value :: MakeValueTuple tuple value => T p tuple > value > valueSource
The call value param v
requires
that v
represents the same value as valueTupleOf (get param p)
for some p
.
However v
might be the result of a load operation
and param
might be a constant.
In this case it is more efficient to use valueTupleOf (get param undefined)
since the constant is translated to an LLVM constant
that allows for certain optimizations.
This is the main function for taking advantage of a constant parameter
in lowlevel implementations.
For simplicity we do not omit constant parameters in the parameter struct
since this would mean to construct types at runtime and might become ugly.
Instead we just check using value
at the according places in LLVM code
whether a parameter is constant
and ignore the parameter from the struct in this case.
In many cases there will be no speed benefit
because the parameter will be loaded to a register anyway.
It can only lead to speedup if subsequent optimizations
can precompute constant expressions.
Another example is drop
where a loop with constant loop count can be generated.
For small loop counts and simple loop bodies the loop might get unrolled.