[racket] question on pluggable modules

There are several ways to do that.

As Matthias, I often use a file called "base.rkt" where I put all the
constants that can be used in different files.
For non-constants, I use either a parameter or simply a getter procedure.
You can even place there some procedures to be defined later (kind of like
with a .h C file) in case module A requires module B that requires function
f, but you want to define f in A, for whatever reason. Then you can write
`(define f #f) (provide f)' in base.rkt and `(set! f (lambda ....)' in
A.rkt. It's not pretty though.
If required several times, a module will be instantiated only once (you
could tried this out yourself ;) ).
Also, if the student module needs to be required in several files and you
don't want to change the student file name in all modules, you can write a
require/provide wrapper D.rkt, where you write
(require "student1.rkt")
(provide (all-from-out "student1.rkt"))
and then require only D.rkt. Switching from one student file to the other
then only needs to be done only in D.rkt.

I think you can also use units, but I've never really tried them myself.

You can also use a struct or a singleton object where to put all your
globals, and pass that object to all students functions.

You can also make the student code inherit from a class that already has
access to all these globals.

I'd be interested in the end result :)

Laurent


On Mon, Nov 4, 2013 at 12:49 AM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> I tend to define such constants in a file dubbed 'basics' and require it
> everywhere. See
>
>  https://github.com/mfelleisen/Acquire
>
> for example. There 'basics' contains the constants I need for most of the
> game implementation and some simple functions too.
>
> -- Matthias
>
>
>
>
>
>
> On Nov 3, 2013, at 12:45 PM, Stephen Bloch wrote:
>
> > Program P uses several functions (say, f and g) which can be implemented
> in several different ways (think of (f,g) as a Java interface, with (f1,g1)
> as one implementing class, (f2,g2) as another implementing class, etc.)
>  I'd like to be able to run the program with one implementation, then with
> minimal effort run it again with a different implementation.
> >
> > The f and g functions, naturally, take some information from P.  But
> some of the information they need really is changeable from one call to the
> next (make it parameters to f and g), while other information is read from
> a data file on each invocation of P, and won't change for the duration of
> that run of P, so it feels more natural to store that information in a
> global constant C.
> >
> > If I were putting implementations of f & g in the same source file with
> P, I would just define C in that source file, and implementations of f & g
> could refer to it by name.  But putting the implementations of f & g into
> the main source file makes it a pain to plug in a different implementation.
>  If C were simple to define, I would provide it from another source file
> that all these other files require… but C is defined by parsing a data
> file; is that going to happen once for each source file that requires it?
> >
> > What's an "approved" way to structure this sort of thing?  Is this a job
> for parameterize?
> >
> > (In case you're curious about the application, it's an animated
> visualization of a graph-coloring problem, and I want to have students plug
> in their own algorithms for graph-coloring.  C is the adjacency relation,
> the list of available colors, a couple of things like that.  My students
> have never heard of parameterize, but that's the least of my worries right
> now.)
> >
> >
> > Stephen Bloch
> > sbloch at adelphi.edu
> > GPG key at http://home.adelphi.edu/sbloch/sbloch.pubkey.asc
> >
> > ____________________
> >  Racket Users list:
> >  http://lists.racket-lang.org/users
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20131104/937fc132/attachment-0001.html>