[plt-scheme] custom language level

From: Daniel Yoo (dyoo at cs.wpi.edu)
Date: Tue May 1 22:28:48 EDT 2007

> 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!


Posted on the users mailing list.