Hi Daniel - Sorry to be unspecific - I thought my error has to do with me not understanding the module loading system, that's why I ask the question this way.  The error that I am seeing is: module: no #%module-begin binding in the module's language in: (module foo (lib " util.scm" "util") (require (lib "trace.ss")) (define x 1) (provide (all-defined))) I tried your example and it worked (of course ;P), and I try to figure out the difference between the two - and it turns out the line <div style="margin-left: 40px;">(provide (all-from mzscheme)) </div> is what I am missing - when I add that to my module it also worked ;)  So I asked the wrong question, but you gave me the right answer - thanks :P The planet development link and idea sounds interesting - I will take a look at it ;)  Thanks, yinso <div>On 5/1/07, Daniel Yoo <<a href="mailto:dyoo@cs.wpi.edu"> dyoo@cs.wpi.edu</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > but I cannot then use the module in the language position (per my > understanding that's how one can create a new language...) - so the > following don't work: > > (module foo (lib "util.scm" "util") > ....) Hi Yinso, Can you be more specific?  Do you mean that the module system doesn't see it at all, or does something else happen?  If you can show us a specific error message, maybe we can help to explain it. Here's an example of a language that includes a compose primitive (which is slightly silly, since one exists in (lib "etc.ss")... ) ######################################################### mithril:~/Desktop dyoo$ cat test/mzscheme-with-compose.ss (module mzscheme-with-compose mzscheme    (provide (all-from mzscheme))    (provide compose)    (define (compose f g)      (lambda (x)        (f (g x))))) mithril:~/Desktop dyoo$ PLTCOLLECTS=~/Desktop mzscheme Welcome to MzScheme v369.10 [3m], Copyright (c) 2004-2007 PLT Scheme Inc. > > > (module test-compose (lib "mzscheme-with-compose.ss" "test")      (printf "hello ~a~n" ((compose string-upcase (lambda (x) (string-append x x)))                            "yinso"))) > (require test-compose) hello YINSOYINSO ######################################################### So there's no requirement that language modules have to live in a specific place, just as long as the module resolver can find them. One of the really minimal languages, like Dave Herman's mzlite.plt PLaneT package, might also help you get started:     <a href="http://planet.plt-scheme.org/display.ss?package=mzlite.plt&owner=dherman"> http://planet.plt-scheme.org/display.ss?package=mzlite.plt&owner=dherman</a> > If that's the solution, then a related question would be how one should > organize source code so one don't have to pollute the \plt\collects > directory so it works well in the face of an upgrade. Doing things in the PLaneT framework seems to be less problematic for me. It sounds like you've configured PLTCOLLECTS.  For personal development, rather than do something with the PLTCOLLECTS environmental variable, I've been taking advantage of PLaneT's development link feature. We can register a directory to act as a development link for PLaneT, so that module references like (planet "some-module.ss" ("dyoo" "package.plt")) resolve locally to my work directory.  It makes things easier if the code ends up being useful enough to really migrate onto PLaneT. If you're interested, see the section on "Development links" and the "--associate" option in:      <a href="http://pre.plt-scheme.org/plt/collects/planet/doc.txt">http://pre.plt-scheme.org/plt/collects/planet/doc.txt </a> Good luck! </blockquote></div>