> El 10 mar 2016, a las 11:09, Miguel Negrão 
> <miguel.negrao-li...@friendlyvirus.org> escribió:
> 
>> On 10-03-2016 15:56, amin...@gmail.com wrote:
>> Hi Miguel,
>>     Agreed that preserving state is crucial -- you don't want e.g. your 
>> volume jumping around every time you replace the node in the graph that 
>> represents volume.
>> 
>>     Midair differs for your WIP supercollider implementation a bit: you can 
>> replace individual sections of the graph, and the inner sections need not 
>> have the same types as long as the piece being inserted has the same type as 
>> what it's replacing. E.g a a graph that counts keypresses and adds 5 to the 
>> total:
>> 
>> foo :: SFlow GetChar Int
>> foo = sMap (+5) <<< sFold 0 (\_ -> (+1))
>> 
>> Can be replaced by one which returns the (accumulated) length of a string 
>> starting with the most-recent character:
>> 
>> bar :: SFlow GetChar Int
>> bar = sFold 0 (+) <<< sMap length <<< sMap (\(GetChar c) -> dropWhile (/=c) 
>> "foobarbaz")
>> 
>> ...even though the inner graph elements have different types and have a 
>> different "shape" -- so you're totally unconstrained by your previous 
>> decisions about the graph (segment).
> 
> Ok, I get it, that is indeed a different approach. I thought about doing
> similar also. But can you make any part of the graph a new hot-swappable
> node, or do you have to declare those nodes up-front ?  For instance
> could you change 'sMap length' in bar to a node ref while keeping the
> state of the fold ?
> 

Yes, you can! You'd say:

do nr <- mkNodeRef $ sMap length
   return $ sFold 0 (+) <<< nr <<< sMap baz

where
baz (GetChar c) = dropWhile (/=c) "foobarbaz"

(The actions are in IO; they can also be in STM)

Tom


> Best,
> Miguel
> 
> -- 
> 
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/4vZkaPsWqe92OxGk2A5Uuk
> 
> To leave Haskell Art, email haskell-...@group.lurk.org with the following 
> email subject: unsubscribe

-- 

Read the whole topic here: Haskell Art:
http://lurk.org/r/topic/4O3cSSEhhVCTjKqixzcJq

To leave Haskell Art, email haskell-...@group.lurk.org with the following email 
subject: unsubscribe

Reply via email to