How to correctly use (second-class) modules?

My software uses a pretty-printer abstraction, and when I opted to 
provide two different pretty-printing mechanisms the naïve decision I 
made was to just write another module satisfying the signature. 
However, now that I want to be able to choose a pretty-printer via a 
command-line switch I seem to be left with one of two options

(1) Functorize my program and then instantiate two completely separate 
versions and dispatch using a wrapper script.

(2) Write a third implementation of the signature that is a very tedious 
series of conditionals.

Both of these solutions are hard to take seriously.  Is there some other 
idiom people use in practice to overcome the restrictions of 
second-class modules?  I did see the dynamic loading solution in the CM 
manual, but that would not appear to be able to handle modules that 
contain abstract types.  Similarly, attempting to recast the abstraction 
as a record of functions fails also fails because of the need for 
abstract types.  Is this really that uncommon of a design decision?



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Smlnj-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/smlnj-list