[racket] Question about resolution of variable-name conflicts in namespaces

Two comments on this code:

1. You are using eval because you *necessarily* have arbitrary Racket 
code coming into your application from outside at run time?  Or because 
the libraries you are using seem to want you to use "eval"?  The former 
reason is legitimate, but rare.  If the latter reason, there should be a 
better way.  ("eval" is almost always a bad idea, except for when it's 
fundamentally necessary.  Do not be misled by gesticulating CS 101 
lecturers; they are talking about theory.)

2. If speed is a consideration, I wouldn't be creating new namespaces 
and doing "require"s on each page request.  But hopefully you can get 
rid of the "eval"s, and then optimizing namespace reuse is irrelevant.

Neil V.

Matthew Butterick wrote at 05/15/2013 01:37 PM:
> BTW here's the technique I devised, in case it's useful to others.
>
> ; define the values you need for include-template
> (define body-for-template "content")
> (define template-name "template.html")
>
> (define page-result
>       (parameterize ([current-namespace (make-base-empty-namespace)]
>                      [current-directory source-dir]       ; set this 
> to your template directory if you want to use relative names in 
> include-template
>                      [current-output-port (open-output-nowhere)])
>         (namespace-require 'racket)
>         (eval '(require web-server/templates) (current-namespace)) ; 
> repeat as needed for other modules your template uses
>         (eval `(define body ',body-for-template) (current-namespace)) 
> ; repeat as needed to establish your template variables
>         (eval `(include-template #:command-char #\∂ ,template-name) 
> (current-namespace)))) ; I use ∂ as exp delimiter
>
>
> ; go on to do things with page-result ...
>
>
> BTW thanks again to Jay McCarthy for adding the command-char option to 
> include-templates, which makes it possible to have compile-time 
> expressions and run-time expressions in the templates, and also avoid 
> escaping @ symbols.