[plt-scheme] enclosing-module-name

A few years ago, I assigned the design and implementation of a TAX  
form language to my students in "software construction" (the last  
course on programming and the first course on SE at Rice and here). I  
think you're on the right track as far as the development of a  
sandbox language goes but I would propose the use of UNITs instead of  
modules. Consider Schedule C. You could imagine a family where both  
mom and dad own a small company and their minor child is an aspiring  
actor or tennis player who is also  incorporated as a company. In  
that case, you want to use the same "unit of computation" three  
times, parameterized over certain personal data. I used UNITs for  
that, though I will admit not having Modules at the time. If I had  
them, I would enclose the units in modules of the sandbox language.  
-- Matthias







On Apr 4, 2007, at 2:13 PM, support at taxupdate.com wrote:

> On Thu, Apr 05, 2007 at 05:05:26AM +0800, Matthew Flatt wrote:
>>
>> It's possible that either `syntax-identifier-binding' or
>> `syntax-source-module' will do what you want, but I'm not sure.
>
> I tried both of these, and they don't seem to provide what's needed in
> my situation.  Here's what I'd like to be able to do:
>
> The application will interpret user files written in what I'll call
> a "template language":
>
> (template x "description of x"
>     (image "image1.xpm"
> 	(text first "First Name")
> 	(fixed-2 wages "Wages")
> 	(fixed-2 agi "AGI" (+ wages 100))))
> 	
> which gets transformed to (roughly):
>
> (module x sandbox-language
>     (register 'x 'first "")
>     (register 'x 'wages 0)
>     (register 'x 'agi (+ wages 100))      ; this field has a "formula"
>     (reqister-image "image1.xpm")
>     ...)
>
> (define *field-hash* (make-hash-table))
> (define (register module var)
>     (hash-table-put! *field-hash* (string->symbol (format "~a.~a"  
> module var))))
>
> The hash table gives me a simple namespace simulation which I can  
> control
> easily.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
> ;;;;;;
>
> Here's the problem I'd like to solve.  The "formula", such as (+  
> wages 100),
> can be any scheme expression.  It gets transformed by a #%top which  
> does a
> hash-table-get on *field-hash* for any top-level symbol which isn't  
> defined.
> So %#top needs to know the enclosing module name (in this case "x")  
> in order
> to do the lookup.  I'd like to avoid requiring (+ x.wages 100) if  
> possible
> when the reference is to another field in the same template.  When  
> the formula
> refers to another template, then it must use the form (+ y.wages 200).
>
> I attempted this using parameters, but this didn't work correctly  
> because
> the parameter doesn't get evaluated until run time.  That caused  
> problems
> when more than one template was evaluated.
>
> #%module-begin looks promising, since it includes the enclosing- 
> module-name
> syntax property.  However, it seems hazy to me how I can get #%top  
> to see
> the property that's only available to #%module-begin.
>
> define-syntax-parameters might work, but I also want to avoid using  
> any plt libs
> like stxparam.ss, as the app will be distributed to users who don't  
> have mzscheme
> installed (only libmzscheme/libgc, mzscheme will be embedded in the  
> app).
>
> Any ideas on how to define #%top to be able to get the module name  
> at compile time?
> If you've made it this far, thanks for your patience on this long  
> post!
>
> Wayne
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme