Please check out Paul Hudak's page. http://cs-www.cs.yale.edu/homes/hudak-paul/ On Tue, 01 Dec 2009 17:01:29 -0800, you wrote:

Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way.

I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong.

To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy.

In this one example, in a OO way of thinking, I have data called AssignedNumbers that assigns integers to unique strings and keeps track of the used integers and next available integer (the choice of available integer could follow a number of conventions so I wanted to hide that in an ADT.) So it has an associated function:

getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers)

What getNumber does is:

- check if the string already has a number assigned to it. If so, return that number.

- if not, pick the next available number.

- in all cases, return the possibly changed state of AssignedNumbers

Then in a larger data structure, it contains fields of type AssignedNumbers. Like

data MusicStuff = MusicStuff { oscillatorNumbers :: AssignedNumbers , tableNumbers :: AssignedNumbers , ... }

I'm using MusicStuff in a State monad, so I might write a function like

doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) doSomeMusicStuff aString1 aString2 = do ms <- get (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) (t1,newTabNums) = getNumber aString2 (tableNumbers ms) put ms { oscillatorNumbers = newOscNums , tableNumbers = newTabNums } return (o1,t1)

For what it does, this is extremely verbose and filled with distracting visual content. And this is just a very simple example---my real problem is several times more state-ful. Is there a better way?

Note that in Python it would be a method

def doMusicStuff( self, s1, s2 ) : return (self.oscillatorNumbers.next(s1), self.oscillatorNumbers.next(s2))

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Casey

On Tue, Dec 1, 2009 at 8:01 PM, Michael P Mossey wrote:

Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way.

I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong.

To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy.

In this one example, in a OO way of thinking, I have data called AssignedNumbers that assigns integers to unique strings and keeps track of the used integers and next available integer (the choice of available integer could follow a number of conventions so I wanted to hide that in an ADT.) So it has an associated function:

getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers)

What getNumber does is:

- check if the string already has a number assigned to it. If so, return that number.

- if not, pick the next available number.

- in all cases, return the possibly changed state of AssignedNumbers

Then in a larger data structure, it contains fields of type AssignedNumbers. Like

data MusicStuff = MusicStuff { oscillatorNumbers :: AssignedNumbers , tableNumbers :: AssignedNumbers , ... }

I'm using MusicStuff in a State monad, so I might write a function like

doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) doSomeMusicStuff aString1 aString2 = do ms <- get (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) (t1,newTabNums) = getNumber aString2 (tableNumbers ms) put ms { oscillatorNumbers = newOscNums , tableNumbers = newTabNums } return (o1,t1)

For what it does, this is extremely verbose and filled with distracting visual content. And this is just a very simple example---my real problem is several times more state-ful. Is there a better way?

As a quick observation, you might consider changing getNumber to be something like: nextNumber :: String -> NumberGroup -> State MusicStuff Int where NumberGroup is something like data NumberGroup = OscNums | TabNums |... nextNumber updates the appropriate set of numbers in MusicStuff and returns the number. doSomeMusicStuff then becomes: doSomeMusicStuff aString1 aString2 = (,) `liftM` nextNumber OscNums `ap` nextNumber TabNums or better yet (applicatively) doSomeMusicStuff aString1 aString2 = (,) <$> nextNumber OscNums <*> nextNumber TabNums

Am Mittwoch 02 Dezember 2009 02:01:29 schrieb Michael P Mossey:

Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way.

I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong.

If you want to do something very stateful, it is a bit cumbersome in Haskell. Perhaps it is the wrong approach and you can do it with much less state. Or perhaps, this is possible, too, it is not a task for which Haskell is well suited. Or perhaps you're really doing it wrong because of lack of experience.

To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy.

In this one example, in a OO way of thinking, I have data called AssignedNumbers that assigns integers to unique strings and keeps track of the used integers and next available integer (the choice of available integer could follow a number of conventions so I wanted to hide that in an ADT.) So it has an associated function:

