[racket] Scheme Design Patterns

Luckily, you've asked the person who wrote that code!

There's a few things going on here...

1. read-request is just provided for backwards compatibility, the Web
server itself ONLY use make-ext:read-request (as renamed to
make-read-request on line 23); for instance, see
https://github.com/plt/racket/blob/v5.3.4/collects/web-server/web-server.rkt#L62

The reason is that we want to give you the option to never use HTTP/1.1 and
always close a connection and that is part of request handling.

That's the first part of make-ext:read-request, or rather why we have
make-read-request at all.

2. Next, we want to make sure that whenever read-request throws an error,
it kills the connection (which will in turn kill the Web server thread and
free resources). However, we don't want to clutter the definition of
make-read-request with these details, particularly because the test suite
wants to turn this behavior off for various reasons and uses require/expose
to get the /real/ make-read-request.

So, in all, I wouldn't call this a use of a 'pattern' but rather a weird
hodge-podge of the stuff from the past decade of maintaining the Web server
:)

Jay




On Tue, Sep 10, 2013 at 7:28 PM, Chad A. <chad at neomantic.com> wrote:

> Thanks for your help.  I was sure it would have something to do with
> capturing bindings in a closure, but the code in question seems to
> lack a closure.  Maybe I'm missing something, though.
>
> Here's the code:
>
> https://github.com/plt/racket/blob/v5.3.4/collects/web-server/http/request.rkt#L102
> .
>
> Thanks again,
> Chad
>
>
> --
> Chad Albers
> http://www.neomantic.com
> (pgp signature available on request)
>
>
> On Tue, Sep 10, 2013 at 10:16 PM, Jay McCarthy <jay.mccarthy at gmail.com>
> wrote:
> > I think more context would be useful to know why a specific case is
> useful.
> > But, I'll do my best with none...
> >
> > By using functions like this, you can control when things happen and what
> > they can see. For instance...
> >
> > (define (make-worker)
> >   (define a (build-list 10 add1)
> >   (define (worker)
> >     ;; a is visible to 'worker'
> >     (+ (first a) 10))
> >   worker)
> >
> > ;; a is not visible here
> >
> > ;; .... you do some other work ...
> >
> > ;; and only now do you run the construction of a
> >
> > (define some-worker
> >   (make-worker))
> >
> > ;; .... you do some other work before getting the contents
> >
> > (define answer
> >   (some-worker))
> >
> > This is all because closures are a basic form of objects---their
> environment
> > values are their "private fields" and "apply" is their one method. Thus,
> any
> > time that you would find OO useful, you might find a pattern like this
> > useful. Especially when you don't want to go whole hog and use the
> > object/class system from racket/class
> >
> > Jay
> >
> >
> >
> >
> > On Mon, Sep 9, 2013 at 8:24 PM, Chad A. <chad at neomantic.com> wrote:
> >>
> >> Hi,
> >>
> >> I'm wondering if someone can help me understand a design-pattern that
> >> I have noticed in the Racket code base. (I'm teaching myself, so
> >> review other people's code alot).
> >>
> >> I've seen this pattern..which is a bit contrived.
> >>
> >> (define (say-hello)
> >>   (define (display-hello)
> >>      (display "hello")))
> >>
> >> So this produces a producer, and to evaluate it I would need to write
> >> ((hello)) => "hello"
> >>
> >> But then I see this...
> >>
> >> (define say-hi (say-hello)).  When I evaluate (say-hello), I get
> >> "hello".  Obviously, the definition of "say-hi" contains the evaluated
> >> (say-hello) than returns the 'display-hello' procedure to be
> >> evaluated.
> >>
> >> My question is...why would I want to write the code like this? 3
> >> definitions have been created which could easily be compressed into
> >> one.
> >>
> >>  (I also see nothing in the code I'm looking at that appears to
> >> capture a binding via a closure).
> >>
> >> Thanks in advance for any insights someone can share.
> >>
> >> Chad
> >> ____________________
> >>   Racket Users list:
> >>   http://lists.racket-lang.org/users
> >
> >
> >
> >
> > --
> > Jay McCarthy <jay at cs.byu.edu>
> > Assistant Professor / Brigham Young University
> > http://faculty.cs.byu.edu/~jay
> >
> > "The glory of God is Intelligence" - D&C 93
>



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130910/9e30643f/attachment.html>