[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [plt-scheme] eval question




The reason Paul and I decided to parse the config table for the server was
that some people may wish to open emacs and just hack these kinds of files
on their own. This is particularly true for Apache where you are encoouraged
to do just that. So, we needed to make sure that the data is syntactically
in good shape and doesn't blow up on us as we start the server and if it is
in bad shape the code should inform the consumer what is wrong (though this
code doesn't do the greatest job and so I will have a chat with Paul).

-- Matthias

> -----Original Message-----
> From: owner-plt-scheme@fast.cs.utah.edu
> [mailto:owner-plt-scheme@fast.cs.utah.edu]On Behalf Of Benderjg2@aol.com
> Sent: Wednesday, June 05, 2002 11:14 PM
> To: plt-scheme@fast.cs.utah.edu
> Subject: Re: [plt-scheme] eval question
>
>
> In a message dated 6/5/2002 8:48:38 PM Central Daylight Time,
> matthias@ccs.neu.edu writes:
>
> > .[...] you may wish to turn
> >  this into a unit, and dynamically link in the unit. You could,
> >  for example, check its interface and make sure that you don't
> >  get strange things ...
>
> Having made use of this eval/load trick quite a bit myself, I
> will have to
> try this with a unit. (Off the top of my head, I can already think of one
> good use of this in the code that produces the Readscheme.org
> sites.) One of
> the reasons I stopped doing this was because I was using modules
> extensively,
> but where  I only care about the _value_ (which would be a unit)
> returned by
> load, that's not really an issue.
>
> At the same time, however, I would like to plug another approach
> to dealing
> with configuration data-- based on something else in the
> PLT-bag-of-tricks,
> which I first saw in the PLT web server code. (The morale of the
> following is
> that I very much like match-lambda !)
>
> [from comments I sent Sebastian earlier...]
>
> ... you may want to a look at is how the configuration-table for
> the PLT web
> server is loaded/parsed and how it is updated (see parse-table.ss is the
> web-server collection). Just to give you a short glimpse:
>
> The table is loaded by reading an s-expression:
>    (with-input-from-file path read)
>
> That value is passed to (parse-configuration-table ...)
>
> Which is defined using match-lambda (from "match.ss"):
>
> ; my apologies to Paul Graunke ;) -- this isn't the real code, it
> includes my
> hacks
>   (define parse-configuration-table
>     (match-lambda
>      [`((port ,port)
>         (max-waiting ,max-waiting)
>   (initial-connection-timeout ,initial-connection-timeout)
>         (log-profiles . ,log-profile-table)
>         (default-host-table
>          ,default-host-table)
>         (virtual-host-table . ,virtual-host-table))
>   ... code that does something with this data ...)]
>     [ `(... other matching criteria ...) ... code ...]
>     [x (error 'parse-configuration-table "malformed configuration
> ~s" x)]))
>
> match-lambda is a bit like case-lambda: it is a sequence of
> clauses: (pattern
> expression ...). The ,<some-var> items in the pattern (for example
> ",max-waiting" in the above pattern) get bound to the value in
> that place in
> the matched-sexpression. Sometimes this value is itself another
> s-expression,
> which gets passed again to a different match-lambda. (This is the
> case for
> the virtual-host-table, in the above example.)
>
> Of course writing the data to file is quite simple as well:
>   (write `((port ,port)
>         (max-waiting ,max-waiting)
>       (initial-connection-timeout ,initial-connection-timeout)
>         (log-profiles . ,log-profile-table)
>         (default-host-table
>          ,default-host-table)
>         (virtual-host-table . ,virtual-host-table)))
>
> Jim Bender
>