getNumber :: String -> AssignedNumbers -> (Int,AssignedNumbers)

Yeah, that screams State Monad.

What getNumber does is:

- check if the string already has a number assigned to it. If so, return that number.

- if not, pick the next available number.

- in all cases, return the possibly changed state of AssignedNumbers

Then in a larger data structure, it contains fields of type AssignedNumbers. Like

data MusicStuff = MusicStuff { oscillatorNumbers :: AssignedNumbers , tableNumbers :: AssignedNumbers , ... }

I'm using MusicStuff in a State monad, so I might write a function like

doSomeMusicStuff :: String -> String -> State MusicStuff (Int,Int) doSomeMusicStuff aString1 aString2 = do ms <- get (o1,newOscNums) = getNumber aString1 (oscillatorNumbers ms) (t1,newTabNums) = getNumber aString2 (tableNumbers ms) put ms { oscillatorNumbers = newOscNums , tableNumbers = newTabNums } return (o1,t1)

For what it does, this is extremely verbose and filled with distracting visual content. And this is just a very simple example---my real problem is several times more state-ful. Is there a better way?

If you're doing that in many places, factor out the methods getOscillatorNumber :: String -> State MusicStuff Int getOscillatorNumber str = do ms <- get let on = oscilatorNumbers ms (o1,newOn) = getNumber str on put (ms{ oscillatorNumbers = newOn }) return o1 same for tableNumbers etc. Then doSomeMusicStuff aString1 aString2 = do o <- getOscillatorNumber aString1 t <- getTableNumber aString2 return (o,t) and the verbosity is moved to one place. That isn't worthwhile for seldomly used stuff, of course.

Note that in Python it would be a method

def doMusicStuff( self, s1, s2 ) : return (self.oscillatorNumbers.next(s1), self.oscillatorNumbers.next(s2))

Yeah, mutability gives brevity here.

Michael P Mossey wrote:

Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way.

I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong.

Stop the presses! I had an idea to make this more functional in style. Do it through multiple passes. The idea is that we've got a list of musical events as input ("Node" is a term some algorithmic composers use, so I will use type Node.) In fact we could have other types of input data too, so I might need the algebraic type data InputType = Node ... | CSoundSource ... etc. Then we make a pass through the nodes using map concat to produce a bunch of Output data. data Output = OIStatement ... | OInstrName InstrName -- represents an instrument name -- (ultimately we need a number, but -- won't know that # during first -- pass) | OInstrNum Int -- when we compute an instrument -- number, this will replace the above | OMixer MixerName ... we have a function processInput: processInput :: InputType -> [Output] This expresses the idea that a single input may result in the generation of several pieces of output data. The first pass is just a concat map firstPass :: [InputType] -> [Output] firstPass = concatMap processInput In translating an InputType datum, we look at it "in isolation"---here it sits in front of us in the stream, and we haven't maintained a lot of state---and we translate it to some intermediate Output form, making all specific calculations or substitutions possible at that given time and context. Then further passes are needed, many of which are folds. For example, to assign the instrument number I have some kind of NumberDatabase, but now my dealings with it are limited to a single fold. assignNumbers :: [Output] -> NumberDatabase assignNumbers outputList = foldl g newNumberDatabase outputList where g outputDatum numberDb = case outputDatum of OInstrName n -> ... ah! unassigned name! update db _ -> numberDb -- just return unchanged All the rest of the processing can be done via filters, folds, and maps. Does this seem more functional in style? Thanks, Mike

Michael P Mossey schrieb:

Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way.

I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong.

To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy.

There are currently two public interfaces to CSound: http://hackage.haskell.org/packages/archive/haskore/0.1/doc/html/Haskore-Int... http://hackage.haskell.org/package/hCsound You may also want to use SuperCollider: http://hackage.haskell.org/package/hsc3