Re: parameter config is a mess

On Wed, Apr 09, 2003 at 09:10:11AM +0100, Matthias Radestock wrote:
> 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

I believe for proper properties, this is the case.

> 
> 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
I'm not sure what you mean by this.

> 
> 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.

The problem with parser as it stands now is that it operates 
independently of Interpreter, which means any information it needs to 
operate has to come either from its own instance variables, or must be 
passed in on method calls.  It does have a flags field for just this 
sort of thing.  
  Currently, there is a PRODUCE_ANNOTATIONS flag which is 
passed in by readCode and not by ordinary read.  The original (messy) 
scheme was that if PRODUCE_ANNOTATIONS and the boolean flag in Parser 
were both true, we'd emit annotations.  What we obviously need is to 
read a proper variable out of the dynamic environment to decide whether 
to pass PRODUCE_ANNOTATIONS in from read-code.  
  The other Parser related flag is STRICT_R5RS, which was recently 
introduced, and which comes from the Lexer.  This one is weird because 
the lexer doesn't even have a flags field.  I propose that we add one so 
we can pass the flags from Parser to Lexer in the same fashion.

	Scott

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+lDFpr9IW4v3mHtQRAudeAJ92KqtNnDqi+J3QeRdqTbmhKBhPrwCfZoEG
T89JHcYQsKbVQdZGQPSbQiQ=
=gpkR
-----END PGP SIGNATURE-----