|
Size: 3097
Comment:
|
Size: 41
Comment: Very nice site!
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| This page describes the implementation of the DomTool language interpreter and other tools. Most members would probably be better served visiting DomTool/UserGuide. [[TableOfContents()]] = Languages = DomTool is implemented mostly in [http://en.wikipedia.org/wiki/Standard_ML Standard ML] (SML), with teeny tiny bits of C and shell script. Standard ML is a [http://en.wikipedia.org/wiki/Statically_typed statically-typed] [http://en.wikipedia.org/wiki/Functional_programming_language functional programming language] with much to recommend it, including a [http://portal.acm.org/citation.cfm?id=549659 language standard] (with formal semantics), [http://mlton.org/ one of the best open source optimizing compilers ever for any language], and open development models and communities associated with the major implementations (out of about 10 total language implementations floating around today). But really, why choose a programming language that "nobody's ever heard of"? The answer is simple. With SML, you can program at a high level of abstraction without having to worry about performance penalties and other historical undesirables. Information about obtaining and building the DomTool tools is found on ["DomTool/Building"]. = Configuration = As is more and more the fashion lately, DomTool supports many tweakable configuration variables, and the particular settings of those variables are conveyed via program source code. In particular, the various pieces of the DomTool implementation look for configuration in different members of a `Config` module in an SML source file `config.sml` in the `domtool2` base directory. When building the standalone tools with MLton, these configuration settings will be inlined into the places where they're used in the resulting binary, possibly triggering opportunities for further optimization. Isn't compilation technology wonderful? Any particular installation of DomTool is unlikely to want to set custom values for all or even most of the available variables. Thus, the implementation takes modest advantage of SML's module system to allow inheritance of default settings via the `open` declaration, while maintaining the possibility for piecemeal setting of custom values. DomTool involves a number of distinct plugins and sources of functionality, all of which have some configuration parameters. The implementation uses Makefile-driven concatenation of files following a certain convention to build the overall default configuration module from files associated with the separate plugins. In particular, in `domtool2/configDefault`, you will find a set of `.cfg`, `.cfs`, and `.csg` files. All the `.cfs` files are concatenated together to form the definition of the signature `CONFIG`, while `.csg` files are concatenated together to form supporting definitions of sub-signatures. The `.cfg` files are concatenated together to form the definition of a structure `ConfigDefault` ascribing opaquely to `CONFIG`. Your custom configuration structure `Config` also ascribes to `CONFIG` and may `open` `ConfigDefault`. |
Very nice site! ---- CategoryCategory |
