I guess you probably need to step back and understand how things tend to mutate this hash and look for another construct that more accurately captures the interesting use cases for mutating the hash. That is, hash mutation is a kind of do-anything assembly language and until you have a good handle on what &quot;anything&quot; might be in the usual case, then you can design a construct to replace it. (Also, you will find that there are invariants that you can express too, and even check when you move away from the hashs (I hope).)<br>
<br>My $0.02,<div>Robby<br><div><br></div><div>On Tuesday, May 15, 2012, Chad Albers  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br><br>I&#39;m working on project to port the Ruby Rack framework to Racket scheme.  If you&#39;re not familiar with Rack,  it creates a layer to manage the http response/requests, and a level of abstraction to build a chained list of middle ware clients - each calling the next in chain.  <br>

<br>Switching from from Ruby&#39;s OOP paradigm to Scheme&#39;s more functional paradigm, a problem has presented itself that I would like some advice on.<br><br>In the Rack middleware in the chain, each piece of the middleware receives a hash which encapsulates the response/requests, and the middleware mutates this hash depending on the functionality it adds.<br>

<br>I could port this hash exchange in my Racket implementation, but I have an aversion to the side effects inherently in mutating this hash.   My question, then, is does anyone have a more functional approach to how I could implement this middleware chain?<br>

<br>Any advice anyone could offer would be greatly appreciated.  I&#39;m going to open sourcing the project soon.<br clear="all">--<br>Chad<br><br>
</blockquote></div></div>