[Haskell-cafe] seems like I'm on the wrong track

Stephen Tetley stephen.tetley at gmail.com
Wed Dec 2 07:58:17 EST 2009

Hi Mike

There used to be some slides available commenting on Haskore's CSound
interface. But they seem to have vanished (I have a copy rendered to
pdf when they were available). Like all slide presentations there's a
lot of reading between the lines to get a good picture after the fact:

http://plucky.cs.yale.edu/cs431/HasSoundNEPLS-10-05.ppt  -- vanished

Maybe you're doomed to frustration though trying to implement your
system in "Haskell". For the argument I'm about to make, I'd say a
working programming language has two things - syntax, semantics and
libraries and a repertory of prior art. Stateful programming clearly
has some syntax burden in Haskell, stateful monadic programming has
some benefit of 'stratification' - you have precise control of 'what
state is where'. It's a matter of taste whether you like Python's
flexibility or Haskell's, erm, 'locality' (precision?).

As for the second half of what you get from a programming language,
your system description frames what you want to do with an emphasis on
dynamic aspects. This seems a good way off from the prior art in
Haskell. For instance there are Haskell synthesizers - George
Giorgidze's yampa-synth and Jerzy Karczmarczuk's Clarion (actually in
Clean, but near enough). Here you build signal processing modules -
unit generators, of course - Yampasynth uses arrows to do this Clarion
uses infinite streams. With both you would build a synthesizer
statically from unit generators and somehow run it to produce

There is also the prior art of embedded hardware description
languages, Lava, Hydra, Wired, Gordon Pace's HeDLa, soon Kansas Lava.
One could view constructing synthesizers from unit generators as
usefully analogous to constructing circuits - and certainly if you are
'compiling' to another system to do do the real work (in your case
CSound) the papers on Wired, HeDLa, and Kansas Lava have useful
insights on 'offshoring' compilation. But again these systems have
strong bearing in the 'static description' of a circuit rather than
its dynamical operation.

If neither of those 'genres' is close to what you really want to do
then the Haskell prior art is running a bit thin. You could look at
dataflow - the dynamic PD / Max systems are often describe as a
dataflow systems. There are some outposts in Haskell of dataflow
programming - Gordon Pace has an embedding of Lustre available from
his homepage and there has been work on dataflow programming via
comonads. There is also reactive programming, but musical examples are
thin on the ground
(nonexistent?) so it might be a long haul to come up with something.

Best wishes


[1] This seems a bit of a paraphrase of Yampasynth - which I think
allows you to
define a synthesizer statically in code, but then play it interactively.

2009/12/2 Michael Mossey <mpm at alumni.caltech.edu>:
> Thanks for the reply. Was there something specific you were referring to, or
> just the idea that he wrote Haskore? Haskore is not very closely related to
> what I'm trying to do.

More information about the Haskell-Cafe mailing list