s c h e m a t i c s : c o o k b o o k

/ Cookbook.DynamicEvalCustomNamespace

This Web

TOC (with recipes)

Other Webs



Schematics Home
Sourceforge Page
Original Cookbook

Scheme Links

Scheme FAQ
Scheme Cross Reference
Scheme48 SCM
MIT Scheme scsh
JScheme Kawa
Chicken Guile
Bigloo Tiny
Gambit LispMe

Lambda the Ultimate

Evaluating Code in a Custom Namespace


You want to eval code that:

And all this without the code you are evaluating having to include require statements to load the modules it needs.


All code is evaluated within a namespace. You must firstly create a new empty namespace for the code you wish to eval, and then attach any necessary modules to it:

500 Can't connect to (connect: Connection refused)


Typically code evaluated in eval has access to anything visible to the code that calls eval. E.g.:

500 Can't connect to (connect: Connection refused)

This is insecure -- the evaluated code could mess with the internals of the code that evaluates it. [TODO]

This is useful, for example, when web pages. Say you have a library of code that you use to write webpages (e.g. SSAX or WebIt and some transformations to HTML). You want to write the webpages as Scheme programs but you want to put each page in its own file and you don't want to worry about all the usual module wrapper code to load your library. You can use this method to create a custom namespace that includes your library and eval the code in this namespace.

[TODO: talk about attaching modules from existing namespace]

See also DynamicUntrustedEval

Here is another example of attaching modules from an existing namespace:

500 Can't connect to (connect: Connection refused)

We take special care here to make sure that the point module is shared between the main namespace and the evaluated code's namespaces. If we don't use namespace-attach-module, then test-evaluation can't call any of the point's selector functions since the evaluated code will instantiate its own point structure.

Also note that the call to module-path->symbol needs to occur outside the context of the evaluated code's namespace; (current-module-name-resolver) can load modules if they don't yet exist in a namespace, and that's precisely what we're trying to avoid.

Comments about this recipe

Here's an eval that hides the set! form:

500 Can't connect to (connect: Connection refused)

So if you try to bang on an identifier, you get an error:

500 Can't connect to (connect: Connection refused)

Note that namespace-attach-module only registers an instantiated module in the module registry of a destination namespace. It doesn't actually import any symbols as the (require ...) form does -- for that you need to namespace-require the registered module.

To instantiate a module that you haven't required in the source namespace, use dynamic-require. For example, if you have a module foo in foo.ss:

500 Can't connect to (connect: Connection refused)

To provide foo.ss to your users, change your my-eval to instantiate it:

500 Can't connect to (connect: Connection refused)

Remember that modules are only instantiated once per namespace, so you'll only see foo's load-time output one time:

500 Can't connect to (connect: Connection refused)

-- DanielSilva - 25 Jan 2005


-- NoelWelsh - 20 Jan 2005

TopicType: Recipe
ParentTopic: DynamicRecipes
TopicOrder: 999

Copyright © 2004 by the contributing authors. All material on the Schematics Cookbook web site is the property of the contributing authors.
The copyright for certain compilations of material taken from this website is held by the SchematicsEditorsGroup - see ContributorAgreement & LGPL.
Other than such compilations, this material can be redistributed and/or modified under the terms of the GNU Lesser General Public License (LGPL), version 2.1, as published by the Free Software Foundation.
Ideas, requests, problems regarding Schematics Cookbook? Send feedback.
/ You are Main.guest