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 <[email protected]>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 > > [email protected] > > 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 >
____________________ Racket Users list: http://lists.racket-lang.org/users
