parameter config is a mess

SISC's current way of setting runtime parameters such as 
emit-annotations, max-precision is terribly inconsistent and fragile(*).

Here's what *should* happen. *Any* configuration parameter "param" can 
be initialized on startup in the following ways:
1) initial, default, value; pre-configured by system
2) placing a (param . value) entry in sisc.properties
3) specifying -Dsisc.param=value on the command line
4) adding an entry to the '*config-parameters* property table

Latter entries in the above list take precedence over earlier entries.

There are several complications that make it hard to implement the above:

* there is currently no way to reset the default value of a dynamic 
parameter

* not all parameters are "proper" dynamic parameters; some are special 
entries in the DynamicEnvironment and are accessed by special 
primitives, some are not dynamic, some are "fake" parameters represented 
by primitives that manipulate settings somewhere in the runtime system.


We do need to sort this out asap. The current inconsistencies/breakages 
result in a very frustrating user experience that is quite unacceptable.


Matthias
(*) It's broken at the moment, not for the first time:
1) with the introduction of primordial threads, setting dynamic 
parameters in (initialize), e.g. those read from sisc.properties, has no 
effect on the repl.
2) emit-annotations is a property of the parser. Unlike other dynamic 
parameters it does not get inherited when a dynamic environment is cloned.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf