On Sunday, July 13, 2003, at 06:54 AM, Thaddeus L. Olczyk wrote:

A while ago I looked at Haskell. I got stuck on a problem which basically caused me to stop using Haskell.

Realising that I never asked anyone else how they would approach the deal, I decided to ask before I put the final chapter on Haskell.

I have a program that requires a lot of customisation. As a result there is an initialization file with many entries ( typically 30-80 entries ). Some of these entries need to be accessed quite often, so that opening the file and reading in on demand is not really an option.

So the basic question is how do I handle access to these parameters?

PS: I've thought of Hugh's approach to global variables, but even with compound data structures it really isn't practical for such a large number. Not even when creating compound structures to hold the data. Worse you wind up with data structures which are not coherent having only the fact that each is a customisation in common.

I think that each being a customisation *is* sufficient for coherence of one data structure to hold them all. My approach was to define a data structure that stored a sequence of flags, bindings of property names to values, sets of those, and sequences of those. For this I wrote a parser and some accessor functions. See section 7 in http://www.cit.gu.edu.au/~arock/hlibs/ABRHLibs.pdf Cheers, Rock. -- Andrew Rock -- A.Rock@griffith.edu.au -- http://www.cit.gu.edu.au/~arock/ School of Computing and Information Technology Griffith University -- Nathan, Brisbane, Queensland 4111, Australia

On Sat, 12 Jul 2003 15:54:47 -0500 "Thaddeus L. Olczyk" wrote:

A while ago I looked at Haskell. I got stuck on a problem which basically caused me to stop using Haskell.

Realising that I never asked anyone else how they would approach the deal, I decided to ask before I put the final chapter on Haskell.

I have a program that requires a lot of customisation. As a result there is an initialization file with many entries ( typically 30-80 entries ). Some of these entries need to be accessed quite often, so that opening the file and reading in on demand is not really an option.

It would help if you were a bit more specific on what the program is like or does ... For a sequential program it seems relatively straightforward. You load the configuration at startup, you build an environment object that holds all these settings (or better a record that contains function partially applied to the relevant settings if only certain functions need to know the options and the others are defined in terms of these). You can then pass around this (these) environment object(s) by hand, or use an Environment (Reader) monad, or use GHC's implicit parameters extension. If you have a 'reload configuration file' command then you simply reread the file, rebuild the environment object, and run the computation with this new environment. If options can be changed during the course of a computation then you are likely in the IO monad and have a large range of options available. You can handle consistency checking and updating more or less as you would in any language. For a concurrent program things are somewhat more complicated, but not much. The simplest thing would be to poll a MVar that specifies when to rebuild the environment object (obviously you wouldn't be constantly polling it, just before you did whatever. You could use throwTo as well). The type can be MVar(Maybe Environment) if nothing very complex or thread specific needs to be done. This would allow for threads to be using the old configuration while some use the new, typically this isn't a problem, using a webserver as an analogy, those threads would be already started sessions. If it's necessary to keep them consistent you could likely use throwTo to terminate them gracefully, or just wait for all of them to finish if they aren't potentially long-lived.

So the basic question is how do I handle access to these parameters?

Pass them around. Use an environment or state monad to handle it if you want cleaner looking code. Finally, you could of course mostly stay in an IO computation and solve the problem as you would in most any imperative language. Heck, there would still be benefits of using Haskell as opposed to (most) imperative languages even if you took that approach, such as, strong polymorphic static typing, higher-order procedures, type classes, a flexible syntax, and quite a few others.