[m-dev.] for review: make unboxed enums and no-tag types optional

Tyson Dowd trd at cs.mu.OZ.AU
Wed Aug 9 17:31:02 AEST 2000


On 09-Aug-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 09-Aug-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > Index: compiler/options.m
> > @@ -1931,7 +1938,16 @@
> >  		"\tThe C code needs to be compiled with `-UBOXED_FLOAT'.",
> >  		"\tIt may also need to be compiled with",
> >  		"\t`-DUSE_SINGLE_PREC_FLOAT', if double precision",
> > -		"\tfloats don't fit into a word."
> > +		"\tfloats don't fit into a word.",
> > +
> > +		"--unboxed-enums",
> > +		"(This option is not for general use.)",
> > +		"\tDon't box enumerations.  This option is set by default.",
> 
> For consistency with the documentation for the rest of the options,
> if an option is enabled by default, then you should document the
> inverse option (`--no-unboxed-enums' in this case).
> 
> If you don't like the double negation, then you could provide an
> option `--boxed-enums', either in addition to or instead of the
> `--no-unboxed-enums' option.  (If you want to allow both, this can be
> handled by one of them being a bool_special option.)  For consistency
> whatever you do here should also be done for `--unboxed-float'. 

I don't really care about the double negation, nobody should be using
this option anyway.  So I've documented the negation.

> 
> > +		"--no-tag-types",
> > +		"(This option is not for general use.)",
> > +		"\tDon't allow unboxed no-tag types.",
> > +		"\tThis option is set by default."
> 
> Clearly the double and triple negatives are getting confusing,
> since your documentation here inverts the sense of the option.
> 
> Likewise here since the option is set by default, you
> should document its inverse, the `--no-no-tag-types' option(!).
> 
> In fact using `--no-tag-types' as an option name won't work, because
> "--no-" prefix is reserved for use as the negation operator.  If you
> try to use that option, getopt will complain about there being no such
> option as the `--tag-types' option.
> 
> So, I suggest you name the option `--unboxed-no-tag-types'/
> `--boxed-no-tag-types', or perhaps `--unboxed-trivial-types'/
> `--boxed-trivial-types'.  In addition, the documentation should
> explain what a "no-tag" or "trivial" type is.

I've documented --no-unboxed-no-tag-types.

I haven't explained what a no-tag type is, this is a developer only
option (see below).

> 
> Finally, anything documented here should also be documented in
> doc/user_guide.texi.

This level of documentation implies some kind of support. 
I don't want to imply any kind of support for these options by
themselves.

I've instead commented out the documentation in options.m as we have with
many other developer only options.  Only experienced
developers should be setting these flags.  Otherwise they will just be
set as a result of a grade option.

I like the idea of renaming "no-tag" types as "trivial" types.
But it should be a separate change across the entire compiler if we do
it.

The updated options.m follows.

Index: options.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/options.m,v
retrieving revision 1.285
diff -u -r1.285 options.m
--- options.m	2000/07/25 09:27:24	1.285
+++ options.m	2000/08/09 07:10:14
@@ -166,6 +166,8 @@
 		;	highlevel_data
 		;	gcc_nested_functions
 		;	unboxed_float
+		;       unboxed_enums
+		;       unboxed_no_tag_types
 		;	sync_term_size % in words
 		;	type_layout
 	% Options for internal use only
@@ -561,7 +563,9 @@
 	highlevel_code		-	bool(no),
 	highlevel_data		-	bool(no),
 	gcc_nested_functions	-	bool(no),
-	unboxed_float		-	bool(no)
+	unboxed_float           -       bool(no),
+	unboxed_enums           -       bool(yes),
+	unboxed_no_tag_types    -       bool(yes)
 ]).
 option_defaults_2(code_gen_option, [
 		% Code Generation Options
@@ -935,7 +939,10 @@
 long_option("high-level-data",		highlevel_data).
 long_option("gcc-nested-functions",	gcc_nested_functions).
 long_option("unboxed-float",		unboxed_float).
+long_option("unboxed-enums",		unboxed_enums).
+long_option("unboxed-no-tag-types",	unboxed_no_tag_types).
 
+
 % code generation options
 long_option("low-level-debug",		low_level_debug).
 long_option("polymorphism",		polymorphism).
@@ -1932,6 +1939,16 @@
 		"\tIt may also need to be compiled with",
 		"\t`-DUSE_SINGLE_PREC_FLOAT', if double precision",
 		"\tfloats don't fit into a word."
+
+		% This is a developer only option.
+%		"--no-unboxed-enums",
+%		"(This option is not for general use.)",
+%		"\tBox enumerations.  This option is disabled by default.",
+
+		% This is a developer only option.
+%		"--no-unboxed-no-tag-types",
+%		"(This option is not for general use.)",
+%		"\tBox no-tag types.  This option is disabled by default."
 	]).
 
 :- pred options_help_code_generation(io__state::di, io__state::uo) is det.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list