[racket] Architecture advice for new project

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120515/e8ec06be/attachment.html>