From zoltan.somogyi at runbox.com Tue Sep 1 08:13:05 2026 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 01 Sep 2026 00:13:05 +0200 (CEST) Subject: [m-dev.] two issues I need your input on about input specialization Message-ID: I would like your opinions on the two issues discussed in the attached file. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: IS Type: application/octet-stream Size: 7191 bytes Desc: not available URL: From jfischer at opturion.com Tue Sep 1 15:37:30 2026 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 1 Sep 2026 15:37:30 +1000 Subject: [m-dev.] two issues I need your input on about input specialization In-Reply-To: References: Message-ID: On Tue, 1 Sept 2026 at 08:13, Zoltan Somogyi wrote: > I have applied the input_mode_spec pragma to the two modules in the > compiler that inspired it, ml_elim_nested.m and quantification.m. > This raised two main issues. The first concerns how that pragma > should apply to module interfaces, while the second is specific > to the code now in quantification.m. > > ---------------------------------------------------------- > > Issue 1 ... > The only ways I see around this problem are these. > > Way 1a: Have predicates such implicitly_quantify_goal_general replace > each call to e.g. implicitly_quantify_goal_2 with a switch on > NonLocalsToRecompute, in which the code of each arm contains > the same call to implicitly_quantify_goal_2, but from a program point > at which the value of NonLocalsToRecompute has been tested by the switch. > This is, to put it politely, inelegant. (This lack of elegance could > possibly be cured by a new scope around the call that basically > asks the compiler to create that switch automatically, but I think > that would be a massive overkill.) > > Way 1b: Allow input_mode_spec pragmas to specify replace_in_mode > even in the interface. I don't like this, because it makes the > actual mode declarations of the input specialized exported predicates > into lies. > > Way 1c: Ask programmers to manually apply input specialization > to exported predicate declarations, as the old ml_elim_nested.m > has done for a *long* time. However, if we take this path, then > there is no point in actually allowing input_mode_spec pragmas > in module interfaces, and in fact it would be better if that > asking was done, beside the manual, by the error message we generate > for any input_mode_spec pragma in the interface. (This would also > probably mean that input_mode_spec pragmas should be reclassified > as impl pragmas, instead of the current decl pragma, but this is > easily done.) > > Of those three alternatives, I would prefer Way 1c. It does > require more work from the programmer writing the module, but > it makes the module interface easier to understand for every programmer > *reading* the module. My preference is 1b. So long as the pragma is positioned near the predicate declaration, I don't think readability is too badly affected. > ---------------------------------------------------------- > > Issue 2 > > As shown above, nonlocals_to_recompute has three values: > > :- type nonlocals_to_recompute > ---> ord_nl_maybe_lambda % ordinary nonlocals computation > ; ord_nl_no_lambda % ordinary nonlocals computation > ; cg_nl_no_lambda. % code gen nonlocals computation > > When I applied way 1c above to quantification.m, I found that while > there are plenty of callers of quantification.m's exported predicates > that specify the first two values of nonlocals_to_recompute, there are > absolutely NONE that specify the third. > > I tried to find out when the last call to quantification.m that passed > cg_nl_no_lambda (or code_gen_nonlocals, the original name of that > function symbol) was deleted, but I found that there NEVER WAS such a call. > Simon added code_gen_nonlocals to quantification.m on 10 Feb 2000, > in a commit that also added a fake code_gen_nonlocals field to > hlds_goal_infos. It is fake because its getter and setter access > the ordinary nonlocals instead: > > % The code-gen non-locals are always the same as the > % non-locals when structure reuse is not being performed. > goal_info_get_code_gen_nonlocals(GoalInfo) = > goal_info_get_nonlocals(GoalInfo). > % The code-gen non-locals are always the same as the > % non-locals when structure reuse is not being performed. > goal_info_set_code_gen_nonlocals(NonLocals, !GoalInfo) :- > goal_info_set_nonlocals(NonLocals, !GoalInfo). > > I have no idea whether Simon intended to work on adding calls to actually > compute the codegen nonlocals, or whether he intended to hand over that > work to someone else, or what. (Simon's commits later that Feb all involved > Aditi.) The emails about that commit are not in the m-rev archive, > since that started in Oct 2000. Before that we used the m-dev list. In addition to the Aditi stuff, Simon also posted a change to constraint propagation that month (although that doesn't appear to have been committed until late 2001.) > I also don't know whether the people who later worked on structure > sharing/reuse knew about the codegen nonlocals being fake. Peter, did you? > > The difference between ordinary and codegen nonlocals is definitely > relevant to any work on structure reuse; no such system will work > without it. This means that Simon's work on computing codegen nonlocals > is potentially useful, though its usefulness is somewhat limited > by the fact that this code couldn't have ever been tested, > at least on the main trunk. (I don't know of any CVS branches > for this work, but there may have been some.) > > The issue I am raising is this: this code may be useful in the future, > but for now, it is a dead weight, complicating maintenance, and slowing > compilation. I can see three ways forward. > > Way 2a: keep the code handling cg_nl_no_lambda as is, by adding > a mode to at least one exported predicate that has in(cg_nl_no_lambda) > as the mode of the nonlocals_to_recompute argument. > > Way 2b: keep the code handling cg_nl_no_lambda, but comment it out, > and comment the cg_nl_no_lambda alternative out of the nonlocals_to_recompute > type. Do NOT specify in(cg_nl_no_lambda) as the mode of the > nonlocals_to_recompute argument for ANY exported predicate. > Note that commenting out the parts of predicates that handle cg_nl_no_lambda > in many cases leaves some of the inputs of the predicates involved unused. > > Way 2c: go beyond 2b by deleting those now-unused inputs, and where relevant, > propagate these deletions upward. > > I would be ok with any of 2a/b/c, though I have a slight preference for 2c. 2c. No-one has needed it in the latest 26 years and it's not that hard to restore if it ever is needed. Julien. From novalazy at gmail.com Tue Sep 1 16:39:22 2026 From: novalazy at gmail.com (Peter Wang) Date: Tue, 1 Sep 2026 16:39:22 +1000 Subject: [m-dev.] two issues I need your input on about input specialization In-Reply-To: References: Message-ID: <20260901163922.GR878836197300100@gmail.com> On Tue, 01 Sep 2026 00:13:05 +0200 "Zoltan Somogyi" wrote: > I have no idea whether Simon intended to work on adding calls to actually > compute the codegen nonlocals, or whether he intended to hand over that > work to someone else, or what. (Simon's commits later that Feb all involved > Aditi.) The emails about that commit are not in the m-rev archive, > since that started in Oct 2000. I also don't know whether the people > who later worked on structure sharing/reuse knew about the codegen > nonlocals being fake. Peter, did you? I don't remember anything about the reuse work. > The difference between ordinary and codegen nonlocals is definitely > relevant to any work on structure reuse; no such system will work > without it. This means that Simon's work on computing codegen nonlocals > is potentially useful, though its usefulness is somewhat limited > by the fact that this code couldn't have ever been tested, > at least on the main trunk. (I don't know of any CVS branches > for this work, but there may have been some.) Yes, I seem to recall the original reuse work was done on a branch, so what we see on the main branch is probably just a stub. Does anyone happen to have a copy of the old CVS repository? I thought I had a copy as it would have been used for the git migration, but it's not on my current machines. > > I would be ok with any of 2a/b/c, though I have a slight preference for 2c. I agree with Julien. Peter From jfischer at opturion.com Tue Sep 1 17:16:12 2026 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 1 Sep 2026 17:16:12 +1000 Subject: [m-dev.] two issues I need your input on about input specialization In-Reply-To: <20260901163922.GR878836197300100@gmail.com> References: <20260901163922.GR878836197300100@gmail.com> Message-ID: On Tue, 1 Sept 2026 at 16:39, Peter Wang wrote: > > On Tue, 01 Sep 2026 00:13:05 +0200 "Zoltan Somogyi" wrote: > > I have no idea whether Simon intended to work on adding calls to actually > > compute the codegen nonlocals, or whether he intended to hand over that > > work to someone else, or what. (Simon's commits later that Feb all involved > > Aditi.) The emails about that commit are not in the m-rev archive, > > since that started in Oct 2000. I also don't know whether the people > > who later worked on structure sharing/reuse knew about the codegen > > nonlocals being fake. Peter, did you? > > I don't remember anything about the reuse work. > > > The difference between ordinary and codegen nonlocals is definitely > > relevant to any work on structure reuse; no such system will work > > without it. This means that Simon's work on computing codegen nonlocals > > is potentially useful, though its usefulness is somewhat limited > > by the fact that this code couldn't have ever been tested, > > at least on the main trunk. (I don't know of any CVS branches > > for this work, but there may have been some.) > > Yes, I seem to recall the original reuse work was done on a branch, > so what we see on the main branch is probably just a stub. If by original work you mean Nancy's work, then that was definitely done on a branch of the CVS repository. Julien.