[racket] Architecture advice for new project

[Chad Albers]

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

[Danny Yoo]

> 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.

Could each middleware layer return the updated hash value? Racket has
functional hash tables alongside mutable ones.

http://docs.racket-lang.org/reference/hashtables.html#(def._((quote._~23~25kernel)._hash-set))
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Chad Albers]

Definitely. Using Racket's hashes, I can duplicate the same functionality.

But this hash mechanism bothers me, because I see a informal
convention developing in Rack middleware, where the middleware starts
injecting it's own state into the hash, with hacky namespaces on the
keys to prevent key collisions. I would like to avoid that.

Just wondering if anyone had an alternative suggestion.

--
Chad Albers

[Raoul Duke]

On Tue, May 15, 2012 at 11:00 AM, Chad Albers <cal...@neomantic.com> wrote:
> injecting it's own state into the hash, with hacky namespaces on the
> keys to prevent key collisions.  I would like to avoid that.

off the top of my head, it seems like if there is sharing, yet you
want to avoid collisions, then you either have 1 hash with namespacing
of keys involved, or you have N hashes, one for each namespace?

[Danny Yoo]

On Tuesday, May 15, 2012, Chad Albers wrote:

Definitely.  Using Racket's hashes, I can duplicate the same functionality.

But this hash mechanism bothers me, because I see a informal
convention developing in Rack middleware, where the middleware starts
injecting it's own state into the hash, with hacky namespaces on the
keys to prevent key collisions.  I would like to avoid that.

One of the things I notice about Racket's runtime library design is the use of opaque values to avoid collisions.  For example, the way that structure properties work is to create a unique value, a structure type property descriptor, to be used as the "key".

     http://docs.racket-lang.org/reference/structprops.html  

The advantage of this versus using a plain symbol is that the association doesn't depend on the symbolic representation of the property's name, so there's no collision potential between properties that are named similarly.  Maybe you can do something similar?

[Robby Findler]

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:

[Chad Albers]

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

____________________