I'd like to thank everyone for their advice. I'm going to definitely
explore the Racket's webserver and step back and look at existing Rack
middleware implementations to determine if I can use a different
construct besides hash-manipulations.
--
Chad
On Tue, May 15, 2012 at 8:23 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> 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 "anything" 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).)
>> My $0.02,
> Robby
>> On Tuesday, May 15, 2012, Chad Albers wrote:
>>>> Hi,
>>>> I'm working on project to port the Ruby Rack framework to Racket scheme.
>> If you'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.
>>>> Switching from from Ruby's OOP paradigm to Scheme's more functional
>> paradigm, a problem has presented itself that I would like some advice on.
>>>> 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.
>>>> 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?
>>>> Any advice anyone could offer would be greatly appreciated. I'm going to
>> open sourcing the project soon.
>> --
>> Chad
>>>