Interactions between .programrc options?

[Arthur J. O'Dwyer]

Same background information as my post on "Quadtree rotations?"
in comp.programming. I'm writing a Funge interpreter. Google
'spec98.html' for details on the language.

It has a lot of quirks and alternative interpretations that I want
to be user-settable options. For example, the user ought to be
able to select a "safe mode" in which the '=' command is disabled;
or a "classic mode" in which the interpreter behaves as in Befunge-93.
There are literally dozens of these options right now, and I
anticipate adding more.

My current implementation just has a gigantic command-line parser.
This is reasonable for some options, but I think it will be better
to create a ".fungerc" options file containing text something like
this:

dialect=Befunge98
sgml_strings=false
warn_unimplemented=false
display_onlyascii=true
stackbits=32
cellbits=32
actslike x r

and then parse that file to set the options. Simple enough so far.

My question is: Some of these options interact with each other.
For example, if we set 'language=Befunge93', then that ought to
implicitly set stackbits=8, cellbits=8, sgmlstrings=false, and a
bunch of other things. And there will be more interactions. In
some cases, the interactions will happen at runtime; for example,
if the program divides by zero it will ask the user for a value.
If the user enters "Always use 0", then it will be as if he had
set the 'divz_result=0' option in the option file.

Is there a library or existing open-source program that does a
particularly intuitive job of managing such interactions? I would
think there is, but I don't know what to search for. Any help
would be greatly appreciated.

-Arthur

[CBFalconer]

"Arthur J. O'Dwyer" wrote:
.... snip ... My question is: Some of these options interact with each other. For example, if we set 'language=Befunge93', then that ought to implicitly set stackbits=8, cellbits=8, sgmlstrings=false, and a bunch of other things. And there will be more interactions. In some cases, the interactions will happen at runtime; for example, if the program divides by zero it will ask the user for a value. If the user enters "Always use 0", then it will be as if he had set the 'divz_result=0' option in the option file.

In the past I have allowed each internal option to have three (or
more) states, including 'notset'. The system comes up with them
all in the 'notset' condition, and /changing/ a previously set
option is an error. After all input option settings are done we
can check that all required options have been set.

Combined with input controls that set a herd of internal option,
this can handle a multitude of restrictions. Some of the
individual operations can also insist on prerequisites.

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski

[Arthur J. O'Dwyer]

On Fri, 6 Aug 2004, CBFalconer wrote: "Arthur J. O'Dwyer" wrote: My question is: Some of these options interact with each other. For example, if we set 'language=Befunge93', then that ought to implicitly set stackbits=8, cellbits=8, sgmlstrings=false, and a bunch of other things. And there will be more interactions. In some cases, the interactions will happen at runtime; for example, if the program divides by zero it will ask the user for a value. If the user enters "Always use 0", then it will be as if he had set the 'divz_result=0' option in the option file. In the past I have allowed each internal option to have three (or more) states, including 'notset'. The system comes up with them all in the 'notset' condition, and /changing/ a previously set option is an error. After all input option settings are done we can check that all required options have been set. Combined with input controls that set a herd of internal option, this can handle a multitude of restrictions. Some of the individual operations can also insist on prerequisites.

While your post is chock-full of good advice, I'm going to
point out:

(1) It might happen that the user wants to set the options
such that they say, "Use language Befunge-93, but do not apply
the 80x25 playfield restriction." The obvious way to do this is

language=Befunge93
small_playfield=false

(or something like that). If 'language=Befunge93' implicitly
sets 'small_playfield', then your scheme would consider that an
error (AIUI). So we really need three meta-states: not set,
implicitly set, and explicitly set. And then the latter two
meta-states would have their own true/false or Befunge93/Befunge98
or 1/2/3 or whatever. Explicit settings would override implicit
settings, and only one explicit setting could exist.

...Oh, wait. We might also have something like

set_foo_and_notbar_and_cleverstuff1=true
set_foo_and_bar_and_cleverstuff2=true

which contains two contradictory implicit settings for 'bar',
which ought to be an error... unless we /also/ have exactly one
explicit setting! So add another meta-state: implicitly errorful.
This setting is overridden by "explicitly set," and if any options
are left in this state, we give up with an error message.


(2) You wrote:
this can handle a multitude of restrictions. Some of the individual operations can also insist on prerequisites.

which is a one-sentence glossing-over of what I see as the major
hurdle here. How do I "insist on prerequisites" in a neat and
extensible fashion? I could just have a big ad-hoc structure the
way I'm doing it now, where I write

if (FungeVersion == BEFUNGE93) {
UseSGMLStrings = false;
[...]
}
if (ReflectOnUnimplemented) {
WarnUnimplemented = false;
}

and so on. But that's long, ugly, and prone to error. I'd prefer
something like

struct Option {
has a short name of some kind
has a default setting
has a list of pairs (value, list of implications)
}

struct Option all_options[] = { ... };

void setOption(user-supplied short name x, value)
{
struct Option *p = locate_option(x);
x->current_value = value;
follow_through_on_implications(x);
}

value_type getOption(programmer-supplied short name x)
{
return x->current_value;
}

except that I don't have any idea how to implement that in C, which
is the language in which I'm writing the interpreter. (I suppose I
could investigate using a different language for the user-interface
part of the interpreter, but that would be (1) less portable and
(2) work. So I'm not planning on it unless someone gives me an
example of how Language X makes this a /lot/ easier.)

I hope this clarifies things a bit more. :)

-Arthur

[CBFalconer]

"Arthur J. O'Dwyer" wrote:
.... snip ... except that I don't have any idea how to implement that in C, which is the language in which I'm writing the interpreter. (I suppose I could investigate using a different language for the user-interface part of the interpreter, but that would be (1) less portable and (2) work. So I'm not planning on it unless someone gives me an example of how Language X makes this a /lot/ easier.)

I think you want to look over the possible schemes and see how you
can implement them with some sort of table. Then future changes
simple involve revising the table. Do you smell a similarity to
parser generators driven from BNF?

--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski