Re: [Haskell-cafe] Sample rate inference

Henning Thielemann wrote:

I want to connect several functions for signal processing. The typical case is that in a network of signal processor there are parts that are already discretized such as sampled sounds, and there are processors with no particular sample rate such as amplifiers. But when it comes to computation each processor must choose a sample rate for processing. There are also processors for converting sample rates. They divide the network into components of equal sample rate. The computation sample rate should be propagated through the network as follows: If in a component of equal sample rate some processors have the same fixed sample rate, all uncertain processors must adapt that. If some processors have different fixed sample rates this is an error. If no processor has a fixed sample rate, the user must provide one manually. To me this looks very similar to type inference. Is there some mechanism in Haskell which supports this programming structure?

If you define a class for sample rates, and an instance for each possible sample rate, then you could use type inference, e.g.

class Rate a where rate :: a -> Int;

data Rate22050 = Rate22050; instance Rate Rate22050 where rate _ = 22050;

data Rate44100 = Rate44100; instance Rate Rate44100 where rate _ = 44100;

data (Rate a) => Stream a = ...

type unaryProcessor a = (Rate a) => Stream a -> Stream a type binaryProcessor a = (Rate a) => Stream a -> Stream a -> Stream a ...

resample :: (Rate a, Rate b) => Stream a -> Stream b resample s = ...

Supporting arbitrary sample rates would require being able to construct a distinct type for every possible sample rate; e.g. using Church numerals:

data Rate0 = Rate0 instance Rate Rate0 where rate _ = 0;

data (Rate a) => RateN a instance (Rate a) => Rate (RateN a) where rate (RateN x) = 1 + rate x;

fourHertzFilter :: unaryProcessor (RateN (RateN (RateN (RateN Rate0)))) fourHertzFilter = ...

I doubt that this specific example wouldn't work in practice (the type inference would probably give the compiler a heart attack), but you could presumably construct an equivalent mechanism using base-N numerals. -- Glynn Clements