[plt-scheme] custom language level
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
(provide (all-from mzscheme))
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
On 5/1/07, Daniel Yoo <dyoo at cs.wpi.edu> wrote:
>
>
> > 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:
>
>
> http://planet.plt-scheme.org/display.ss?package=mzlite.plt&owner=dherman
>
>
>
> > 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:
>
> http://pre.plt-scheme.org/plt/collects/planet/doc.txt
>
>
>
> Good luck!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070501/d71e52e9/attachment.html>