From zoltan.somogyi at runbox.com Wed May 1 11:51:11 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 01 May 2024 11:51:11 +1000 (AEST) Subject: [m-rev.] for possible post-commit review: detect more kinds of bugs when pushing types into modes Message-ID: In the absence of a review by then, I intend to commit this this evening, and deal with any comments post-commit. For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.tim Type: application/octet-stream Size: 3263 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.tim Type: application/octet-stream Size: 87550 bytes Desc: not available URL: From novalazy at gmail.com Wed May 1 11:58:51 2024 From: novalazy at gmail.com (Peter Wang) Date: Wed, 1 May 2024 11:58:51 +1000 Subject: [m-rev.] for review: Fix codegen for subtype field names in high-level data grades. In-Reply-To: References: Message-ID: <20240501115851.GF2000@gmail.com> On Tue, 30 Apr 2024 19:27:00 +1000 "Zoltan Somogyi" wrote: > > On 2024-04-30 17:08 +10:00 AEST, "Peter Wang" wrote: > > diff --git a/compiler/hlds_data.m b/compiler/hlds_data.m > > index 4ba19cdf5..d53bd3362 100644 > > --- a/compiler/hlds_data.m > > +++ b/compiler/hlds_data.m > > @@ -982,11 +982,20 @@ set_type_defn_prev_errors(X, !Defn) :- > > :- type constructor_arg_repn > > ---> ctor_arg_repn( > > car_field_name :: maybe(ctor_field_name), > > + % car_maybe_base_arg says whether this constructor argument > > + % belongs to a subtype. If so, it must have a corresponding > > + % constructor argument in the base type, which may or may not > > + % have a field name. > > + car_maybe_base_arg :: maybe_base_ctor_arg, > > car_type :: mer_type, > > car_pos_width :: arg_pos_width, > > car_context :: prog_context > > ). > > > > +:- type maybe_base_ctor_arg > > + ---> no_base_ctor_arg > > + ; base_ctor_arg(maybe(ctor_field_name)). > > I intend to review the rest of this diff, but before I do, I would like > to know why you chose this approach over the approach I thought > would have been the obvious one, which would be to have the subtype > inherit all the field names for its subset of data constructors from its supertype. This was the obvious and direct fix to me. I just made the code work how I expected it to work all along. > One could either forbid the subtype declarations containing field names, > or just forbid them from having field names that differ from the supertype, > but either way, the supertype's field names would be available to be used > both by programmers, and by the code generator. I'm still intending on introducing restrictions on subtype field names, but that's a language design issue. > The approach used by the type definition above is more flexible than that, > in that it allows subtypes to have (user-facing) field names that differ from > the supertype's names for the same fields. What I would like to know is: > in what kinds of scenarios would this capability be more helpful than confusing? > The reason why I ask is that I can't think of any. Perhaps: - Adding distinguishing prefixes to field names. This makes more sense if you consider subtypes as distinct types first, that happen to be coerceable to other du types. - Renaming a field for documentation reasons, e.g. from "maybe_foo" in the supertype to "foo" in the subtype. BTW, does anyone know if there was particular reason for using Mercury field names to derive field names in high-level data grades. Obviously it makes for slightly more readable target code, but that seems like a very small benefit. Peter From zoltan.somogyi at runbox.com Wed May 1 20:21:16 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 01 May 2024 20:21:16 +1000 (AEST) Subject: [m-rev.] for review: \e as ESC, stage 2 In-Reply-To: Message-ID: On 2024-04-28 17:02 +10:00 AEST, "Zoltan Somogyi" wrote: > I intend to commit this on wednesday, since that should be > enough time for an rotd containing stage 1. Committed. Zoltan. From zoltan.somogyi at runbox.com Wed May 1 22:42:38 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 01 May 2024 22:42:38 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color to simplification diagnostics Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cs Type: application/octet-stream Size: 846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cs Type: application/octet-stream Size: 22580 bytes Desc: not available URL: From jfischer at opturion.com Wed May 1 23:43:09 2024 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 1 May 2024 23:43:09 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in mode_errors.m In-Reply-To: References: Message-ID: On Tue, 30 Apr 2024, Zoltan Somogyi wrote: > Use color in mode error diagnostics.m. ... > diff --git a/tests/invalid/bug117.err_exp b/tests/invalid/bug117.err_exp > index 37b288004..597c4a741 100644 > --- a/tests/invalid/bug117.err_exp > +++ b/tests/invalid/bug117.err_exp > @@ -1,10 +1,10 @@ > bug117.m:028: In clause for `extract(in) = out(list.non_empty_list)': > bug117.m:028: mode error: the function result did not get sufficiently > bug117.m:028: instantiated. > -bug117.m:028: Final instantiatedness of `X' was `ground', > -bug117.m:028: expected final instantiatedness was > -bug117.m:028: named inst list.non_empty_list > -bug117.m:028: which expands to > -bug117.m:028: bound( > -bug117.m:028: '[|]'(ground, ground) > -bug117.m:028: ). > +bug117.m:028: Final instantiatedness of `X' was `ground', > +bug117.m:028: expected final instantiatedness was  > +bug117.m:028: named inst list.non_empty_list > +bug117.m:028: which expands to > +bug117.m:028: bound( > +bug117.m:028: '[|]'(ground, ground) > +bug117.m:028: ). I wonder if "named inst" and "which expands to" should not be colored, so as the actual insts stand out. (OTOH, given the size some of those inst expressions grow to the in the other messages I can see why you did it this way.) ... > diff --git a/tests/invalid/coerce_clobbered.err_exp b/tests/invalid/coerce_clobbered.err_exp > index c3c75f42a..1093ff05c 100644 > --- a/tests/invalid/coerce_clobbered.err_exp > +++ b/tests/invalid/coerce_clobbered.err_exp > @@ -1,4 +1,4 @@ > coerce_clobbered.m:021: In clause for `bad(in(clobbered), out)': > coerce_clobbered.m:021: in coerce expression: > coerce_clobbered.m:021: mode error: the argument term has instantiatedness > -coerce_clobbered.m:021: `clobbered', but it must have a ground inst. > +coerce_clobbered.m:021: `clobbered', but it must have a ground inst. Not related to color: it would be nice if this error message mentioned the name of the argument term (i.e. Y in this case). ... > diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp > index cc44364a4..b615b813e 100644 > --- a/tests/invalid/no_ho_inst.err_exp > +++ b/tests/invalid/no_ho_inst.err_exp > @@ -1,14 +1,14 @@ > no_ho_inst.m:044: In clause for `run_loop(in, in, out, di, uo)': > no_ho_inst.m:044: in argument 1 (i.e. the predicate term) of higher-order > no_ho_inst.m:044: predicate call: > -no_ho_inst.m:044: mode error: context requires a predicate of arity 4. The > -no_ho_inst.m:044: type of AppHandler does match that expectation. However, to > -no_ho_inst.m:044: check the correctness of the call, the compiler also needs > -no_ho_inst.m:044: to know the modes of the arguments and the determinism of > -no_ho_inst.m:044: the predicate that AppHandler represents. The insts of > -no_ho_inst.m:044: higher order values should contain this information, but > -no_ho_inst.m:044: AppHandler's inst, which is `ground' at this point, does > -no_ho_inst.m:044: not. > +no_ho_inst.m:044: mode error: context requires a predicate of arity 4, and > +no_ho_inst.m:044: the type of AppHandler does match that expectation. > +no_ho_inst.m:044: However, to check the correctness of the call, the compiler > +no_ho_inst.m:044: also needs to know the modes of the arguments and the > +no_ho_inst.m:044: determinism of the predicate that AppHandler represents. > +no_ho_inst.m:044: The insts of higher order values should contain this > +no_ho_inst.m:044: information, but AppHandler's inst, which is `ground' at > +no_ho_inst.m:044: this point, does not. > no_ho_inst.m:044: > no_ho_inst.m:044: The fix for this error is to add this information. For > no_ho_inst.m:044: example, given a higher order type such as Unrelated: presumably AppHandler should quoted in that one since it's a program variable. ... > diff --git a/tests/invalid/polymorphic_unification.err_exp b/tests/invalid/polymorphic_unification.err_exp > index 9bf23a870..d806f5d73 100644 > --- a/tests/invalid/polymorphic_unification.err_exp > +++ b/tests/invalid/polymorphic_unification.err_exp > @@ -1,20 +1,20 @@ > polymorphic_unification.m:023: In clause for `p(in, (list.list_skel >> dead))': > polymorphic_unification.m:023: in polymorphically-typed unification: > -polymorphic_unification.m:023: mode error: variable `X' has instantiatedness > -polymorphic_unification.m:023: named inst list.list_skel > -polymorphic_unification.m:023: which expands to > -polymorphic_unification.m:023: named inst list.list_skel(free) > -polymorphic_unification.m:023: which expands to > -polymorphic_unification.m:023: bound( > -polymorphic_unification.m:023: [] > -polymorphic_unification.m:023: ; > -polymorphic_unification.m:023: '[|]'( > -polymorphic_unification.m:023: free, > -polymorphic_unification.m:023: named inst list.list_skel(free) > -polymorphic_unification.m:023: ) > -polymorphic_unification.m:023: ), > -polymorphic_unification.m:023: expected instantiatedness was `ground' or > -polymorphic_unification.m:023: `any'. > +polymorphic_unification.m:023: mode error: variable `X' has instantiatedness  > +polymorphic_unification.m:023: named inst list.list_skel > +polymorphic_unification.m:023: which expands to > +polymorphic_unification.m:023: named inst list.list_skel(free) > +polymorphic_unification.m:023: which expands to > +polymorphic_unification.m:023: bound( > +polymorphic_unification.m:023: [] > +polymorphic_unification.m:023: ; > +polymorphic_unification.m:023: '[|]'( > +polymorphic_unification.m:023: free, > +polymorphic_unification.m:023: named inst list.list_skel(free) > +polymorphic_unification.m:023: ) > +polymorphic_unification.m:023: ), > +polymorphic_unification.m:023: expected instantiatedness was `ground' or > +polymorphic_unification.m:023: `any'. I think it would look better not to color "or" there. > polymorphic_unification.m:023: When unifying two variables whose type will > polymorphic_unification.m:023: not be known until runtime, the variables must > polymorphic_unification.m:023: both be ground (or have inst `any'). Should this explanation not be colored with color_cause? The diff looks fine otherwise. Julien. From jfischer at opturion.com Wed May 1 23:49:04 2024 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 1 May 2024 23:49:04 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in det_report.m In-Reply-To: References: Message-ID: <5d913722-4f6-669a-7386-b4ab2affb35b@opturion.com> On Tue, 30 Apr 2024, Zoltan Somogyi wrote: > On 2024-04-29 20:57 +10:00 AEST, "Zoltan Somogyi" wrote: >>> "int" and "uint8" are now colored, but nothing else is. I think there >>> is a case to be made that the variable "N", which is the subject of the >>> message should stand out mode. >> >> That is a good idea. Internally, we could call that color "color_subject", >> as it denotes the subject of the error messsage. Does anyone have >> a better name in mind? And what should the default color shade for be? >> Some kind of blue, given that red, green and yellow are already in use >> for other things? Or should we rejig the existing colors? > > Unless I hear some other opinions by then, about this time tomorrow I intend to > > - add color_subject, with the default shade being a light cyan, probably 8-bit color 87, and color_subject is fine; I was going to suggest bright white as the color, but light cyan works as well. Julien. From zoltan.somogyi at runbox.com Thu May 2 01:01:01 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 02 May 2024 01:01:01 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in mode_errors.m In-Reply-To: Message-ID: On 2024-05-01 23:43 +10:00 AEST, "Julien Fischer" wrote: >> +bug117.m:028: Final instantiatedness of `X' was `ground', >> +bug117.m:028: expected final instantiatedness was  >> +bug117.m:028: named inst list.non_empty_list >> +bug117.m:028: which expands to >> +bug117.m:028: bound( >> +bug117.m:028: '[|]'(ground, ground) >> +bug117.m:028: ). > > I wonder if "named inst" and "which expands to" should not be colored, > so as the actual insts stand out. (OTOH, given the size some of those > inst expressions grow to the in the other messages I can see why you > did it this way.) The thing is, text of the form "named inst ..., which expands to ..." can occur not just at the top level, but in the middle of other insts as well. Treating the two cases differently is possible, but it would be a lot of work, and I don't think it is worthwhile. >> diff --git a/tests/invalid/coerce_clobbered.err_exp b/tests/invalid/coerce_clobbered.err_exp >> index c3c75f42a..1093ff05c 100644 >> --- a/tests/invalid/coerce_clobbered.err_exp >> +++ b/tests/invalid/coerce_clobbered.err_exp >> @@ -1,4 +1,4 @@ >> coerce_clobbered.m:021: In clause for `bad(in(clobbered), out)': >> coerce_clobbered.m:021: in coerce expression: >> coerce_clobbered.m:021: mode error: the argument term has instantiatedness >> -coerce_clobbered.m:021: `clobbered', but it must have a ground inst. >> +coerce_clobbered.m:021: `clobbered', but it must have a ground inst. > > Not related to color: it would be nice if this error message mentioned the name of the > argument term (i.e. Y in this case). The problem is harder than it looks, for two reasons. The more obvious one is that in superhomogeneous form, a coerce is always from one var to another, but the var being coerced may be an anonymous variable added by superhomogeneous.m. That means that printing the term being coerced would require reconstructing it from the construction unifications preceding the coerce goal. The less obvious one is that the code of modecheck_coerce.m can detect errors for which it itself has no variable to report about, because the error is not at the level of the top type_ctors of the types of X and Y, but one or more levels down. >> diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp >> index cc44364a4..b615b813e 100644 >> --- a/tests/invalid/no_ho_inst.err_exp >> +++ b/tests/invalid/no_ho_inst.err_exp >> @@ -1,14 +1,14 @@ >> no_ho_inst.m:044: In clause for `run_loop(in, in, out, di, uo)': >> no_ho_inst.m:044: in argument 1 (i.e. the predicate term) of higher-order >> no_ho_inst.m:044: predicate call: >> -no_ho_inst.m:044: mode error: context requires a predicate of arity 4. The >> -no_ho_inst.m:044: type of AppHandler does match that expectation. However, to >> -no_ho_inst.m:044: check the correctness of the call, the compiler also needs >> -no_ho_inst.m:044: to know the modes of the arguments and the determinism of >> -no_ho_inst.m:044: the predicate that AppHandler represents. The insts of >> -no_ho_inst.m:044: higher order values should contain this information, but >> -no_ho_inst.m:044: AppHandler's inst, which is `ground' at this point, does >> -no_ho_inst.m:044: not. >> +no_ho_inst.m:044: mode error: context requires a predicate of arity 4, and >> +no_ho_inst.m:044: the type of AppHandler does match that expectation. >> +no_ho_inst.m:044: However, to check the correctness of the call, the compiler >> +no_ho_inst.m:044: also needs to know the modes of the arguments and the >> +no_ho_inst.m:044: determinism of the predicate that AppHandler represents. >> +no_ho_inst.m:044: The insts of higher order values should contain this >> +no_ho_inst.m:044: information, but AppHandler's inst, which is `ground' at >> +no_ho_inst.m:044: this point, does not. >> no_ho_inst.m:044: >> no_ho_inst.m:044: The fix for this error is to add this information. For >> no_ho_inst.m:044: example, given a higher order type such as > > Unrelated: presumably AppHandler should quoted in that one since it's a program variable. As a variable, it must start with an upper case letter. I think that is sufficient to make it clear that it is variable, especially when I color its first occurrence with cyan. Do you disagree? >> diff --git a/tests/invalid/polymorphic_unification.err_exp b/tests/invalid/polymorphic_unification.err_exp >> index 9bf23a870..d806f5d73 100644 >> --- a/tests/invalid/polymorphic_unification.err_exp >> +++ b/tests/invalid/polymorphic_unification.err_exp >> @@ -1,20 +1,20 @@ >> polymorphic_unification.m:023: In clause for `p(in, (list.list_skel >> dead))': >> polymorphic_unification.m:023: in polymorphically-typed unification: >> -polymorphic_unification.m:023: mode error: variable `X' has instantiatedness >> -polymorphic_unification.m:023: named inst list.list_skel >> -polymorphic_unification.m:023: which expands to >> -polymorphic_unification.m:023: named inst list.list_skel(free) >> -polymorphic_unification.m:023: which expands to >> -polymorphic_unification.m:023: bound( >> -polymorphic_unification.m:023: [] >> -polymorphic_unification.m:023: ; >> -polymorphic_unification.m:023: '[|]'( >> -polymorphic_unification.m:023: free, >> -polymorphic_unification.m:023: named inst list.list_skel(free) >> -polymorphic_unification.m:023: ) >> -polymorphic_unification.m:023: ), >> -polymorphic_unification.m:023: expected instantiatedness was `ground' or >> -polymorphic_unification.m:023: `any'. >> +polymorphic_unification.m:023: mode error: variable `X' has instantiatedness  >> +polymorphic_unification.m:023: named inst list.list_skel >> +polymorphic_unification.m:023: which expands to >> +polymorphic_unification.m:023: named inst list.list_skel(free) >> +polymorphic_unification.m:023: which expands to >> +polymorphic_unification.m:023: bound( >> +polymorphic_unification.m:023: [] >> +polymorphic_unification.m:023: ; >> +polymorphic_unification.m:023: '[|]'( >> +polymorphic_unification.m:023: free, >> +polymorphic_unification.m:023: named inst list.list_skel(free) >> +polymorphic_unification.m:023: ) >> +polymorphic_unification.m:023: ), >> +polymorphic_unification.m:023: expected instantiatedness was `ground' or >> +polymorphic_unification.m:023: `any'. > > I think it would look better not to color "or" there. I will look into that, but I think that would be worthwhile only if decide to make this (don't color connectives) a rule. Should we? I am fine with either answer. I presume you vote "yes"; Peter, what do you think? >> polymorphic_unification.m:023: When unifying two variables whose type will >> polymorphic_unification.m:023: not be known until runtime, the variables must >> polymorphic_unification.m:023: both be ground (or have inst `any'). > > Should this explanation not be colored with color_cause? That text is not intended to *point out* a possible cause of the error; the red color in the text above gives the cause exactly. That text is printed only with -E, and it is intended to explain the rule that the buggy code broke. (Though in this case, it just gives the rule without doing much explaining.) It is thus a different kind of thing from I have used color_cause for so far. We *could* expand color_cause's remit, so to speak, to encompass this kind of thing as well, but in this case, I don't think it would be helpful, since it does not give any pointers to the possible cause of the error reported in red. > The diff looks fine otherwise. Thank you. Zoltan. From zoltan.somogyi at runbox.com Thu May 2 01:50:39 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 02 May 2024 01:50:39 +1000 (AEST) Subject: [m-rev.] for review: Fix codegen for subtype field names in high-level data grades. In-Reply-To: <20240430070815.17895-1-novalazy@gmail.com> Message-ID: On 2024-04-30 17:08 +10:00 AEST, "Peter Wang" wrote: > diff --git a/compiler/du_type_layout.m b/compiler/du_type_layout.m > index 64d7adbc7..f6fb17d69 100644 > --- a/compiler/du_type_layout.m > +++ b/compiler/du_type_layout.m > @@ -2,7 +2,7 @@ > % vim: ft=mercury ts=4 sw=4 et > %---------------------------------------------------------------------------% > % Copyright (C) 1993-2012 The University of Melbourne. > -% Copyright (C) 2015, 2017-2023 The Mercury team. > +% Copyright (C) 2015, 2017-2024 The Mercury team. > % This file may only be copied under the terms of the GNU General > % Public License - see the file COPYING in the Mercury distribution. > %---------------------------------------------------------------------------% > @@ -725,6 +725,8 @@ check_and_record_du_notag(TypeCtor, Context, Ctors, MaybeCanon, > MaybeDuRepn = have_errors([Spec]) > ; > MaybeCanon = canon, > + % We can only get here for a non-subtype du type. Do you think it would be helpful to include "non_sub" in the names of the predicates that can only be reached from fill_in_non_sub_du_type_repn? It would certainly make this code easier to check. > @@ -3781,9 +3802,12 @@ search_ctor_repn_by_unqual_name([CtorRepn | CtorRepns], UnqualName, Arity, > > make_subtype_constructor_arg_repn(CtorArg, BaseCtorArgRepn, CtorArgRepn) :- > CtorArg = ctor_arg(MaybeFieldName, ArgType, Context), > - BaseCtorArgRepn = ctor_arg_repn(_MaybeBaseFieldName, _BaseArgType, > - ArgPosWidth, _BaseContext), > - CtorArgRepn = ctor_arg_repn(MaybeFieldName, ArgType, ArgPosWidth, Context). > + BaseCtorArgRepn = ctor_arg_repn(MaybeBaseFieldName, BaseMaybeBaseCtorArg, > + _BaseArgType, ArgPosWidth, _BaseContext), > + expect(unify(BaseMaybeBaseCtorArg, no_base_ctor_arg), $pred, > + "BaseMaybeBaseCtorArg != no_base_ctor_arg"), > + CtorArgRepn = ctor_arg_repn(MaybeFieldName, > + base_ctor_arg(MaybeBaseFieldName), ArgType, ArgPosWidth, Context). I would add a pointer to this predicate in the comment above in the diff (which I deleted) which says "this is filled in later". > diff --git a/compiler/ml_code_util.m b/compiler/ml_code_util.m > index 766854c38..83c705fec 100644 > --- a/compiler/ml_code_util.m > +++ b/compiler/ml_code_util.m > @@ -235,14 +235,21 @@ > % > % Routines for dealing with fields. > % > - > - % Given the user-specified field name, if any, and the argument number > - % (starting from one), generate an MLDS field name for the target language > - % type that represents the function symbol's cell when we are generating > - % code with --high-level-data. > + % ml_gen_hld_field_name(MaybeFieldName, MaybeBaseCtorArg, ArgNum) = > + % FieldName: > % > -:- func ml_gen_hld_field_name(maybe(ctor_field_name), int) = > - mlds_field_var_name. > + % Generate an MLDS field name for the target language type that represents > + % the function symbol's cell when we are generating code with > + % --high-level-data. > + % > + % MaybeFieldName is the user-specified field name (if any). > + % MaybeBaseCtorArg tells if this is a field in a subtype, and if so, s/tells if/says whether/ > + % the field name of the corresponding constructor argument in the base type > + % (if any). Move the "(if any)" to just after "the field name". > diff --git a/compiler/ml_unify_gen_util.m b/compiler/ml_unify_gen_util.m > index a46b1435d..3dc626682 100644 > --- a/compiler/ml_unify_gen_util.m > +++ b/compiler/ml_unify_gen_util.m > @@ -319,7 +319,8 @@ allocate_consecutive_full_word_ctor_arg_repns_boxed(CurOffset, > [Var | Vars], [VarArgRepn | VarArgRepns]) :- > Type = ml_make_boxed_type, > ArgPosWidth = apw_full(arg_only_offset(CurOffset), cell_offset(CurOffset)), > - ArgRepn = ctor_arg_repn(no, Type, ArgPosWidth, dummy_context), > + ArgRepn = ctor_arg_repn(no, no_base_ctor_arg, Type, ArgPosWidth, > + dummy_context), > VarArgRepn = Var - ArgRepn, > allocate_consecutive_full_word_ctor_arg_repns_boxed(CurOffset + 1, > Vars, VarArgRepns). I would change the name of this predicate, deleting "_boxed" and replacing it with "_for_tuple". That would make clear that no_base_ctor_arg is justified here. > @@ -333,7 +334,8 @@ allocate_consecutive_full_word_ctor_arg_repns_lookup(Info, CurOffset, > [Var | Vars], [VarArgRepn | VarArgRepns]) :- > ml_variable_type_direct(Info, Var, Type), > ArgPosWidth = apw_full(arg_only_offset(CurOffset), cell_offset(CurOffset)), > - ArgRepn = ctor_arg_repn(no, Type, ArgPosWidth, dummy_context), > + ArgRepn = ctor_arg_repn(no, no_base_ctor_arg, Type, ArgPosWidth, > + dummy_context), > VarArgRepn = Var - ArgRepn, > allocate_consecutive_full_word_ctor_arg_repns_lookup(Info, CurOffset + 1, > Vars, VarArgRepns). I would consider something similar here, but I can't think of an expressive yet short suffix. > diff --git a/compiler/mlds.m b/compiler/mlds.m > index abb799a84..bf7d1da44 100644 > --- a/compiler/mlds.m > +++ b/compiler/mlds.m > @@ -2340,7 +2340,8 @@ > % When compiling with --high-level-data, we generate a type > % in the target language for each data constructor in a > % discriminated union type. This is the name of one of the fields > - % of this type. > + % of this type. For a subtype, this has to be the name of a field > + % in the base type. ... of THE CORRESPONDING field in the base type. The diff is otherwise fine. Zoltan. From novalazy at gmail.com Thu May 2 12:33:26 2024 From: novalazy at gmail.com (Peter Wang) Date: Thu, 2 May 2024 12:33:26 +1000 Subject: [m-rev.] for review: Fix codegen for subtype field names in high-level data grades. In-Reply-To: References: Message-ID: <20240502123326.GD1750@gmail.com> On Thu, 02 May 2024 01:50:39 +1000 "Zoltan Somogyi" wrote: > > On 2024-04-30 17:08 +10:00 AEST, "Peter Wang" wrote: > > diff --git a/compiler/du_type_layout.m b/compiler/du_type_layout.m > > index 64d7adbc7..f6fb17d69 100644 > > --- a/compiler/du_type_layout.m > > +++ b/compiler/du_type_layout.m > > @@ -2,7 +2,7 @@ > > % vim: ft=mercury ts=4 sw=4 et > > %---------------------------------------------------------------------------% > > % Copyright (C) 1993-2012 The University of Melbourne. > > -% Copyright (C) 2015, 2017-2023 The Mercury team. > > +% Copyright (C) 2015, 2017-2024 The Mercury team. > > % This file may only be copied under the terms of the GNU General > > % Public License - see the file COPYING in the Mercury distribution. > > %---------------------------------------------------------------------------% > > @@ -725,6 +725,8 @@ check_and_record_du_notag(TypeCtor, Context, Ctors, MaybeCanon, > > MaybeDuRepn = have_errors([Spec]) > > ; > > MaybeCanon = canon, > > + % We can only get here for a non-subtype du type. > > Do you think it would be helpful to include "non_sub" in the names > of the predicates that can only be reached from fill_in_non_sub_du_type_repn? > It would certainly make this code easier to check. Yes, done. > > > @@ -3781,9 +3802,12 @@ search_ctor_repn_by_unqual_name([CtorRepn | CtorRepns], UnqualName, Arity, > > > > make_subtype_constructor_arg_repn(CtorArg, BaseCtorArgRepn, CtorArgRepn) :- > > CtorArg = ctor_arg(MaybeFieldName, ArgType, Context), > > - BaseCtorArgRepn = ctor_arg_repn(_MaybeBaseFieldName, _BaseArgType, > > - ArgPosWidth, _BaseContext), > > - CtorArgRepn = ctor_arg_repn(MaybeFieldName, ArgType, ArgPosWidth, Context). > > + BaseCtorArgRepn = ctor_arg_repn(MaybeBaseFieldName, BaseMaybeBaseCtorArg, > > + _BaseArgType, ArgPosWidth, _BaseContext), > > + expect(unify(BaseMaybeBaseCtorArg, no_base_ctor_arg), $pred, > > + "BaseMaybeBaseCtorArg != no_base_ctor_arg"), > > + CtorArgRepn = ctor_arg_repn(MaybeFieldName, > > + base_ctor_arg(MaybeBaseFieldName), ArgType, ArgPosWidth, Context). > > I would add a pointer to this predicate in the comment above in the diff (which I deleted) > which says "this is filled in later". I've changed that particular comment to match the others which say "This predicate only deals with non-subtype du types", along with renaming the predicates. > > + % MaybeFieldName is the user-specified field name (if any). > > + % MaybeBaseCtorArg tells if this is a field in a subtype, and if so, > > s/tells if/says whether/ > > > + % the field name of the corresponding constructor argument in the base type > > + % (if any). > > Move the "(if any)" to just after "the field name". > Done. > > diff --git a/compiler/ml_unify_gen_util.m b/compiler/ml_unify_gen_util.m > > index a46b1435d..3dc626682 100644 > > --- a/compiler/ml_unify_gen_util.m > > +++ b/compiler/ml_unify_gen_util.m > > @@ -319,7 +319,8 @@ allocate_consecutive_full_word_ctor_arg_repns_boxed(CurOffset, > > [Var | Vars], [VarArgRepn | VarArgRepns]) :- > > Type = ml_make_boxed_type, > > ArgPosWidth = apw_full(arg_only_offset(CurOffset), cell_offset(CurOffset)), > > - ArgRepn = ctor_arg_repn(no, Type, ArgPosWidth, dummy_context), > > + ArgRepn = ctor_arg_repn(no, no_base_ctor_arg, Type, ArgPosWidth, > > + dummy_context), > > VarArgRepn = Var - ArgRepn, > > allocate_consecutive_full_word_ctor_arg_repns_boxed(CurOffset + 1, > > Vars, VarArgRepns). > > I would change the name of this predicate, deleting "_boxed" and replacing it > with "_for_tuple". That would make clear that no_base_ctor_arg is justified here. > > > @@ -333,7 +334,8 @@ allocate_consecutive_full_word_ctor_arg_repns_lookup(Info, CurOffset, > > [Var | Vars], [VarArgRepn | VarArgRepns]) :- > > ml_variable_type_direct(Info, Var, Type), > > ArgPosWidth = apw_full(arg_only_offset(CurOffset), cell_offset(CurOffset)), > > - ArgRepn = ctor_arg_repn(no, Type, ArgPosWidth, dummy_context), > > + ArgRepn = ctor_arg_repn(no, no_base_ctor_arg, Type, ArgPosWidth, > > + dummy_context), > > VarArgRepn = Var - ArgRepn, > > allocate_consecutive_full_word_ctor_arg_repns_lookup(Info, CurOffset + 1, > > Vars, VarArgRepns). > > I would consider something similar here, but I can't think of an expressive yet short suffix. > I've renamed those two predicates to allocate_consecutive_ctor_arg_repns_for_tuple allocate_consecutive_ctor_arg_repns_for_extra_args > > diff --git a/compiler/mlds.m b/compiler/mlds.m > > index abb799a84..bf7d1da44 100644 > > --- a/compiler/mlds.m > > +++ b/compiler/mlds.m > > @@ -2340,7 +2340,8 @@ > > % When compiling with --high-level-data, we generate a type > > % in the target language for each data constructor in a > > % discriminated union type. This is the name of one of the fields > > - % of this type. > > + % of this type. For a subtype, this has to be the name of a field > > + % in the base type. > > ... of THE CORRESPONDING field in the base type. > > The diff is otherwise fine. Thanks for the review. Peter From novalazy at gmail.com Thu May 2 18:16:00 2024 From: novalazy at gmail.com (Peter Wang) Date: Thu, 2 May 2024 18:16:00 +1000 Subject: [m-rev.] for review: options to control the use of color In-Reply-To: References: Message-ID: <20240502181600.GG1750@gmail.com> On Fri, 26 Apr 2024 06:47:20 +1000 "Zoltan Somogyi" wrote: > +init_color_db(OptionTable) = ColorDb :- > + getopt.lookup_bool_option(OptionTable, use_color_diagnostics, UseColors), > + ( > + UseColors = no, > + ColorDb = no_color_db > + ; > + UseColors = yes, > + MaybeColorSpecs = convert_color_spec_options(OptionTable), > + ( > + MaybeColorSpecs = error1(_Specs), > + % This should not happen, because handle_options.m should > + % report _Specs, and not let execution proceed any further. > + % But just in case ... > + ColorDb = no_color_db > + ; > + MaybeColorSpecs = ok1(ColorSpecs), > + ColorSpecs = color_specs(MaybeCorrect, MaybeIncorrect, MaybeCause), > + ( > + MaybeCorrect = yes(Correct) > + ; > + MaybeCorrect = no, > + Correct = color_8bit(40u8) % This is green. > + ), > + ( > + MaybeIncorrect = yes(Incorrect) > + ; > + MaybeIncorrect = no, > + Incorrect = color_8bit(203u8) % This is red. > + ), > + ( > + MaybeCause = yes(Cause) > + ; > + MaybeCause = no, > + Cause = color_8bit(11u8) % This is yellow. > + ), I think the compiler should stick to the original 16 colors by default, (1) for compatibility, and (2) the original 16 colors are the ones that the user might tweak to taste. > % The terminal control codes we use here are described by > % https://en.wikipedia.org/wiki/ANSI_escape_code#Colors. > % > :- func color_to_string(color) = string. > > -color_to_string(color_8bit(ColourNum)) = Str :- > - string.format("\033\[38;5;%dm", [i(uint8.cast_to_int(ColourNum))], Str). > -color_to_string(color_reset) = Str :- > - Str = "\033\[39;49m". > +color_to_string(SetOrReset) = Str :- > + ( > + SetOrReset = color_set(Color), > + Color = color_8bit(ColorNum), > + string.format("\033\[38;5;%dm", [i(uint8.cast_to_int(ColorNum))], Str) > + ; > + SetOrReset = color_reset, > + Str = "\033\[39;49m" > + ). It MIGHT be better to stick to the control codes 30-37, and use the bold attribute for bright colors, for compatibility with older terminal emulators. Peter From zoltan.somogyi at runbox.com Thu May 2 18:40:23 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 02 May 2024 18:40:23 +1000 (AEST) Subject: [m-rev.] for review: options to control the use of color In-Reply-To: <20240502181600.GG1750@gmail.com> Message-ID: On 2024-05-02 18:16 +10:00 AEST, "Peter Wang" wrote: >> + ColorSpecs = color_specs(MaybeCorrect, MaybeIncorrect, MaybeCause), >> + ( >> + MaybeCorrect = yes(Correct) >> + ; >> + MaybeCorrect = no, >> + Correct = color_8bit(40u8) % This is green. >> + ), >> + ( >> + MaybeIncorrect = yes(Incorrect) >> + ; >> + MaybeIncorrect = no, >> + Incorrect = color_8bit(203u8) % This is red. >> + ), >> + ( >> + MaybeCause = yes(Cause) >> + ; >> + MaybeCause = no, >> + Cause = color_8bit(11u8) % This is yellow. >> + ), > > I think the compiler should stick to the original 16 colors by default, > (1) for compatibility, and (2) the original 16 colors are the ones that > the user might tweak to taste. I don't think your conclusion follows from your objectives. As for (1), if all users have available on their terminals, the scheme that is currently implemented does allow them to override the defaults with a color that is drawn from the original 16 (or even the original 8) colors. I would be extremely surprised if anyone nowadays used Mercury on a terminal that is physically incapable of displaying 256 colors or more, so the only reason why they wouldn't be able to handle a 256-color palette is that they are using a crappy terminal emulator. I don't see any need to cater to them at the expense of the vast majority of our users. As for (2), yes, users can tweak the base 16 colors to their taste. However, in all the terminal emulators I know about, and certainly in the one I use, xterm on MATE, they cannot tweak them independently for different programs they run in the terminal. The colors you want for e.g. syntax coloring by vim may not be the ones you want for Mercury diagnostics, and 16 colors are few enough that *if* you limit all uses to just those 16 slots, then conflicts are just about inevitable. And, the scheme I implemented *does* let users tweak the colors Mercury uses to their taste, whether their taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit) colors. > It MIGHT be better to stick to the control codes 30-37, Only if you dismiss the arguments above. > and use the bold > attribute for bright colors, for compatibility with older terminal > emulators. So far, all use of color by Mercury diagnostic is for color contrast, not brightness contrast. I don't see any reason for this to change. Until it does, I think this is moot point. And *how much* older emulators are you talking about? I don't remember precisely, but I think have had 256+ color emulators for at least two decades now. Even the wikipedia page on 8-bit color says "Even though it is now outdated for most consumer applications, 8-bit color encoding can still be useful ...". Zoltan. From novalazy at gmail.com Thu May 2 19:34:19 2024 From: novalazy at gmail.com (Peter Wang) Date: Thu, 2 May 2024 19:34:19 +1000 Subject: [m-rev.] for review: options to control the use of color In-Reply-To: References: Message-ID: <20240502193419.GH2754@gmail.com> On Thu, 02 May 2024 18:40:23 +1000 "Zoltan Somogyi" wrote: > As for (2), yes, users can tweak the base 16 colors to their taste. However, > in all the terminal emulators I know about, and certainly in the one I use, > xterm on MATE, they cannot tweak them independently for different > programs they run in the terminal. Yes, but that's kind of the point. I can pick a palette of 16 colors that work well together, and expect programs to stick to that palette (obviously in the past there was no choice). As it is, the Mercury compiler wants to use THIS green, THIS red, THIS yellow. Why can't it just use the green/red/yellow that I've already chosen, without me having to override it? It's not like it's drawing a picture where no other shade will do. > The colors you want for e.g. syntax > coloring by vim may not be the ones you want for Mercury diagnostics, > and 16 colors are few enough that *if* you limit all uses to just those > 16 slots, then conflicts are just about inevitable. And, the scheme I implemented > *does* let users tweak the colors Mercury uses to their taste, whether their > taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit) > colors. Will the diagnostics really need that many different colors? It only needs a little bit of highlighting. Peter From zoltan.somogyi at runbox.com Thu May 2 19:44:21 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 02 May 2024 19:44:21 +1000 (AEST) Subject: [m-rev.] for review: options to control the use of color In-Reply-To: <20240502193419.GH2754@gmail.com> Message-ID: On 2024-05-02 19:34 +10:00 AEST, "Peter Wang" wrote: > On Thu, 02 May 2024 18:40:23 +1000 "Zoltan Somogyi" wrote: >> As for (2), yes, users can tweak the base 16 colors to their taste. However, >> in all the terminal emulators I know about, and certainly in the one I use, >> xterm on MATE, they cannot tweak them independently for different >> programs they run in the terminal. > > Yes, but that's kind of the point. I can pick a palette of 16 colors > that work well together, and expect programs to stick to that palette > (obviously in the past there was no choice). Users can pick the palette, but they can't pick which color will be used for what purpose. > As it is, the Mercury compiler wants to use THIS green, THIS red, THIS > yellow. Why can't it just use the green/red/yellow that I've already > chosen, without me having to override it? It's not like it's drawing a > picture where no other shade will do. My point is: people who want that *can* override the Mercury default, and this is a minute or two to look up the Mercury options, and add an entry to an Mmakefile or Mercury.options file. I believe that imposing this cost on the very few people who I expect would want to do this is preferable to imposing the same cost on the (I expect) larger number of people who don't want to be limited to the strong primary colors in the default 3-bit palette, which (on my terminal emulator, and on probably others) don't look so good. >> The colors you want for e.g. syntax >> coloring by vim may not be the ones you want for Mercury diagnostics, >> and 16 colors are few enough that *if* you limit all uses to just those >> 16 slots, then conflicts are just about inevitable. And, the scheme I implemented >> *does* let users tweak the colors Mercury uses to their taste, whether their >> taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit) >> colors. > > Will the diagnostics really need that many different colors? It uses four. The point is that *other* uses, such as syntax highlighting, already use all the available 3-bit colors, so even using one color by Mercury causes interference. Zoltan. From zoltan.somogyi at runbox.com Fri May 3 04:28:52 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 03 May 2024 04:28:52 +1000 (AEST) Subject: [m-rev.] diff: put the code that converts pieces to words into a separate predicate Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.pw Type: application/octet-stream Size: 1171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.pw Type: application/octet-stream Size: 31886 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 3 16:00:43 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 03 May 2024 16:00:43 +1000 (AEST) Subject: [m-rev.] for possible post-commit review: handle color changes next to prefixes/suffixes Message-ID: For review by anyone. I intend to commit this late tonight. In the absence of a review by then, I will address any comments post-commit. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.iw Type: application/octet-stream Size: 3717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.iw Type: application/octet-stream Size: 68135 bytes Desc: not available URL: From novalazy at gmail.com Fri May 3 17:27:55 2024 From: novalazy at gmail.com (Peter Wang) Date: Fri, 3 May 2024 17:27:55 +1000 Subject: [m-rev.] for review: options to control the use of color In-Reply-To: References: Message-ID: <20240503172755.GH2325@gmail.com> On Thu, 02 May 2024 19:44:21 +1000 "Zoltan Somogyi" wrote: > > On 2024-05-02 19:34 +10:00 AEST, "Peter Wang" wrote: > > On Thu, 02 May 2024 18:40:23 +1000 "Zoltan Somogyi" wrote: > >> As for (2), yes, users can tweak the base 16 colors to their taste. However, > >> in all the terminal emulators I know about, and certainly in the one I use, > >> xterm on MATE, they cannot tweak them independently for different > >> programs they run in the terminal. > > > > Yes, but that's kind of the point. I can pick a palette of 16 colors > > that work well together, and expect programs to stick to that palette > > (obviously in the past there was no choice). > > Users can pick the palette, but they can't pick which color will be used > for what purpose. I'm not arguing against allowing the user to configure which color for what purpose. > > As it is, the Mercury compiler wants to use THIS green, THIS red, THIS > > yellow. Why can't it just use the green/red/yellow that I've already > > chosen, without me having to override it? It's not like it's drawing a > > picture where no other shade will do. > > My point is: people who want that *can* override the Mercury default, > and this is a minute or two to look up the Mercury options, and add > an entry to an Mmakefile or Mercury.options file. I believe that imposing > this cost on the very few people who I expect would want to do this > is preferable to imposing the same cost on the (I expect) larger number of people > who don't want to be limited to the strong primary colors in the default 3-bit palette, > which (on my terminal emulator, and on probably others) don't look so good. > That's a good argument for configuring your terminal emulator to use a palette that you DO like, not to configure each program separately. > >> The colors you want for e.g. syntax > >> coloring by vim may not be the ones you want for Mercury diagnostics, > >> and 16 colors are few enough that *if* you limit all uses to just those > >> 16 slots, then conflicts are just about inevitable. And, the scheme I implemented > >> *does* let users tweak the colors Mercury uses to their taste, whether their > >> taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit) > >> colors. > > > > Will the diagnostics really need that many different colors? > > It uses four. The point is that *other* uses, such as syntax highlighting, > already use all the available 3-bit colors, so even using one color by Mercury > causes interference. I don't understand. I think there has been a misunderstanding. I am not suggesting to prevent users from using more than the basic 16 ANSI colors. It is very common to select a "color scheme" in a terminal emulator, which picks a color for each of the 16 ANSI color "slots". Any other colors beyond the basic 16 are not configurable (that I have seen), and who would want to pick 256 colors anyway? Programs that use the basic 16 ANSI colors will produce output on the screen that follows the user's chosen color scheme. The vast majority of command-line programs do this (including ls, grep, gcc, clang, ...), which is good, and expected. Otherwise, what would be the point of creating or picking a color scheme if programs ignored it? Programs which produce output using colors beyond the basic 16 will NOT follow the user's color scheme. I'm asking that the Mercury compiler respect the user's chosen color scheme by default, like most programs. That's it. Peter From zoltan.somogyi at runbox.com Sat May 4 00:25:19 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 04 May 2024 00:25:19 +1000 (AEST) Subject: [m-rev.] for review: options to control the use of color In-Reply-To: <20240503172755.GH2325@gmail.com> Message-ID: On 2024-05-03 17:27 +10:00 AEST, "Peter Wang" wrote: > On Thu, 02 May 2024 19:44:21 +1000 "Zoltan Somogyi" wrote: >> >> On 2024-05-02 19:34 +10:00 AEST, "Peter Wang" wrote: >> > On Thu, 02 May 2024 18:40:23 +1000 "Zoltan Somogyi" wrote: >> >> As for (2), yes, users can tweak the base 16 colors to their taste. However, >> >> in all the terminal emulators I know about, and certainly in the one I use, >> >> xterm on MATE, they cannot tweak them independently for different >> >> programs they run in the terminal. >> > >> > Yes, but that's kind of the point. I can pick a palette of 16 colors >> > that work well together, and expect programs to stick to that palette >> > (obviously in the past there was no choice). >> >> Users can pick the palette, but they can't pick which color will be used >> for what purpose. > > I'm not arguing against allowing the user to configure which color > for what purpose. I didn't think you were. I was attempting to point out the reason for why I think we are talking past each other. You are using the phrase "color scheme" to mean "use these 8 colors as the colors to display for the escape sequences CSI 30 to 37", or maybe "use these 16 colors to display for CSI 30 to 37 and 90 to 97". I am saying that this is not enough, because this does not, and CANNOT, achieve BY ITSELF what a user like me probably wants to accomplish, which is something like "I want vim color syntax highlighting to use red for characters past column 79, green for clause heads, yellow for string constants etc" AND "I want mmc to use red for incorrect, green for correct and yellow for possible error causes". This is because it is up to the code of vim and of mmc to pick which CSI escape sequence they use for each purpose. If e.g. mmc pics CSI 31 (which is red by default) to display incorrect code, but vim, through a vim syntax file, picks CSI 31 as the color to use for clause heads, and NOT as the color to use for chars past column 79, then THERE IS NO WAY you select the exact shade of red you like to get what you want with both programs simulatenously just by that action. Instead, you will have to do something to override the default in what one might call "role assignment". And as soon as you do that, the default does not matter much anymore, since you are explicitly ignoring it. >> > As it is, the Mercury compiler wants to use THIS green, THIS red, THIS >> > yellow. Why can't it just use the green/red/yellow that I've already >> > chosen, without me having to override it? It's not like it's drawing a >> > picture where no other shade will do. >> >> My point is: people who want that *can* override the Mercury default, >> and this is a minute or two to look up the Mercury options, and add >> an entry to an Mmakefile or Mercury.options file. I believe that imposing >> this cost on the very few people who I expect would want to do this >> is preferable to imposing the same cost on the (I expect) larger number of people >> who don't want to be limited to the strong primary colors in the default 3-bit palette, >> which (on my terminal emulator, and on probably others) don't look so good. >> > > That's a good argument for configuring your terminal emulator to use a > palette that you DO like, not to configure each program separately. As explained above, I am not talking about configuring the color palette. I am talking about configuring the color role assignment. >> >> The colors you want for e.g. syntax >> >> coloring by vim may not be the ones you want for Mercury diagnostics, >> >> and 16 colors are few enough that *if* you limit all uses to just those >> >> 16 slots, then conflicts are just about inevitable. And, the scheme I implemented >> >> *does* let users tweak the colors Mercury uses to their taste, whether their >> >> taste leads them to choose 3-bit or 4-bit colors, or 8-bit (or possibly later even 24-bit) >> >> colors. >> > >> > Will the diagnostics really need that many different colors? >> >> It uses four. The point is that *other* uses, such as syntax highlighting, >> already use all the available 3-bit colors, so even using one color by Mercury >> causes interference. > > I don't understand. I think there has been a misunderstanding. As the above part of my reply implies, I agree. > I am not suggesting to prevent users from using more than the basic > 16 ANSI colors. I didn't think you were. > It is very common to select a "color scheme" in a terminal emulator, > which picks a color for each of the 16 ANSI color "slots". I have little personal experience with that. On my work laptop, on which I use Mate and xterm, selecting the colors to go into those 16 color slots is a pretty bad experience, precisely because it does only half the job. It lets you pick the color to go into e.g. slot 5, but does not, and cannot, tell you what any particular program, such vim with a particular syntax file, will use the color in that slot FOR. So there is no way to pick the colors you want except by trial and error. And to top it all off, picking your preferred color scheme requires and entails setting up a "custom" color palette, but (as far I can tell) there is no way to actually SAVE this color palette anywhere. If you want to switch away even for a moment to try out e.g. the "xterm" or the "linux console" palette, there is NO WAY to get your possibly painfully set up custom palette back. I say "painfully" because when you click on a color slot in an attempt to change the color in that slot, the pop-op window you get gives you a sea of colors but gives you absolutely no clue about what clicking one of these colors would do. You have to figure it out by trial and error, which usually involves a nontrivial amount of cursing. On my Mac, the color preferences just let you pick your 16 colors. It also does not tell you what each will be used for; it can't, since there are far too many programs whose settings it would need to know about, including programs that did not exist or whose color role assignments have changed since that preferences panel was coded. At least it does not seem to let you destroy your custom setup with a single click. I have no idea whether things are so bad on other setups, but these experiences with two reasonably common systems lead me to believe that many people probably have a selection of colors in the standard 16 slots in their terminal that they treat as a black box that is not worth messing with > Any other colors beyond the basic 16 are not configurable > (that I have seen), and who would want to pick 256 colors anyway? Nobody. But that is not the same thing as "picking four colors from a selection of 256". > Programs that use the basic 16 ANSI colors will produce output on the > screen that follows the user's chosen color scheme. ... that will use the user's chosen color palette. That palette, if it was set up by the user, it was almost certainly set up to get the right overall *color assignment* by some program other than mmc, since users would need clairvoyance to set them up for mmc :-) > The vast majority of > command-line programs do this (including ls, grep, gcc, clang, ...), > which is good, and expected. Otherwise, what would be the point of > creating or picking a color scheme if programs ignored it? > > Programs which produce output using colors beyond the basic 16 will NOT > follow the user's color scheme. Trivially true, but for the reason listed above, also irrelevant in many cases, the cases where different programs use incompatible color assignments. (It is up to the users' taste what they view as incompatible.) > I'm asking that the Mercury compiler respect the user's chosen color > scheme by default, like most programs. That's it. Except users have chosen only a colors to go into the slots; the other half of the color scheme, the assignment from color slots to color roles, they have not chosen. I can see a way to resolve this impasse, which is: Mercury should have TWO sets of default colors. Mercury has (now) four color names: color_incorrect, color_correct, color_cause and the new color_subject. One default scheme would map each of these to one of the 16 color numbers, which correspond to CSI 30-37 and CSI 90-97, or, equivalently, to CSI 38 0-15. These color numbers are controlled by the user, using e.g. xterm preferences. The other default scheme, the current one, would map these color names to colors chosen by the us, the Mercury implementors, from the 256-color palette of CSI 38. Users could then chose the "default to use" by either an mmc option, or by a set-and-forget environment variable. tools/bootcheck would of course have to use the default that does not depend on the possibly-nonstandard color setup of the user running it, but can easily set, or not set, the required env var. It is obvious that Peter will vote vote for the first default as the "default to use" by default, the "default default" if you will, while I will vote for the second. That makes Julien the tie-breaker. I leave it up to you guys to propose the names of the options and env vars, provided of course that you accept this compromise. Zoltan. From jfischer at opturion.com Sat May 4 00:40:02 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sat, 4 May 2024 00:40:02 +1000 (AEST) Subject: [m-rev.] for possible post-commit review: handle color changes next to prefixes/suffixes In-Reply-To: References: Message-ID: <76aee82d-8252-b56-bd1c-9d8f27e3212d@opturion.com> On Fri, 3 May 2024, Zoltan Somogyi wrote: > Handle color changes next to prefixes/suffixes. > That looks fine. Julien. From jfischer at opturion.com Sat May 4 00:49:34 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sat, 4 May 2024 00:49:34 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in mode_errors.m In-Reply-To: References: Message-ID: <66ec9546-6243-2f8f-c581-9a1b3eb6b9ce@opturion.com> On Thu, 2 May 2024, Zoltan Somogyi wrote: > On 2024-05-01 23:43 +10:00 AEST, "Julien Fischer" wrote: >>> +bug117.m:028: Final instantiatedness of `X' was `ground', >>> +bug117.m:028: expected final instantiatedness was  >>> +bug117.m:028: named inst list.non_empty_list >>> +bug117.m:028: which expands to >>> +bug117.m:028: bound( >>> +bug117.m:028: '[|]'(ground, ground) >>> +bug117.m:028: ). >> >> I wonder if "named inst" and "which expands to" should not be colored, >> so as the actual insts stand out. (OTOH, given the size some of those >> inst expressions grow to the in the other messages I can see why you >> did it this way.) > > The thing is, text of the form "named inst ..., which expands to ..." can occur > not just at the top level, but in the middle of other insts as well. > Treating the two cases differently is possible, but it would be a lot of work, and > I don't think it is worthwhile. Hence, my comment in parentheses. ... >>> diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp >>> index cc44364a4..b615b813e 100644 >>> --- a/tests/invalid/no_ho_inst.err_exp >>> +++ b/tests/invalid/no_ho_inst.err_exp >>> @@ -1,14 +1,14 @@ >>> no_ho_inst.m:044: In clause for `run_loop(in, in, out, di, uo)': >>> no_ho_inst.m:044: in argument 1 (i.e. the predicate term) of higher-order >>> no_ho_inst.m:044: predicate call: >>> -no_ho_inst.m:044: mode error: context requires a predicate of arity 4. The >>> -no_ho_inst.m:044: type of AppHandler does match that expectation. However, to >>> -no_ho_inst.m:044: check the correctness of the call, the compiler also needs >>> -no_ho_inst.m:044: to know the modes of the arguments and the determinism of >>> -no_ho_inst.m:044: the predicate that AppHandler represents. The insts of >>> -no_ho_inst.m:044: higher order values should contain this information, but >>> -no_ho_inst.m:044: AppHandler's inst, which is `ground' at this point, does >>> -no_ho_inst.m:044: not. >>> +no_ho_inst.m:044: mode error: context requires a predicate of arity 4, and >>> +no_ho_inst.m:044: the type of AppHandler does match that expectation. >>> +no_ho_inst.m:044: However, to check the correctness of the call, the compiler >>> +no_ho_inst.m:044: also needs to know the modes of the arguments and the >>> +no_ho_inst.m:044: determinism of the predicate that AppHandler represents. >>> +no_ho_inst.m:044: The insts of higher order values should contain this >>> +no_ho_inst.m:044: information, but AppHandler's inst, which is `ground' at >>> +no_ho_inst.m:044: this point, does not. >>> no_ho_inst.m:044: >>> no_ho_inst.m:044: The fix for this error is to add this information. For >>> no_ho_inst.m:044: example, given a higher order type such as >> >> Unrelated: presumably AppHandler should quoted in that one since it's a program variable. > > As a variable, it must start with an upper case letter. I think that is sufficient > to make it clear that it is variable, especially when I color its first occurrence > with cyan. Do you disagree? We quote {program,type,inst} variables in *many* other error message: why do we not do it here? Julien. From zoltan.somogyi at runbox.com Sat May 4 00:59:20 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 04 May 2024 00:59:20 +1000 (AEST) Subject: [m-rev.] for possible post-commit review: handle color changes next to prefixes/suffixes In-Reply-To: <76aee82d-8252-b56-bd1c-9d8f27e3212d@opturion.com> Message-ID: On 2024-05-04 00:40 +10:00 AEST, "Julien Fischer" wrote: > > On Fri, 3 May 2024, Zoltan Somogyi wrote: > >> Handle color changes next to prefixes/suffixes. >> > > That looks fine. Thanks. The attached diff to a comment should have been part of that change. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.iw2 Type: application/octet-stream Size: 3901 bytes Desc: not available URL: From jfischer at opturion.com Sat May 4 01:02:38 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sat, 4 May 2024 01:02:38 +1000 (AEST) Subject: [m-rev.] for possible post-commit review: handle color changes next to prefixes/suffixes In-Reply-To: References: Message-ID: <101fcb40-fa31-2c8f-788e-d2a71d9828b8@opturion.com> On Sat, 4 May 2024, Zoltan Somogyi wrote: > > On 2024-05-04 00:40 +10:00 AEST, "Julien Fischer" wrote: >> >> On Fri, 3 May 2024, Zoltan Somogyi wrote: >> >>> Handle color changes next to prefixes/suffixes. >>> >> >> That looks fine. > > Thanks. The attached diff to a comment should have been part > of that change. > diff --git a/compiler/write_error_spec.m b/compiler/write_error_spec.m > index 45f356510..54f368e47 100644 > --- a/compiler/write_error_spec.m > +++ b/compiler/write_error_spec.m > @@ -1011,6 +1011,21 @@ convert_words_to_paragraphs_acc(ColorDb, [Word | Words], > record_text_word(TextWord, !Done, !InWork) > ; > Word = word_color(ColorChange), > + % Note how with color_start, we want to put any space *before* > + % the color change, while with color_end, we want to put any space > + % *after* the color change. The objective is to enable color > + % only for the shortest span of characters to accomplish the > + % intended coloring effect. This may not matter much when the > + % output we generate gets viewed by a user, but it matters when > + % we as developers work with .err_exp files in the test directories > + % that test diagnostic outputs. > + % > + % It simply easier to visually check whether the output of a diff It *is* > + % between an .err file containing new or updated diagnostic output > + % and the existing .err_exp file contains just the expected changes > + % if neither file contains color change escape sequences that are > + % effectively no-ops. (The addition or deletion of such a no-op > + % sequence would show up in the diff as a red herring.) > ( > ColorChange = color_start(_), > Done0 = !.Done, Julien. From zoltan.somogyi at runbox.com Sat May 4 01:03:02 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 04 May 2024 01:03:02 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in mode_errors.m In-Reply-To: <66ec9546-6243-2f8f-c581-9a1b3eb6b9ce@opturion.com> Message-ID: On 2024-05-04 00:49 +10:00 AEST, "Julien Fischer" wrote: >>>> diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp >>>> index cc44364a4..b615b813e 100644 >>>> --- a/tests/invalid/no_ho_inst.err_exp >>>> +++ b/tests/invalid/no_ho_inst.err_exp >>>> @@ -1,14 +1,14 @@ >>>> no_ho_inst.m:044: In clause for `run_loop(in, in, out, di, uo)': >>>> no_ho_inst.m:044: in argument 1 (i.e. the predicate term) of higher-order >>>> no_ho_inst.m:044: predicate call: >>>> -no_ho_inst.m:044: mode error: context requires a predicate of arity 4. The >>>> -no_ho_inst.m:044: type of AppHandler does match that expectation. However, to >>>> -no_ho_inst.m:044: check the correctness of the call, the compiler also needs >>>> -no_ho_inst.m:044: to know the modes of the arguments and the determinism of >>>> -no_ho_inst.m:044: the predicate that AppHandler represents. The insts of >>>> -no_ho_inst.m:044: higher order values should contain this information, but >>>> -no_ho_inst.m:044: AppHandler's inst, which is `ground' at this point, does >>>> -no_ho_inst.m:044: not. >>>> +no_ho_inst.m:044: mode error: context requires a predicate of arity 4, and >>>> +no_ho_inst.m:044: the type of AppHandler does match that expectation. >>>> +no_ho_inst.m:044: However, to check the correctness of the call, the compiler >>>> +no_ho_inst.m:044: also needs to know the modes of the arguments and the >>>> +no_ho_inst.m:044: determinism of the predicate that AppHandler represents. >>>> +no_ho_inst.m:044: The insts of higher order values should contain this >>>> +no_ho_inst.m:044: information, but AppHandler's inst, which is `ground' at >>>> +no_ho_inst.m:044: this point, does not. >>>> no_ho_inst.m:044: >>>> no_ho_inst.m:044: The fix for this error is to add this information. For >>>> no_ho_inst.m:044: example, given a higher order type such as >>> >>> Unrelated: presumably AppHandler should quoted in that one since it's a program variable. >> >> As a variable, it must start with an upper case letter. I think that is sufficient >> to make it clear that it is variable, especially when I color its first occurrence >> with cyan. Do you disagree? > > We quote {program,type,inst} variables in *many* other error message: > why do we not do it here? Which version of that error message do you think is more readable, the version above, or a version with quotes around every occurrence of AppHandler? I happen to think that - the version without quote is more readable, and - this consideration is more important than following the usual pattern. Which of those propositions do you disagree with? Zoltan. From jfischer at opturion.com Sat May 4 01:18:26 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sat, 4 May 2024 01:18:26 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in mode_errors.m In-Reply-To: References: Message-ID: <9245692-1125-562e-4266-4dda6473ed2@opturion.com> On Sat, 4 May 2024, Zoltan Somogyi wrote: > On 2024-05-04 00:49 +10:00 AEST, "Julien Fischer" wrote: >>>>> diff --git a/tests/invalid/no_ho_inst.err_exp b/tests/invalid/no_ho_inst.err_exp >>>>> index cc44364a4..b615b813e 100644 >>>>> --- a/tests/invalid/no_ho_inst.err_exp >>>>> +++ b/tests/invalid/no_ho_inst.err_exp >>>>> @@ -1,14 +1,14 @@ >>>>> no_ho_inst.m:044: In clause for `run_loop(in, in, out, di, uo)': >>>>> no_ho_inst.m:044: in argument 1 (i.e. the predicate term) of higher-order >>>>> no_ho_inst.m:044: predicate call: >>>>> -no_ho_inst.m:044: mode error: context requires a predicate of arity 4. The >>>>> -no_ho_inst.m:044: type of AppHandler does match that expectation. However, to >>>>> -no_ho_inst.m:044: check the correctness of the call, the compiler also needs >>>>> -no_ho_inst.m:044: to know the modes of the arguments and the determinism of >>>>> -no_ho_inst.m:044: the predicate that AppHandler represents. The insts of >>>>> -no_ho_inst.m:044: higher order values should contain this information, but >>>>> -no_ho_inst.m:044: AppHandler's inst, which is `ground' at this point, does >>>>> -no_ho_inst.m:044: not. >>>>> +no_ho_inst.m:044: mode error: context requires a predicate of arity 4, and >>>>> +no_ho_inst.m:044: the type of AppHandler does match that expectation. >>>>> +no_ho_inst.m:044: However, to check the correctness of the call, the compiler >>>>> +no_ho_inst.m:044: also needs to know the modes of the arguments and the >>>>> +no_ho_inst.m:044: determinism of the predicate that AppHandler represents. >>>>> +no_ho_inst.m:044: The insts of higher order values should contain this >>>>> +no_ho_inst.m:044: information, but AppHandler's inst, which is `ground' at >>>>> +no_ho_inst.m:044: this point, does not. >>>>> no_ho_inst.m:044: >>>>> no_ho_inst.m:044: The fix for this error is to add this information. For >>>>> no_ho_inst.m:044: example, given a higher order type such as >>>> >>>> Unrelated: presumably AppHandler should quoted in that one since it's a program variable. >>> >>> As a variable, it must start with an upper case letter. I think that is sufficient >>> to make it clear that it is variable, especially when I color its first occurrence >>> with cyan. Do you disagree? >> >> We quote {program,type,inst} variables in *many* other error message: >> why do we not do it here? > > Which version of that error message do you think is more readable, > the version above, or a version with quotes around every occurrence > of AppHandler? I think it's clear enough when the name of the variable in question is something like AppHandler, less so if the subject of the error message were something like P. Julien. From zoltan.somogyi at runbox.com Sat May 4 02:20:10 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 04 May 2024 02:20:10 +1000 (AEST) Subject: [m-rev.] for post-commit review: add color in mode_errors.m In-Reply-To: <66ec9546-6243-2f8f-c581-9a1b3eb6b9ce@opturion.com> Message-ID: On 2024-05-04 00:49 +10:00 AEST, "Julien Fischer" wrote: > We quote {program,type,inst} variables in *many* other error message: > why do we not do it here? Your argument in your following email convinced me, and I will add quotes here. But this raises a more general point. Variables are often the subjects of error messages. If we color the variable name as the subject, should the coloring extend to the quotes around the name? I think it should, both because it probably looks better, and because we can express it using existing pieces in error_spec.m, while leaving the quotes uncolored would need a new mechanism there. Zoltan. From zoltan.somogyi at runbox.com Sat May 4 03:16:49 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 04 May 2024 03:16:49 +1000 (AEST) Subject: [m-rev.] for post-commit review: act on two of Julien's requests about mode errors Message-ID: Julien may wish to verify that these do what he asked for. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.mej Type: application/octet-stream Size: 425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.mej Type: application/octet-stream Size: 4932 bytes Desc: not available URL: From jfischer at opturion.com Sat May 4 16:51:20 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sat, 4 May 2024 16:51:20 +1000 (AEST) Subject: [m-rev.] diff: align functions on word boundaries with clang Message-ID: Align functions on word boundaries with clang. Function trailing with tagged trail entries does not work unless the functions are aligned on word boundaries. In trailing grades with GCC, we have long passed an option (-falign-functions) to force this to happen. Do the same for clang, which supports the same option. This fixes the failure of function trailing tests on Apple Silicon based machines. (This does not appear an issue on Intel-based Macs.) scripts/mgnuc.in: compiler/compile_target_code.m: Tell clang to align functions on word boundaries in trailing grades. Julien. diff --git a/compiler/compile_target_code.m b/compiler/compile_target_code.m index d7acfdac8..0f6d2ec5a 100644 --- a/compiler/compile_target_code.m +++ b/compiler/compile_target_code.m @@ -409,22 +409,23 @@ gather_c_compiler_flags(Globals, PIC, AllCFlags) :- UseTrail = yes, % With tagged trail entries function trailing will not work unless the % C functions stored on the trail are aligned on word boundaries (or a - % multiple thereof). The assemblers on some systems, and some gcc - % optimisation settings, do not align functions, so we need to + % multiple thereof). The assemblers on some systems, and some gcc or + % clang optimisation settings, do not align functions, so we need to % explicitly pass -falign-functions in trailing grades to ensure that % C functions are appropriately aligned. % % Note that this will also affect the untagged version of the trail, % but that shouldn't matter. ( - C_CompilerType = cc_gcc(_, _, _), + ( C_CompilerType = cc_gcc(_, _, _) + ; C_CompilerType = cc_clang(_) + ), globals.lookup_int_option(Globals, bytes_per_word, BytesPerWord), C_FnAlignOpt = string.format("-falign-functions=%d ", [i(BytesPerWord)]) ; % XXX Check whether we need to do anything for these C compilers? - ( C_CompilerType = cc_clang(_) - ; C_CompilerType = cc_cl_x86(_) + ( C_CompilerType = cc_cl_x86(_) ; C_CompilerType = cc_cl_x64(_) ), C_FnAlignOpt = "" diff --git a/scripts/mgnuc.in b/scripts/mgnuc.in index 1ba02f593..8ddefe653 100644 --- a/scripts/mgnuc.in +++ b/scripts/mgnuc.in @@ -393,8 +393,8 @@ case ${use_trail} in # See the comment in compile_c_file/7 in compiler/compile_target_code.m # for an explanation of this. case ${COMPILER} in - gcc) FN_ALIGN_OPTS="-falign-functions=${BYTES_PER_WORD}" ;; - *) FN_ALIGN_OPTS="" ;; + gcc|clang) FN_ALIGN_OPTS="-falign-functions=${BYTES_PER_WORD}" ;; + *) FN_ALIGN_OPTS="" ;; esac ;; false) From zoltan.somogyi at runbox.com Sun May 5 09:49:12 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 05 May 2024 09:49:12 +1000 (AEST) Subject: [m-rev.] for post-commit review; start using color for the subjects of diagnostics Message-ID: This diff starts implementation of Julien's suggestion from a few days ago. For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.subj Type: application/octet-stream Size: 2566 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.subj Type: application/octet-stream Size: 95285 bytes Desc: not available URL: From novalazy at gmail.com Sun May 5 13:11:14 2024 From: novalazy at gmail.com (Peter Wang) Date: Sun, 5 May 2024 13:11:14 +1000 Subject: [m-rev.] for review: options to control the use of color In-Reply-To: References: Message-ID: <20240505131114.GK2024@gmail.com> On Sat, 04 May 2024 00:25:19 +1000 "Zoltan Somogyi" wrote: > > I have no idea whether things are so bad on other setups, > but these experiences with two reasonably common systems > lead me to believe that many people probably have a selection of colors > in the standard 16 slots in their terminal that they treat as a black box > that is not worth messing with If you search for terminal color schemes or themes, you will find a plethora of schemes that people have created. What that says, I leave to you. > > I'm asking that the Mercury compiler respect the user's chosen color > > scheme by default, like most programs. That's it. > > Except users have chosen only a colors to go into the slots; the other half of > the color scheme, the assignment from color slots to color roles, > they have not chosen. Right, this seems to be the heart of the disagreement. I don't care to configure the second half, the assignment of color slots to roles, assuming they are somewhat sensible (which they are). This applies to other programs, too. > I leave it up to you guys to propose the names of the options and env vars, > provided of course that you accept this compromise. I would have proposed the same thing if you didn't change your mind. My suggestion: --color-scheme=dark16|dark256|light16|light256 MERCURY_COLOR_SCHEME (environment variable) (or theme instead of scheme; the two words seem to be used interchangeably) The "light" schemes would use normal (non-bright) colors, which look better on a light background. Bright yellow text, in particular, is completely unreadable on a white background. Bright green and bright cyan are marginal. If we abstain from using bright yellow text, the "dark" schemes would probably not be too objectionable on a light background. I think it's important that the compiler output be readable for everyone out of the box. That means either not enabling colors by default, or defaulting to a scheme that does not use bright yellow. FWIW, this is what I found in the GCC manual, in terms of the colors that they find acceptable to use by default: The default ‘GCC_COLORS’ is error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\ quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\ diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\ type-diff=01;32:fnname=01;32:targs=35 where ‘01;31’ is bold red, ‘01;35’ is bold magenta, ‘01;36’ is bold cyan, ‘32’ is green, ‘34’ is blue, ‘01’ is bold, and ‘31’ is red. Setting ‘GCC_COLORS’ to the empty string disables colors. Peter From jfischer at opturion.com Sun May 5 22:51:54 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 5 May 2024 22:51:54 +1000 (AEST) Subject: [m-rev.] for post-commit review; start using color for the subjects of diagnostics In-Reply-To: References: Message-ID: <18608c25-fa4e-2644-398c-99f1428dd79@opturion.com> On Sun, 5 May 2024, Zoltan Somogyi wrote: > Color the subjects of error messages. > > compiler/error_spec.m: > Add a new color name, color_subject, which is intended to be used > as the color for the subject of an error message. The subject is > usually a variable or a term. > > compiler/options.m: > doc/user_guide.texi: > Add an option to control the actual color for this color name. > > compiler/globals.m: > Include the new color in the color specification database. > > compiler/write_error_spec.m: > Handle the conversion of the new color name to the selected > corresponding actual color. > > compiler/typecheck_errors.m: > Color the subjects of (most of) the error messages generated by > this module with the new color. I've just stepped through a bunch of the new outputs with the latest ROTD. I think coloring the subject is an improvement. The diff is fine. Julien. From zoltan.somogyi at runbox.com Tue May 7 09:32:19 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 07 May 2024 09:32:19 +1000 (AEST) Subject: [m-rev.] forpost-commit review: color subjects in mode errors Message-ID: For review by anyone. I would particularly like feedback on the XXXs added to mode_errors.m. The test case on which the things they complain about can best be seen is constrained_poly_insts2 in invalid. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.sme Type: application/octet-stream Size: 4003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.sme Type: application/octet-stream Size: 170942 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 7 10:09:35 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 07 May 2024 10:09:35 +1000 (AEST) Subject: [m-rev.] for review: options to control the use of color In-Reply-To: <20240505131114.GK2024@gmail.com> Message-ID: On 2024-05-05 13:11 +10:00 AEST, "Peter Wang" wrote: > On Sat, 04 May 2024 00:25:19 +1000 "Zoltan Somogyi" wrote: >> I have no idea whether things are so bad on other setups, >> but these experiences with two reasonably common systems >> lead me to believe that many people probably have a selection of colors >> in the standard 16 slots in their terminal that they treat as a black box >> that is not worth messing with > > If you search for terminal color schemes or themes, you will find a > plethora of schemes that people have created. I know that; I did that search myself many years ago when I started using syntax highlighting, and I know the pile would have grown a lot since then. > What that says, I leave to you. The existence of many people who create color schemes is perfectly compatible with the idea that most people would prefer not to have to do that job. >> > I'm asking that the Mercury compiler respect the user's chosen color >> > scheme by default, like most programs. That's it. >> >> Except users have chosen only a colors to go into the slots; the other half of >> the color scheme, the assignment from color slots to color roles, >> they have not chosen. > > Right, this seems to be the heart of the disagreement. I don't care to > configure the second half, the assignment of color slots to roles, > assuming they are somewhat sensible (which they are). > This applies to other programs, too. For me, the "assuming they are somewhat sensible" part is the problem, for the simple reason that in this instance, what is "sensible" is a question of taste, and "de gustibus non disputandum", i.e. there is no point in arguing about taste. The reason why I created a custom scheme for myself is precisely the fact that I didn't like any of the ones I initially found, and found more than a few to be downright ugly. >> I leave it up to you guys to propose the names of the options and env vars, >> provided of course that you accept this compromise. > > I would have proposed the same thing if you didn't change your mind. > > My suggestion: > > --color-scheme=dark16|dark256|light16|light256 > > MERCURY_COLOR_SCHEME (environment variable) > (or theme instead of scheme; the two words seem to be used > interchangeably) I presume the difference between 16 and 256 is that - the 16 versions use the 16 color slots that users can configure for themselves, and which are set up to use the 8 normal and 8 bright colors of the original 4-color VGA palette in the absence of such configuration, while - the 256 versions use color slots 16-255 of the 8 bit color palette, which users can't reconfigure, and in both cases, we would pick the slot numbers. Are those presumptions correct? Another question: what exactly do light and dark mean in these names? Does "light" mean "light colors for dark backgrounds" or "dark colors for light backgrounds"? Should the names be changed to disambiguate this? lightbg and darkbg, perhaps? > The "light" schemes would use normal (non-bright) colors, which look > better on a light background. Agreed. > Bright yellow text, in particular, is > completely unreadable on a white background. Again, agreed. I will keep on using it for now, because I have to use something. I can do a global replace of all the .err_exp files containing it once we agree on a default scheme. > Bright green and bright > cyan are marginal. I think green and cyan both have shades that are readable on both white and black blackgrounds, and I would expect that some of those shades would be on the 256-color palette, though I have not yet verified this. > If we abstain from using bright yellow text, the > "dark" schemes would probably not be too objectionable on a light > background. Yes, it should be possible to pick color slots for which this is true. If those slots are configurable and configured, then all bets are off. > I think it's important that the compiler output be readable for everyone > out of the box. I agree that that is an important objective. > That means either not enabling colors by default, > or defaulting to a scheme that does not use bright yellow. I am fine with either. > FWIW, this is what I found in the GCC manual, in terms of the colors > that they find acceptable to use by default: > > The default ‘GCC_COLORS’ is > error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\ > quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\ > diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\ > type-diff=01;32:fnname=01;32:targs=35 > where ‘01;31’ is bold red, ‘01;35’ is bold magenta, ‘01;36’ is bold > cyan, ‘32’ is green, ‘34’ is blue, ‘01’ is bold, and ‘31’ is red. > Setting ‘GCC_COLORS’ to the empty string disables colors. I looked up the documentation of GCC_COLORS in "man gcc", and I can say that the person who implemented colors for gcc was definitely EVIL. My evidence for that assertion is that they actually implemented *blinking text* :-) I have no objection to having the main means of letting users specify colors be a similar environment variable, though I would strongly prefer for the env var to specify *only* foreground colors, and not background color, or things such as bold. This is because supporting multiple attributes (such as bold/nonbold, foreground color and background color) that can be set independently, the code required to implement the end of their scopes will need to be more complicated than the code we have now, which is already complicated enough. Zoltan. From zoltan.somogyi at runbox.com Tue May 7 15:48:59 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 07 May 2024 15:48:59 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in determinism and purity diagnostics Message-ID: For review by anyone. The only thing I can think of being a semantic (as opposed to cosmetic) issue is requiring any predicate named main/2 to be exported. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.sdp Type: application/vnd.sun.xml.impress Size: 1891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.sdp Type: application/vnd.sun.xml.impress Size: 54655 bytes Desc: not available URL: From novalazy at gmail.com Tue May 7 16:25:21 2024 From: novalazy at gmail.com (Peter Wang) Date: Tue, 7 May 2024 16:25:21 +1000 Subject: [m-rev.] for review: options to control the use of color In-Reply-To: References: Message-ID: <20240507162521.GQ2461@gmail.com> On Tue, 07 May 2024 10:09:35 +1000 "Zoltan Somogyi" wrote: > >> I leave it up to you guys to propose the names of the options and env vars, > >> provided of course that you accept this compromise. > > > > I would have proposed the same thing if you didn't change your mind. > > > > My suggestion: > > > > --color-scheme=dark16|dark256|light16|light256 > > > > MERCURY_COLOR_SCHEME (environment variable) > > (or theme instead of scheme; the two words seem to be used > > interchangeably) > > I presume the difference between 16 and 256 is that > > - the 16 versions use the 16 color slots that users can configure > for themselves, and which are set up to use the 8 normal and 8 bright colors > of the original 4-color VGA palette in the absence of such > configuration, while > > - the 256 versions use color slots 16-255 of the 8 bit color palette, > which users can't reconfigure, > > and in both cases, we would pick the slot numbers. > > Are those presumptions correct? Yes. Also, some or all of these could be equivalent to disabling color (unless overridden by another option): --color-scheme=none MERCURY_COLOR_SCHEME="" MERCURY_COLOR_SCHEME=none > Another question: what exactly do light and dark mean in these names? > Does "light" mean "light colors for dark backgrounds" or "dark colors > for light backgrounds"? Should the names be changed to disambiguate this? > lightbg and darkbg, perhaps? I don't think that's necessary. CSS, mobile devices, and many applications all have a "dark mode" or "dark themes", which refer to a light-on-dark color scheme. https://en.wikipedia.org/wiki/Light-on-dark_color_scheme > > That means either not enabling colors by default, > > or defaulting to a scheme that does not use bright yellow. > > I am fine with either. Ok. > > FWIW, this is what I found in the GCC manual, in terms of the colors > > that they find acceptable to use by default: > > > > The default ‘GCC_COLORS’ is > > error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\ > > quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\ > > diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\ > > type-diff=01;32:fnname=01;32:targs=35 > > where ‘01;31’ is bold red, ‘01;35’ is bold magenta, ‘01;36’ is bold > > cyan, ‘32’ is green, ‘34’ is blue, ‘01’ is bold, and ‘31’ is red. > > Setting ‘GCC_COLORS’ to the empty string disables colors. > > I looked up the documentation of GCC_COLORS in "man gcc", > and I can say that the person who implemented colors for gcc > was definitely EVIL. My evidence for that assertion is that they > actually implemented *blinking text* :-) > Right. (Though, they are just listing the attributes available via SGR parameters.) > I have no objection to having the main means of letting users > specify colors be a similar environment variable, though I would > strongly prefer for the env var to specify *only* foreground colors, > and not background color, or things such as bold. I agree, we don't need to allow all that. If we *did* introduce an environment variable similar to GCC_COLORS, would you keep the --set-color-* options as well? I think very few people would be using either; we needn't dedicate that much code and documentation to configuring colors. Peter From zoltan.somogyi at runbox.com Tue May 7 16:46:54 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 07 May 2024 16:46:54 +1000 (AEST) Subject: [m-rev.] for review: options to control the use of color In-Reply-To: <20240507162521.GQ2461@gmail.com> Message-ID: On 2024-05-07 16:25 +10:00 AEST, "Peter Wang" wrote: > Also, some or all of these could be equivalent to disabling color > (unless overridden by another option): > > --color-scheme=none > MERCURY_COLOR_SCHEME="" > MERCURY_COLOR_SCHEME=none "none" I definitely agree. I am not sure about MERCURY_COLOR_SCHEME="". While any shell scripts I write use sh/bash, my interactive shell has been tcsh for about three decades now. I know how to unset an env var in tcsh: just "unsetenv varname". I don't know how to do that sh/bash. Does an assignment of the empty string to a sh or bash var, followed by an export of the var unset the environment variable, or does it just set it to the empty string? And if the latter, how *do* you unset an envvar in sh/bash? >> Another question: what exactly do light and dark mean in these names? >> Does "light" mean "light colors for dark backgrounds" or "dark colors >> for light backgrounds"? Should the names be changed to disambiguate this? >> lightbg and darkbg, perhaps? > > I don't think that's necessary. CSS, mobile devices, and many applications > all have a "dark mode" or "dark themes", which refer to a light-on-dark > color scheme. > https://en.wikipedia.org/wiki/Light-on-dark_color_scheme I agree that "dark mode" is clear on this point. I don't think "dark16" is. That said, I wouldn't object to including "mode" in the name of the scheme. >> I looked up the documentation of GCC_COLORS in "man gcc", >> and I can say that the person who implemented colors for gcc >> was definitely EVIL. My evidence for that assertion is that they >> actually implemented *blinking text* :-) >> > > Right. (Though, they are just listing the attributes available via > SGR parameters.) Yes, I know. I still think it is evil, for the same reason Nazi generals saying "I was just obeying orders when I ordered the POWs to be shot" was evil. > If we *did* introduce an environment variable similar to GCC_COLORS, > would you keep the --set-color-* options as well? I think very few > people would be using either; we needn't dedicate that much code and > documentation to configuring colors. We will want the options anyway. Without them, every error_spec being written out will need to parse the envvar's text to find the color shades to use. That would not be a problem, except you have to be prepared for the parse to fail, in which case you want to report its failure. However, you don't want to report it a dozen times if the program wants to print a dozen diagnostics. The simple way to handle this is to parse the env var just once in handle_options.m, report any errors in that parse at that time, record the results of the parse, or the results of the recovery process from any parse errors, in the option table, and then let the rest of the compiler get its color info from those options. Normally, we would actually record this info in specialized parts of the globals structure, i.e. in the parts that are NOT the option table, but in this case, we can't do that. The reason is that write_error_spec.m has to work when all it has is an option_table. And the reason for *that* is to enable it to report the errors that handle_options.m can discover while it is deciding what should go into the very first globals structure. Given that we need the options for internal purposes, giving them names that allow them to be used from command lines should cost us only a few lines of documentation in options.m and user_guide.texi. Zoltan. From novalazy at gmail.com Tue May 7 17:34:12 2024 From: novalazy at gmail.com (Peter Wang) Date: Tue, 7 May 2024 17:34:12 +1000 Subject: [m-rev.] for review: options to control the use of color In-Reply-To: References: Message-ID: <20240507173412.GA2461@gmail.com> On Tue, 07 May 2024 16:46:54 +1000 "Zoltan Somogyi" wrote: > > On 2024-05-07 16:25 +10:00 AEST, "Peter Wang" wrote: > > Also, some or all of these could be equivalent to disabling color > > (unless overridden by another option): > > > > --color-scheme=none > > MERCURY_COLOR_SCHEME="" > > MERCURY_COLOR_SCHEME=none > > "none" I definitely agree. I am not sure about MERCURY_COLOR_SCHEME="". > While any shell scripts I write use sh/bash, my interactive shell has been tcsh > for about three decades now. I know how to unset an env var in tcsh: > just "unsetenv varname". I don't know how to do that sh/bash. Does an > assignment of the empty string to a sh or bash var, followed by an export > of the var unset the environment variable, or does it just set it to the empty string? > And if the latter, how *do* you unset an envvar in sh/bash? Assigning the empty string to a sh/bash variable sets the variable to the empty string. "export VAR" marks the variable to be exported to the environment in child processes. "unset VAR" removes the variable, which also unexports it. You can try playing around with: sh -c 'FOO=; export FOO; unset FOO; FOO=bar; env|grep FOO' > >> Another question: what exactly do light and dark mean in these names? > >> Does "light" mean "light colors for dark backgrounds" or "dark colors > >> for light backgrounds"? Should the names be changed to disambiguate this? > >> lightbg and darkbg, perhaps? > > > > I don't think that's necessary. CSS, mobile devices, and many applications > > all have a "dark mode" or "dark themes", which refer to a light-on-dark > > color scheme. > > https://en.wikipedia.org/wiki/Light-on-dark_color_scheme > > I agree that "dark mode" is clear on this point. I don't think "dark16" is. > That said, I wouldn't object to including "mode" in the name of the scheme. Meh, I still prefer "dark16" as a name. It's not important. Peter From zoltan.somogyi at runbox.com Wed May 8 13:30:04 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 08 May 2024 13:30:04 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in superhomogeneous.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.csh Type: application/octet-stream Size: 406 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.csh Type: application/octet-stream Size: 10633 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Wed May 8 13:36:55 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 08 May 2024 13:36:55 +1000 (AEST) Subject: [m-rev.] for post-commit review: return error_specs up from compile_target_code.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ctc Type: application/octet-stream Size: 412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ctc Type: application/octet-stream Size: 18471 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 9 04:12:31 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 09 May 2024 04:12:31 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in check_typeclass.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cctc Type: application/octet-stream Size: 1062 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cctc Type: application/octet-stream Size: 37448 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 9 04:16:09 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 09 May 2024 04:16:09 +1000 (AEST) Subject: [m-rev.] diff: test for an option error in handle_options.m Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.oe Type: application/octet-stream Size: 546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.oe Type: application/octet-stream Size: 8082 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 9 08:40:54 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 09 May 2024 08:40:54 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in post_typecheck.m Message-ID: For review by anyone. The diff adds a new XXX about a possible improvement, which I would like your opinions on. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cptc Type: application/octet-stream Size: 890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cptc Type: application/octet-stream Size: 26858 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 9 10:35:03 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 09 May 2024 10:35:03 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in state_var.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.csv Type: text/csv Size: 647 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.csv Type: text/csv Size: 17119 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 9 17:02:56 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 09 May 2024 17:02:56 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in make_hlds_warn.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cmhw Type: application/octet-stream Size: 956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cmhw Type: application/octet-stream Size: 30718 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 10 04:02:42 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 10 May 2024 04:02:42 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_foreign_proc.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cafp Type: application/octet-stream Size: 405 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cafp Type: application/octet-stream Size: 9159 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 10 06:41:46 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 10 May 2024 06:41:46 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_pred.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cap Type: application/octet-stream Size: 612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cap Type: application/octet-stream Size: 22114 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 10 07:41:17 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 10 May 2024 07:41:17 +1000 (AEST) Subject: [m-rev.] diff: move add_pred.m back to the make_hlds package Message-ID: This does not need review, but any workspace that pulls this diff will need hlds.add_pred.* cleared out and the dependencies remade. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.apmh Type: application/octet-stream Size: 714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.apmh Type: application/octet-stream Size: 9756 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Fri May 10 13:09:17 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 10 May 2024 13:09:17 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_class.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cac Type: application/octet-stream Size: 393 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cac Type: application/octet-stream Size: 6694 bytes Desc: not available URL: From novalazy at gmail.com Fri May 10 14:45:42 2024 From: novalazy at gmail.com (Peter Wang) Date: Fri, 10 May 2024 14:45:42 +1000 Subject: [m-rev.] for post-commit review: check for terms containing distinct vars in one place In-Reply-To: References: Message-ID: <20240510144542.GD1992@gmail.com> On Sun, 21 Apr 2024 19:44:31 +1000 "Zoltan Somogyi" wrote: > For review by anyone. I am particularly seeking feedback > on the issue noted by a new XXX in the reference manual. > > Zoltan. > diff --git a/doc/reference_manual.texi b/doc/reference_manual.texi > index e436183cf..552f5c0ff 100644 > --- a/doc/reference_manual.texi > +++ b/doc/reference_manual.texi > @@ -7747,7 +7747,7 @@ Type class constraints may include any number of functional dependencies. > A @dfn{functional dependency} constraint > takes the form @code{(@var{Domain} -> @var{Range})}. > The @var{Domain} and @var{Range} arguments are either single type variables, > -or conjunctions of type variables separated by commas. > +or conjunctions of distinct type variables separated by commas. > > @example > :- typeclass @var{Typeclass}(@var{Var}, @dots{})@ > @@ -7828,6 +7828,12 @@ However, variables which are in the range of a functional dependency > need not appear in the signature, > since it is known that their bindings will be determined > from the bindings of the variables in the domain. > + at c XXX What about a class with two fundeps: A -> B, and B -> A. > + at c Both A and B are in the range of a fundep. > + at c The above text seems to imply that it is ok for *neither* to appear > + at c in the signature. > + at c Should we replace "since it is known that their bindings will be determined" > + at c with "provided that their bindings are determined"? > How about: Without any functional dependencies, all variables in constraints must appear in the signature of the predicate or function being declared. However, a variable [that appears] in the range of a functional dependency does not need appear in the signature *if* the variables in the domain of that functional dependency do appear in the signature. Peter From zoltan.somogyi at runbox.com Fri May 10 15:19:11 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 10 May 2024 15:19:11 +1000 (AEST) Subject: [m-rev.] for post-commit review: check for terms containing distinct vars in one place In-Reply-To: <20240510144542.GD1992@gmail.com> Message-ID: On 2024-05-10 14:45 +10:00 AEST, "Peter Wang" wrote: >> @@ -7828,6 +7828,12 @@ However, variables which are in the range of a functional dependency >> need not appear in the signature, >> since it is known that their bindings will be determined >> from the bindings of the variables in the domain. >> + at c XXX What about a class with two fundeps: A -> B, and B -> A. >> + at c Both A and B are in the range of a fundep. >> + at c The above text seems to imply that it is ok for *neither* to appear >> + at c in the signature. >> + at c Should we replace "since it is known that their bindings will be determined" >> + at c with "provided that their bindings are determined"? >> > > How about: > > Without any functional dependencies, all variables in constraints > must appear in the signature of the predicate or function being > declared. > However, a variable [that appears] in the range of a functional > dependency does not need appear in the signature *if* the variables > in the domain of that functional dependency do appear in the > signature. I don't think that is quite right. Given functional dependencies A->B and B->C, it is ok for only A to appear in the signature. C does not have to appear there, even though B is not in the signature either, because B is nevertheless determined by a type var, A, that *is* in the signature. We need to avoid being both too strict (ruling out the chained application of more than one fundep, even though it is allowed, as with the {A->B, B->C} example above) and too loose (allowing circular reasoning of the form "assuming we know A, we can prove we know A", as with the {A->B, B->A} example in the original text). It is difficult to thread the needle between these two issues. I can't think of a way to do that using simple and short text, because I think that what we need to describe is forward chaining: starting with a given set of type vars from the signature, and adding to that set by applying fundeps *whose domain is already in that set*. I thought we can describe things using dags, along the lines of (1) every fundep with N type vars in its domain and M in its range defines N*M directed edges. with each one pointing from a var in the domain to one in the range, and (2) every var that is not in the signature must be reachable from the vars that are in the signature. But I can't come up with a correctness argument for this description, because I have the nagging feeling that treating a fundep such as P,Q->R as two *independent* edges, P->R and Q->R, loses significant information. In reality, fundeps are not really collections of edges, they are *hyperedges*. But if we use that terminology, we lose at least 95% of our audience. Zoltan. From novalazy at gmail.com Fri May 10 17:09:33 2024 From: novalazy at gmail.com (Peter Wang) Date: Fri, 10 May 2024 17:09:33 +1000 Subject: [m-rev.] for post-commit review: check for terms containing distinct vars in one place In-Reply-To: References: Message-ID: <20240510170933.GI1992@gmail.com> On Fri, 10 May 2024 15:19:11 +1000 "Zoltan Somogyi" wrote: > > On 2024-05-10 14:45 +10:00 AEST, "Peter Wang" wrote: > >> @@ -7828,6 +7828,12 @@ However, variables which are in the range of a functional dependency > >> need not appear in the signature, > >> since it is known that their bindings will be determined > >> from the bindings of the variables in the domain. > >> + at c XXX What about a class with two fundeps: A -> B, and B -> A. > >> + at c Both A and B are in the range of a fundep. > >> + at c The above text seems to imply that it is ok for *neither* to appear > >> + at c in the signature. > >> + at c Should we replace "since it is known that their bindings will be determined" > >> + at c with "provided that their bindings are determined"? > >> > > > > How about: > > > > Without any functional dependencies, all variables in constraints > > must appear in the signature of the predicate or function being > > declared. > > However, a variable [that appears] in the range of a functional > > dependency does not need appear in the signature *if* the variables > > in the domain of that functional dependency do appear in the > > signature. > > I don't think that is quite right. Given functional dependencies > A->B and B->C, it is ok for only A to appear in the signature. > C does not have to appear there, even though B is not in the signature either, > because B is nevertheless determined by a type var, A, that *is* in the > signature. You're right. > > We need to avoid being both too strict (ruling out the chained application of > more than one fundep, even though it is allowed, as with the {A->B, B->C} example > above) and too loose (allowing circular reasoning of the form "assuming > we know A, we can prove we know A", as with the {A->B, B->A} example > in the original text). It is difficult to thread the needle between these two issues. > I can't think of a way to do that using simple and short text, because I think > that what we need to describe is forward chaining: starting with a given set of type vars > from the signature, and adding to that set by applying fundeps *whose domain > is already in that set*. I'll give it another go: Without any functional dependencies, all variables in constraints must appear in the signature of the predicate or function being declared. However, a variable that appears in the range of a functional dependency FD does not need to appear in the signature *if* each variable in the domain of FD satisfies one of these conditions: - the variable in the domain of FD appears in the signature; or - the variable in the domain of FD appears in the range of a functional dependency FD2, and the variables in the domain of FD2 in turn satisfy these conditions. > > I thought we can describe things using dags, along the lines of > > (1) every fundep with N type vars in its domain and M in its range defines N*M directed edges. > with each one pointing from a var in the domain to one in the range, and (2) every var that > is not in the signature must be reachable from the vars that are in the signature. > > But I can't come up with a correctness argument for this description, because I have the > nagging feeling that treating a fundep such as P,Q->R as two *independent* edges, > P->R and Q->R, loses significant information. In reality, fundeps are not really > collections of edges, they are *hyperedges*. But if we use that terminology, we lose > at least 95% of our audience. You've lost me :) Peter From zoltan.somogyi at runbox.com Fri May 10 17:24:28 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 10 May 2024 17:24:28 +1000 (AEST) Subject: [m-rev.] for post-commit review: check for terms containing distinct vars in one place In-Reply-To: <20240510170933.GI1992@gmail.com> Message-ID: On 2024-05-10 17:09 +10:00 AEST, "Peter Wang" wrote: > I'll give it another go: > > Without any functional dependencies, all variables in constraints > must appear in the signature of the predicate or function being > declared. > However, a variable that appears in the range of a functional > dependency FD does not need to appear in the signature *if* > each variable in the domain of FD satisfies one of these conditions: > > - the variable in the domain of FD appears in the signature; or > > - the variable in the domain of FD appears in the range of a > functional dependency FD2, and the variables in the domain of FD2 > in turn satisfy these conditions. I think that's definitely better, but still not quite enough, because "satisfy these conditions" is too vague, and can be read incorrectly as well as correctly. The incorrect reading I am thinking of is the "A->B, B->A is ok" viewpoint. I would preface your text with something along the lines of "There must exist an ordering of the fundeps into FD1, FD2 etc such that ...."; and reword the above *somehow* to get across the idea that for the domain of FDn, we can apply the second rule *only* using fundeps FDm where m > n (or m < n, it does not matter which way the numbers go, as long as they go in only one direction). >> I thought we can describe things using dags, along the lines of >> >> (1) every fundep with N type vars in its domain and M in its range defines N*M directed edges. >> with each one pointing from a var in the domain to one in the range, and (2) every var that >> is not in the signature must be reachable from the vars that are in the signature. >> >> But I can't come up with a correctness argument for this description, because I have the >> nagging feeling that treating a fundep such as P,Q->R as two *independent* edges, >> P->R and Q->R, loses significant information. In reality, fundeps are not really >> collections of edges, they are *hyperedges*. But if we use that terminology, we lose >> at least 95% of our audience. > > You've lost me :) That is OK; I knew I would :-) Zoltan. From zoltan.somogyi at runbox.com Sat May 11 02:21:33 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 02:21:33 +1000 (AEST) Subject: [m-rev.] diff: regularize file names in tests/invalid Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.tifn Type: application/octet-stream Size: 401 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.tifn Type: application/octet-stream Size: 78168 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 11 04:22:55 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 04:22:55 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in det_analysis.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cda Type: application/octet-stream Size: 444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cda Type: application/octet-stream Size: 20956 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 11 04:25:40 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 04:25:40 +1000 (AEST) Subject: [m-rev.] for post-commit review: check for terms containing distinct vars in one place In-Reply-To: Message-ID: Note that the text of tests/invalidtypeclass_constraint_extra_var.err_exp may provide a basis for documenting this point. Zoltan. From zoltan.somogyi at runbox.com Sat May 11 06:32:02 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 06:32:02 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in det_analysis.m In-Reply-To: Message-ID: On 2024-05-11 04:22 +10:00 AEST, "Zoltan Somogyi" wrote: > For review by anyone. I forgot to commit that on its own, here it is combined with the next diff, which adds color to add_mode.m. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cdam Type: application/octet-stream Size: 842 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cdam Type: application/octet-stream Size: 41655 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 11 08:51:04 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 08:51:04 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in inst_check.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cic Type: application/octet-stream Size: 663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cic Type: application/octet-stream Size: 35149 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 11 12:23:16 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 12:23:16 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_type.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cat Type: application/octet-stream Size: 961 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cat Type: application/octet-stream Size: 66706 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 11 17:03:41 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 11 May 2024 17:03:41 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in two more modules Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ctimfe Type: application/octet-stream Size: 978 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ctimfe Type: application/octet-stream Size: 60358 bytes Desc: not available URL: From jfischer at opturion.com Sun May 12 02:08:33 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 12 May 2024 02:08:33 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in two more modules In-Reply-To: References: Message-ID: On Sat, 11 May 2024, Zoltan Somogyi wrote: > Use color in adding foreign enums/checking types. > > compiler/add_foreign_enum.m: > compiler/check_type_inst_mode_defns.m: > Add color to the diagnostics generated by these modules. > > In a few cases, improve the wording of the diagnostic. > > tests/invalid/abstract_solver_type.err_exp: > tests/invalid/any_mode.err_exp: > tests/invalid/ee_invalid.err_exp: > tests/invalid/exported_foreign_enum.err_exp: > tests/invalid/foreign_enum_invalid.err_exp: > tests/invalid/foreign_solver_type.err_exp: > tests/invalid/foreign_type_visibility.err_exp: > tests/invalid/pragma_qual_error.err_exp: > tests/invalid/repeated_field_name.err_exp: > tests/invalid/subtype_foreign.err_exp: > tests/invalid/type_with_no_defn.err_exp: > tests/invalid/types2.err_exp: > tests/invalid_nodepend/bad_foreign_type.err_exp: > tests/invalid_nodepend/types.err_exp: > tests/invalid_nodepend/uu_type.err_exp: > tests/invalid_nodepend/where_abstract_enum.err_exp: > tests/warnings/abstract_type_decl.err_exp: > Expect updated diagnostics. That's fine. Julien. From jfischer at opturion.com Sun May 12 02:24:49 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 12 May 2024 02:24:49 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_type.m In-Reply-To: References: Message-ID: <372b3446-cb32-222a-3ce2-73d1e92eb5d8@opturion.com> On Sat, 11 May 2024, Zoltan Somogyi wrote: > Use color in add_type.m. > > compiler/add_type.m: > Add color to the diagnostics generated by this module. > > In a few cases, improve the wording of the diagnostic. ... > diff --git a/compiler/add_type.m b/compiler/add_type.m > index cb7fe3459..55032f31a 100644 > --- a/compiler/add_type.m > +++ b/compiler/add_type.m > @@ -1050,11 +1065,13 @@ add_type_defn_ctor(Ctor, TypeCtor, TypeCtorModuleName, TVarSet, > OtherConsDefn ^ cons_type_ctor = TypeCtor > ) > then > - QualifiedConsIdStr = cons_id_and_arity_to_string(QualifiedConsIdA), > - TypeCtorStr = type_ctor_to_string(TypeCtor), > - Pieces = [words("Error: constructor"), quote(QualifiedConsIdStr), > - words("for type"), quote(TypeCtorStr), > - words("multiply defined."), nl], > + Pieces = [words("Error: the")] ++ > + color_as_subject([words("constructor"), > + unqual_cons_id_and_maybe_arity(QualifiedConsIdA)]) ++ > + color_as_incorrect([words("occurs more than once")]) ++ > + [words("in the definition of type constructor")] ++ I would delete the word "constructor" there. > + color_as_subject([unqual_type_ctor(TypeCtor), suffix(".")]) ++ > + [nl], > Spec = spec($pred, severity_error, phase_pt2h, Context, Pieces), > !:Specs = [Spec | !.Specs] > else The diff looks fine otherwise. Julien. From jfischer at opturion.com Sun May 12 02:44:30 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 12 May 2024 02:44:30 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in inst_check.m In-Reply-To: References: Message-ID: On Sat, 11 May 2024, Zoltan Somogyi wrote: > Use color in inst_check.m. > > compiler/inst_check.m: > Add color to the diagnostics generated by this module. > > compiler/error_spec.m: > Generalize an existing function for the needs of inst_check.m, and > fix an inconsistency between its name and the name of another function. > > compiler/add_foreign_proc.m: > compiler/check_typeclass.m: > compiler/det_analysis.m: > compiler/error_spec.m: > compiler/make_hlds_warn.m: > compiler/post_typecheck.m: > compiler/state_var.m: > Conform to the change in error_spec.m. > > tests/invalid/bad_inst_for_type.err_exp: > tests/invalid/inst_for_eqv_type.err_exp: > tests/warnings/inst_with_no_type.err_exp: > Expect updated diagnostics. That's fine. Julien. From zoltan.somogyi at runbox.com Sun May 12 04:45:23 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 12 May 2024 04:45:23 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_type_defn.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cptd Type: application/octet-stream Size: 1331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cptd Type: application/octet-stream Size: 66142 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 12 10:51:44 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 12 May 2024 10:51:44 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_type_defn.m In-Reply-To: Message-ID: On 2024-05-12 04:45 +10:00 AEST, "Zoltan Somogyi" wrote: > For review by anyone. I again managed to forget to commit that diff on its own, so here it is again, this time together with the next batch of changes. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cptd Type: application/octet-stream Size: 1787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cptd Type: application/octet-stream Size: 89982 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 12 15:17:19 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 12 May 2024 15:17:19 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_pragma.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.capr Type: application/octet-stream Size: 762 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.capr Type: application/octet-stream Size: 41955 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 12 15:41:02 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 12 May 2024 15:41:02 +1000 (AEST) Subject: [m-rev.] diff: pred_or_func_to_*str Message-ID: This does not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.pfs Type: application/octet-stream Size: 1128 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.pfs Type: application/octet-stream Size: 18008 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sun May 12 18:00:39 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sun, 12 May 2024 18:00:39 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in more of simplify_*.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.simp Type: application/octet-stream Size: 1080 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.simp Type: application/octet-stream Size: 43461 bytes Desc: not available URL: From jfischer at opturion.com Sun May 12 23:19:19 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 12 May 2024 23:19:19 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_pragma.m In-Reply-To: References: Message-ID: <396156d2-9f63-f140-57ec-3dc0fd2eba7d@opturion.com> On Sun, 12 May 2024, Zoltan Somogyi wrote: > Use color in add_pragma. and add_mutable_aux_preds.m. > > compiler/add_mutable_aux_preds.m: > compiler/add_pragma.m: > Add color to the diagnostics generated by these modules. > > In a few cases, improve the wording of the diagnostic. ... > tests/invalid/bug83.err_exp: > tests/invalid/external2.err_exp: > tests/invalid/inline_conflict.err_exp: > tests/invalid/inline_conflict_warn.err_exp: > tests/invalid/invalid_export_detism.err_exp: > tests/invalid/test_feature_set.err_exp: > tests/invalid/uniq_mutable.err_exp: > tests/invalid_nodepend/bad_fact_table.err_exp: > tests/invalid_nodepend/bad_fact_table.err_exp2: > tests/invalid_nodepend/bad_mutable.err_exp: > tests/invalid_nodepend/pragma_export.err_exp: > tests/warnings/pragma_term_conflict.err_exp: > Expect updated diagnostics. > > diff --git a/tests/invalid/bug83.err_exp b/tests/invalid/bug83.err_exp > index c66ea1236..701e514cb 100644 > --- a/tests/invalid/bug83.err_exp > +++ b/tests/invalid/bug83.err_exp > @@ -1,7 +1,7 @@ > -bug83.m:027: Error: ambiguous function name in `:- pragma foreign_export' > +bug83.m:027: Error: ambiguous function name in `:- pragma foreign_export' I suggest using color_subject on ":- pragma foreign_export". > bug83.m:027: declaration. > bug83.m:027: The possible matches are: > -bug83.m:027: function `io.make_io_error'/1, > -bug83.m:027: function `bug83.make_io_error'/1. > +bug83.m:027: function `io.make_io_error'/1, > +bug83.m:027: function `bug83.make_io_error'/1. > bug83.m:027: An explicit module qualifier may be necessary to select the > bug83.m:027: right match. ... > diff --git a/tests/invalid/inline_conflict.err_exp b/tests/invalid/inline_conflict.err_exp > index 5af1c2517..200bc0d7c 100644 > --- a/tests/invalid/inline_conflict.err_exp > +++ b/tests/invalid/inline_conflict.err_exp > @@ -1,2 +1,2 @@ > -inline_conflict.m:019: Error: `:- pragma no_inline' declaration conflicts with > -inline_conflict.m:019: previous inline pragma for `bar'/2. > +inline_conflict.m:019: Error: `:- pragma no_inline' declaration conflicts with > +inline_conflict.m:019: previous inline pragma for `bar'/2. Unrelated: it might be nice to give the context for the previous inline pragma in the message as well. The rest looks fine. Julien. From jfischer at opturion.com Mon May 13 00:14:19 2024 From: jfischer at opturion.com (Julien Fischer) Date: Mon, 13 May 2024 00:14:19 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in more of simplify_*.m In-Reply-To: References: Message-ID: On Sun, 12 May 2024, Zoltan Somogyi wrote: > Use color in more of simplify_*.m. > > compiler/simplify_goal.m: > compiler/simplify_goal_call.m: > compiler/simplify_goal_disj.m: > compiler/simplify_goal_ite.m: > compiler/simplify_proc.m: > Add color to the diagnostics generated by some of these modules, > and modify the existing color in other modules to use color_subject. > > In a few cases, improve the wording of the diagnostic. That looks fine. Julien. From zoltan.somogyi at runbox.com Mon May 13 04:01:14 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 May 2024 04:01:14 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in more modules Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.mc Type: application/octet-stream Size: 1056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.mc Type: application/octet-stream Size: 50596 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 13 04:16:16 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 May 2024 04:16:16 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in add_pragma.m In-Reply-To: <396156d2-9f63-f140-57ec-3dc0fd2eba7d@opturion.com> Message-ID: On 2024-05-12 23:19 +10:00 AEST, "Julien Fischer" wrote: >> --- a/tests/invalid/bug83.err_exp >> +++ b/tests/invalid/bug83.err_exp >> @@ -1,7 +1,7 @@ >> -bug83.m:027: Error: ambiguous function name in `:- pragma foreign_export' >> +bug83.m:027: Error: ambiguous function name in `:- pragma foreign_export' > > I suggest using color_subject on ":- pragma foreign_export". In this case, the phrase "in pragma foreign_export" plays the same role as the "In this argument of this syntactic construct:" preamble that we have on many other kinds of error messages. I think it would be an inconsistency if we colored one but not the other. I could reword that message to move that context up front, so that it would read: In pragma foreign_export declaration: ambiguous function name, ..." Would that be better? >> --- a/tests/invalid/inline_conflict.err_exp >> +++ b/tests/invalid/inline_conflict.err_exp >> @@ -1,2 +1,2 @@ >> -inline_conflict.m:019: Error: `:- pragma no_inline' declaration conflicts with >> -inline_conflict.m:019: previous inline pragma for `bar'/2. >> +inline_conflict.m:019: Error: `:- pragma no_inline' declaration conflicts with >> +inline_conflict.m:019: previous inline pragma for `bar'/2. > > Unrelated: it might be nice to give the context for the previous inline pragma > in the message as well. Yes, it would be nice. However, the predicate that generates that message, add_pred_marker in add_pragma.m, does not have that context, because the HLDS has no slot for that information. We could add it, but this error is so rare, and the context of the conflicting pragma is so trivially easy to find for a human, that noone has never thought it worthwhile to make that change. > The rest looks fine. Thank you very much, for this and for all the other reviews. Zoltan. From zoltan.somogyi at runbox.com Mon May 13 07:15:55 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 May 2024 07:15:55 +1000 (AEST) Subject: [m-rev.] for post-commit review: use more color in check_typeclass.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ctc Type: application/octet-stream Size: 967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ctc Type: application/octet-stream Size: 37130 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 13 11:13:59 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 May 2024 11:13:59 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_class.m Message-ID: For review by anyone. As shown the attached diff, many test cases in tests/invalid* test for empty interfaces, making warnings/empty_interface.m redundant. Would anyone object if I removed it? Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpcmi Type: application/octet-stream Size: 1335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpcmi Type: application/octet-stream Size: 44755 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 13 12:02:21 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 13 May 2024 12:02:21 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_mutable.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpm Type: application/octet-stream Size: 379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpm Type: application/octet-stream Size: 19620 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 14 09:27:48 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 14 May 2024 09:27:48 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in parse_inst_mode_name.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpimn Type: application/octet-stream Size: 803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpimn Type: application/octet-stream Size: 31922 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 14 14:53:19 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 14 May 2024 14:53:19 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_inst_mode_defn.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpimd Type: application/octet-stream Size: 2079 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpimd Type: application/octet-stream Size: 78851 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 14 17:51:18 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 14 May 2024 17:51:18 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_item.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpi Type: application/octet-stream Size: 628 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpi Type: application/octet-stream Size: 37875 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 14 19:49:15 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 14 May 2024 19:49:15 +1000 (AEST) Subject: [m-rev.] diff: use color in parse_vars.m Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpv Type: application/octet-stream Size: 185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpv Type: application/octet-stream Size: 6449 bytes Desc: not available URL: From jfischer at opturion.com Wed May 15 00:29:38 2024 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 15 May 2024 00:29:38 +1000 (AEST) Subject: [m-rev.] for post-commit review: color in parse_inst_mode_name.m In-Reply-To: References: Message-ID: <3bae8ce8-de31-9cc-29d8-7f442f2a8e16@opturion.com> On Tue, 14 May 2024, Zoltan Somogyi wrote: > Use color in parse_inst_mode_name.m. > > compiler/parse_inst_mode_name.m: > Add color to the diagnostics generated by this module. > > In a few cases, improve the wording of the diagnostic, and/or make > the wording of different but related diagnostics more consistent. > > Implement parse_higher_order_mode by *calling* parse_higher_order_inst > and post-processing its results, instead of duplicating pretty much > all of its code. > > tests/invalid_nodepend/bad_with_inst.err_exp: > tests/invalid_nodepend/combined_ho_type_inst_1.err_exp: > tests/invalid_nodepend/impl_def_literal_syntax.err_exp: > tests/invalid_nodepend/inst_list_dup.err_exp: > tests/invalid_nodepend/kind.err_exp: > tests/invalid_nodepend/predmode.err_exp: > tests/invalid_nodepend/test_with_type.err_exp: > Expect updated diagnostics. That's fine. Julien. From jfischer at opturion.com Wed May 15 00:46:09 2024 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 15 May 2024 00:46:09 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_inst_mode_defn.m In-Reply-To: References: Message-ID: <11f1767f-73bb-bb22-47a3-07840da118@opturion.com> On Tue, 14 May 2024, Zoltan Somogyi wrote: > Use color in parse_inst_mode_defn.m and other modules. ... > diff --git a/tests/invalid_nodepend/bad_foreign_export_enum.err_exp b/tests/invalid_nodepend/bad_foreign_export_enum.err_exp > index 3eae66549..1113211c1 100644 > --- a/tests/invalid_nodepend/bad_foreign_export_enum.err_exp > +++ b/tests/invalid_nodepend/bad_foreign_export_enum.err_exp > @@ -25,8 +25,8 @@ bad_foreign_export_enum.m:030: In the third argument of > bad_foreign_export_enum.m:030: `:- pragma foreign_export_enum' declaration: > bad_foreign_export_enum.m:030: error: expected a list of attributes, got > bad_foreign_export_enum.m:030: `1234'. > -bad_foreign_export_enum.m:031: Error: expected a list of mapping elements, got > -bad_foreign_export_enum.m:031: `5678'. > +bad_foreign_export_enum.m:031: Error: expected a list of mapping elements, got > +bad_foreign_export_enum.m:031: `5678'. That's not a great error message, why do we not provide the same context we do for the others, e.g. In fourth argument of `:- pragma foreign_export_enum' declaration: error: expect a list of mapping elements, got `5678' ? The diff looks fine. Julien. From zoltan.somogyi at runbox.com Wed May 15 08:36:08 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 15 May 2024 08:36:08 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_goal.m Message-ID: For review by anyone. There were few test cases affected by this change compared to the number of error-spec-construction-sites updated by it, so it seems like most of those sites don't have tests for their output. So keep an eye out for any unwanted changes appearing "in the wild", so to speak. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpg Type: application/octet-stream Size: 356 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpg Type: application/octet-stream Size: 72504 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Wed May 15 08:39:46 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 15 May 2024 08:39:46 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_inst_mode_defn.m In-Reply-To: <11f1767f-73bb-bb22-47a3-07840da118@opturion.com> Message-ID: On 2024-05-15 00:46 +10:00 AEST, "Julien Fischer" wrote: >> diff --git a/tests/invalid_nodepend/bad_foreign_export_enum.err_exp b/tests/invalid_nodepend/bad_foreign_export_enum.err_exp >> index 3eae66549..1113211c1 100644 >> --- a/tests/invalid_nodepend/bad_foreign_export_enum.err_exp >> +++ b/tests/invalid_nodepend/bad_foreign_export_enum.err_exp >> @@ -25,8 +25,8 @@ bad_foreign_export_enum.m:030: In the third argument of >> bad_foreign_export_enum.m:030: `:- pragma foreign_export_enum' declaration: >> bad_foreign_export_enum.m:030: error: expected a list of attributes, got >> bad_foreign_export_enum.m:030: `1234'. >> -bad_foreign_export_enum.m:031: Error: expected a list of mapping elements, got >> -bad_foreign_export_enum.m:031: `5678'. >> +bad_foreign_export_enum.m:031: Error: expected a list of mapping elements, got >> +bad_foreign_export_enum.m:031: `5678'. > > That's not a great error message, why do we not provide the same context we > do for the others, e.g. > > In fourth argument of > `:- pragma foreign_export_enum' declaration: > error: expect a list of mapping elements, got `5678' > ? That message is generated by parse_pragma_foreign.m, which I have not colorized yet. I will fix it when I get there. > The diff looks fine. Thank you. Zoltan. From zoltan.somogyi at runbox.com Wed May 15 09:21:18 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 15 May 2024 09:21:18 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_goal.m In-Reply-To: Message-ID: On 2024-05-15 08:36 +10:00 AEST, "Zoltan Somogyi" wrote: > There were few test cases affected by this change compared > to the number of error-spec-construction-sites updated by it, > so it seems like most of those sites don't have tests for their output. > So keep an eye out for any unwanted changes appearing > "in the wild", so to speak. The attached diff for adding color to parse_dcg_goal.m affects NO test cases, which is a bit disturbing. (Only a bit, because most of the error messages are for situations that require really stupid code to trigger.) Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpdg Type: application/octet-stream Size: 178 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpdg Type: application/octet-stream Size: 5850 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Wed May 15 14:41:02 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 15 May 2024 14:41:02 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_pragma_foreign.m Message-ID: For review by Julien, since it fixes the issue he brought up last night. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cppf Type: application/octet-stream Size: 1123 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cppf Type: application/octet-stream Size: 99314 bytes Desc: not available URL: From jfischer at opturion.com Wed May 15 16:41:01 2024 From: jfischer at opturion.com (Julien Fischer) Date: Wed, 15 May 2024 16:41:01 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_pragma_foreign.m In-Reply-To: References: Message-ID: <3c6bdb87-a99e-d9f3-5565-c3788cdca6@opturion.com> On Wed, 15 May 2024, Zoltan Somogyi wrote: > Use color in parse_pragma_foreign.m. > > compiler/parse_pragma_foreign.m: > Add color to the diagnostics generated by this module. > > In a few cases, improve the wording of the diagnostic. In several cases, > change the diagnostic's wording to follow our standard patterns. > > In a few cases, simplify the logic of the main code. > > compiler/parse_util.m: > Add a ContextPieces argument to an auxiliary predicate, > parse_list_elements. > > compiler/parse_pragma.m: > compiler/parse_pragma_analysis.m: > compiler/parse_pragma_tabling.m: > Conform to the changes in parse_util.m. > > tests/invalid_make_int/bad_foreign_type_int.int_err_exp: > tests/invalid_nodepend/bad_foreign_code.err_exp: > tests/invalid_nodepend/bad_foreign_decl.err_exp: > tests/invalid_nodepend/bad_foreign_enum.err_exp: > tests/invalid_nodepend/bad_foreign_export.err_exp: > tests/invalid_nodepend/bad_foreign_export_enum.err_exp: > tests/invalid_nodepend/bad_foreign_import_module.err_exp: > tests/invalid_nodepend/bad_foreign_proc.err_exp: > tests/invalid_nodepend/bug363.err_exp: > tests/invalid_nodepend/foreign_enum_import.err_exp: > Expect updated diagnostics. That looks fine. Julien. From zoltan.somogyi at runbox.com Wed May 15 19:51:18 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Wed, 15 May 2024 19:51:18 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_pragma_tabling.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cppt Type: application/octet-stream Size: 340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cppt Type: application/octet-stream Size: 21340 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 16 05:56:48 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 16 May 2024 05:56:48 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_pragma.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cpp Type: application/octet-stream Size: 411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cpp Type: application/octet-stream Size: 59940 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 16 09:26:34 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 16 May 2024 09:26:34 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in parse_type_name.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cptn Type: application/octet-stream Size: 620 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cptn Type: application/octet-stream Size: 38230 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 16 11:56:34 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 16 May 2024 11:56:34 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in split_parse_tree_src.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cspts Type: application/octet-stream Size: 444 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cspts Type: application/octet-stream Size: 20963 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 16 14:38:53 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 16 May 2024 14:38:53 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in equiv_type.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cet Type: application/octet-stream Size: 721 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cet Type: application/octet-stream Size: 24802 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Thu May 16 17:09:34 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 16 May 2024 17:09:34 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in equiv_type.m In-Reply-To: Message-ID: On 2024-05-16 14:38 +10:00 AEST, "Zoltan Somogyi" wrote: > For review by anyone. And again I forgot to commit that diff on its own, so here it is together with the next batch of changes. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cetx Type: application/octet-stream Size: 92569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cetx Type: application/octet-stream Size: 2535 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Sat May 18 19:28:13 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Sat, 18 May 2024 19:28:13 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in make_hlds_error.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cmhe Type: application/octet-stream Size: 2016 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cmhe Type: application/octet-stream Size: 66660 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 20 18:30:34 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 20 May 2024 18:30:34 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color in typecheck_errors_undef.m and others Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cteu Type: application/octet-stream Size: 9140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cteu Type: application/octet-stream Size: 413496 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 20 20:58:58 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 20 May 2024 20:58:58 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color more sparingly, part 1 Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cx1 Type: application/octet-stream Size: 693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cx1 Type: application/octet-stream Size: 36555 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Mon May 20 21:48:41 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Mon, 20 May 2024 21:48:41 +1000 (AEST) Subject: [m-rev.] diff: carve format_call_errors.m out of format_call.m Message-ID: This should not need review. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.fce Type: application/octet-stream Size: 486 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.fce Type: application/octet-stream Size: 14239 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 21 01:33:46 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 21 May 2024 01:33:46 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color when explaining format problems Message-ID: For review by anyone. This diff adds some XXXs documenting some problems with the existing wording. If anyone has any proposals for fixes, I am all ears. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cfc Type: application/octet-stream Size: 815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cfc Type: application/octet-stream Size: 47389 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 21 18:46:04 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 21 May 2024 18:46:04 +1000 (AEST) Subject: [m-rev.] for post-commit review: understate colors in mode_errors.m Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.ucme Type: application/octet-stream Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.ucme Type: application/octet-stream Size: 136727 bytes Desc: not available URL: From zoltan.somogyi at runbox.com Tue May 21 23:40:20 2024 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 21 May 2024 23:40:20 +1000 (AEST) Subject: [m-rev.] for post-commit review: use color more sparingly, part 2 Message-ID: For review by anyone. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.cx2 Type: application/octet-stream Size: 1361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.cx2 Type: application/octet-stream Size: 75296 bytes Desc: not available URL: