Yes, the idea is that you can set the parameter inside your servlet and that will effect the thread-cell for your servlet thread. Or, you can parameterize before you serve/servlet or send/suspend for a sub-component of your servlet with a different response representation<div>
<br></div><div>Jay<br><br><div class="gmail_quote">On Mon, Dec 6, 2010 at 10:18 AM, Robby Findler <span dir="ltr">&lt;<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Also: is this really supposed to be a parameter? That is, do you use<br>
parameterize with it? (If so, how does that interact with the ho<br>
stuff?)<br>
<br>
Robby<br>
<br>
On Mon, Dec 6, 2010 at 11:16 AM, Robby Findler<br>
<div><div></div><div class="h5">&lt;<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>&gt; wrote:<br>
&gt; Who should be blamed if the coercion does not return a response?<br>
&gt;<br>
&gt; Is there a contract on current-response/c? (I assume that the &quot;/c&quot;<br>
&gt; there is a misnomer and it really is a parameter that holds a<br>
&gt; contact/coercion, not a contract.)<br>
&gt;<br>
&gt; Robby<br>
&gt;<br>
&gt; On Mon, Dec 6, 2010 at 10:55 AM, Jay McCarthy &lt;<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Maybe dynamic/c isn&#39;t clear enough... its definition is pretty short:<br>
&gt;&gt; (define (dynamic/c pre parameter post)<br>
&gt;&gt;   (define pre-ctc (coerce-contract &#39;pre pre))<br>
&gt;&gt;   (define post-ctc (coerce-contract &#39;post post))<br>
&gt;&gt;   (make-contract<br>
&gt;&gt;    #:name (build-compound-type-name &#39;dynamic pre-ctc parameter post-ctc)<br>
&gt;&gt;    #:projection<br>
&gt;&gt;    (λ (b)<br>
&gt;&gt;      (define pre-proj ((contract-projection pre-ctc) b))<br>
&gt;&gt;      (define post-proj ((contract-projection post-ctc) b))<br>
&gt;&gt;      (λ (x)<br>
&gt;&gt;        (define dyn-proj<br>
&gt;&gt;          ((contract-projection (coerce-contract &#39;dynamic (parameter))) b))<br>
&gt;&gt;        (post-proj<br>
&gt;&gt;         (dyn-proj<br>
&gt;&gt;          (pre-proj<br>
&gt;&gt;           x)))))))<br>
&gt;&gt; The system provides pre and post, so it can offer protection to the coercion<br>
&gt;&gt; as well as receive protection FROM the coercion. But the coercion comes from<br>
&gt;&gt; a parameter which is exposed to the user.<br>
&gt;&gt; The one I use in the web-server is:<br>
&gt;&gt; (dynamic/c any/c current-response/c response?)<br>
&gt;&gt; where response? is the data structure predicate that the internal plumbing<br>
&gt;&gt; uses.<br>
&gt;&gt; Jay<br>
&gt;&gt; On Mon, Dec 6, 2010 at 9:51 AM, Jay McCarthy &lt;<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; That&#39;s why dynamic/c has a pre/c and post/c. Before it uses the user&#39;s<br>
&gt;&gt;&gt; contract, it applies pre/c. After it applies post/c. This ensures that the<br>
&gt;&gt;&gt; user&#39;s contract actually coerces to a response?<br>
&gt;&gt;&gt; Jay<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Mon, Dec 6, 2010 at 9:25 AM, Robby Findler<br>
&gt;&gt;&gt; &lt;<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Mon, Dec 6, 2010 at 9:23 AM, Jay McCarthy &lt;<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt; Yes, since I am allowing users to customize the coercion behavior, I<br>
&gt;&gt;&gt;&gt; &gt; could<br>
&gt;&gt;&gt;&gt; &gt; either have them provide two functions: a coercion-applies? function<br>
&gt;&gt;&gt;&gt; &gt; and a<br>
&gt;&gt;&gt;&gt; &gt; coercion function; OR I could have them just provide the coercion<br>
&gt;&gt;&gt;&gt; &gt; function<br>
&gt;&gt;&gt;&gt; &gt; and I will check the answer and re-run it inside of the function body.<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt; The other issue is that finding all the places where I should apply the<br>
&gt;&gt;&gt;&gt; &gt; coercion inside the body of the function is difficult, because I need<br>
&gt;&gt;&gt;&gt; &gt; to do<br>
&gt;&gt;&gt;&gt; &gt; it at every place where a response/c could flow in (relatively easy)<br>
&gt;&gt;&gt;&gt; &gt; and<br>
&gt;&gt;&gt;&gt; &gt; every place where a response/c could flow out (much hard, esp. with<br>
&gt;&gt;&gt;&gt; &gt; continuations). Contracts on functions are very nice in their ability<br>
&gt;&gt;&gt;&gt; &gt; to do<br>
&gt;&gt;&gt;&gt; &gt; stuff to inputs and outputs.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I think I need more help to understand the programming problem better.<br>
&gt;&gt;&gt;&gt; Why are your users supplying you a contract that you are using to<br>
&gt;&gt;&gt;&gt; protect your functions? That is how can you use anything about that<br>
&gt;&gt;&gt;&gt; contract to avoid errors in your programs?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Robby<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt; Jay<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt; On Mon, Dec 6, 2010 at 8:19 AM, Matthias Felleisen<br>
&gt;&gt;&gt;&gt; &gt; &lt;<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; The string-&gt;number primitive is probably closer to what Jay wants to<br>
&gt;&gt;&gt;&gt; &gt;&gt; do.<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; The only contract I can think of for string-&gt;number is<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;  ;; Number -&gt; Boolean<br>
&gt;&gt;&gt;&gt; &gt;&gt;  (define (string-&gt;number-able? x)<br>
&gt;&gt;&gt;&gt; &gt;&gt;    (number? (string-&gt;number x)))<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; So the real problem is a performance problem, which a lazy<br>
&gt;&gt;&gt;&gt; &gt;&gt; interpretation<br>
&gt;&gt;&gt;&gt; &gt;&gt; of contracts by the compiler might be able to eliminate.<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; Is this the true problem Jay -- Matthias<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; On Dec 6, 2010, at 9:45 AM, Robby Findler wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; Let&#39;s be clear here: our inability to enforce projectionness is in<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; no<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; way condoning the two coercianlike contracts that you have now<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; written.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; That said, the only value I see to contracts that only signal errors<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; (or do nothing) is that programmers know what to expect from them.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; The<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; downsides you mention are well taken, of course.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; In this specific case, your message seems slightly confused:<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; certainly<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; you should be able to use a contract to ensure that the coercion<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; will<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; always succeed. Let&#39;s assume you have done that and now discuss only<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; where the coercing bit of the &quot;contract&quot; goes. Is it in a higher<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; order<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; position? Is it something that describes an interface to your module<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; or can it be considered an internal detail?<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; As a possible guide by analogy, consider the path-string? Predicate.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; It is the contract on many functions the ultimately is connected to<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; some kind of a coercion somehwere buried inside the racket<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; primitives<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; for dealing with the filesystem. Is that like what you want to do?<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; If<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; so, how would your arguments hold up for that part of our system?<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; Robby<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; On Monday, December 6, 2010, Jay McCarthy &lt;<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; These contracts are not thrown &quot;at dynamic places&quot;. The contract is<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; always at the module boundary/etc, but its meaning if affected by<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; the<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; dynamic context of the particular boundary crossing. [1]<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; I&#39;m been thinking about why I want to use contracts for this<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; purpose.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; The alternative is to put an any/c contract in all the places I<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; currently have response/c and as the first thing in all those<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; functions call<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; current-any-&gt;response [or as the last thing on returns] on the<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; input<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; argument. I would then have to put a note in all the documentation<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; of those<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; any/c that it doesn&#39;t REALLY accept anything, instead in other<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; accepts<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; things that the dynamic current-any-&gt;response will turn into a<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; response. If<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; the coercion failed, then I would have to throw an error, which be<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; purely<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; dynamic with no blame information because it would not be<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; associated with a<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; contract boundary.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; In contrast, using a contract for this purpose allows me to<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; centralize<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; the documentation and behavior of these arguments, get correct<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; blame on<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; places where the coercion fails, and abstract the coercion out of<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; the code<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; that is using it into its interface. These are all great wins.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; In my opinion, if I did not use contracts, the only elegant thing<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; to do<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; would be to recreate something almost exactly like the contract<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; system but<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; called the coercion system. That is absurd to me when contracts<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; already do<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; exactly this.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Am I just not clever enough to think of another elegant way?<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Why is there so much resistance to using the contract system in a<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; perfectly legal way according to its own definition &amp; contracts?<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; [2] [i.e.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; &quot;projection&quot; functions are not forced to be projections by any<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; means. /<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; contracts already break eq?/equal?-ness / etc]<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Jay<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; 1. We already have such context-sensitive contracts:<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; <a href="http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c))" target="_blank">http://docs.racket-lang.org/xml/index.html#(def._((lib._xml/main..rkt)._permissive/c))</a><br>

&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; permissive/c exists to allow DrRacket to embed more snips inside<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; the<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; XML boxes, which are otherwise not XML elements.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; 2. make-contract&#39;s projection keyword has the contract (-&gt; any/c<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; any/c)<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; The example of make-contract coerces the procedure by restricting<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; how<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; many arguments rather than checking that when it is given that<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; number of<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; arguments it is used properly, etc.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Only flat and chaperone contracts attempt to enforce<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; projection-ness.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; On Sun, Dec 5, 2010 at 9:31 AM, Matthias Felleisen<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href="mailto:matthias@ccs.neu.edu">matthias@ccs.neu.edu</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Jay, coercions aka casts in our world are compound words with -&gt; in<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; between them. Why do you need a new name?<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; (There is an inconsistency in their behavior. To wit<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Welcome to Racket v5.0.99.4.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;&gt; (integer-&gt;char 1000000000000000)<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; integer-&gt;char: expects argument of type &lt;exact integer in<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; [0,#x10FFFF],<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; not in [#xD800,#xDFFF]&gt;; given 1000000000000000<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;  === context ===<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; /Users/matthias/plt/collects/racket/private/misc.rkt:78:7<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;&gt; (string-&gt;number &quot;a10&quot;)<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; #f<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; But that is a historical problem.)<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; ;; ---<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; I am also reluctant to throw contracts at dynamic places. Contract<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; boundaries should be syntactically distinct, e.g., module<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; boundaries or<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; define/contract.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; ;; ---<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; I think you&#39;re really just checking an assertion. So perhaps you<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; want<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; to go with /a as a suffix.<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; -- Matthias<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; --<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Jay McCarthy &lt;<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; Assistant Professor / Brigham Young University<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt; &quot;The glory of God is Intelligence&quot; - D&amp;C 93<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt; --<br>
&gt;&gt;&gt;&gt; &gt; Jay McCarthy &lt;<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>&gt;<br>
&gt;&gt;&gt;&gt; &gt; Assistant Professor / Brigham Young University<br>
&gt;&gt;&gt;&gt; &gt; <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;&gt; &gt; &quot;The glory of God is Intelligence&quot; - D&amp;C 93<br>
&gt;&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Jay McCarthy &lt;<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>&gt;<br>
&gt;&gt;&gt; Assistant Professor / Brigham Young University<br>
&gt;&gt;&gt; <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &quot;The glory of God is Intelligence&quot; - D&amp;C 93<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Jay McCarthy &lt;<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>&gt;<br>
&gt;&gt; Assistant Professor / Brigham Young University<br>
&gt;&gt; <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
&gt;&gt;<br>
&gt;&gt; &quot;The glory of God is Intelligence&quot; - D&amp;C 93<br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jay McCarthy &lt;<a href="mailto:jay@cs.byu.edu" target="_blank">jay@cs.byu.edu</a>&gt;<br>Assistant Professor / Brigham Young University<br><a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
<br>&quot;The glory of God is Intelligence&quot; - D&amp;C 93<br>
</div>