From novalazy at gmail.com Fri Apr 16 15:12:14 2021 From: novalazy at gmail.com (Peter Wang) Date: Fri, 16 Apr 2021 15:12:14 +1000 Subject: [m-dev.] subtypes proposal In-Reply-To: <20210114125539.GG1514@kola.localdomain> References: <20210114125539.GG1514@kola.localdomain> Message-ID: <20210416151214.GB1458@kola.localdomain> On Thu, 14 Jan 2021 12:55:39 +1100 Peter Wang wrote: > Hi, > > In this proposal, subtypes are distinct d.u. types that share a data > representation with a base type, which is a normal d.u. type. > Subtypes of subtypes are allowed. > Every term of a given subtype must also be valid term in the supertype > (recursively, up to the base type), with the same data representation. > > A subtype can be introduced like this: > > :- type SUBTYPE =< SUPERTYPE > ---> BODY. Subtypes are supported as of ROTD 2021-04-14. Peter From jfischer at opturion.com Fri Apr 16 15:13:51 2021 From: jfischer at opturion.com (Julien Fischer) Date: Fri, 16 Apr 2021 15:13:51 +1000 (AEST) Subject: [m-dev.] subtypes proposal In-Reply-To: <20210416151214.GB1458@kola.localdomain> References: <20210114125539.GG1514@kola.localdomain> <20210416151214.GB1458@kola.localdomain> Message-ID: <6ee66afe-268-1e59-84b4-1e75fb2346@opturion.com> On Fri, 16 Apr 2021, Peter Wang wrote: > On Thu, 14 Jan 2021 12:55:39 +1100 Peter Wang wrote: >> Hi, >> >> In this proposal, subtypes are distinct d.u. types that share a data >> representation with a base type, which is a normal d.u. type. >> Subtypes of subtypes are allowed. >> Every term of a given subtype must also be valid term in the supertype >> (recursively, up to the base type), with the same data representation. >> >> A subtype can be introduced like this: >> >> :- type SUBTYPE =< SUPERTYPE >> ---> BODY. > > Subtypes are supported as of ROTD 2021-04-14. You may want to add an annoucment for them on the webpage. Julien. From novalazy at gmail.com Tue Apr 20 15:14:25 2021 From: novalazy at gmail.com (Peter Wang) Date: Tue, 20 Apr 2021 15:14:25 +1000 Subject: [m-dev.] allowing duplicate field names in module Message-ID: <20210420151425.GG1441@kola.localdomain> Hi, What are the reasons that field names are required to be unique within a module, and not just within a type? AFAIK, it's because if the user wanted to supply type/mode declarations for multiple fields with the same name, the generated functions would conflict. That doesn't seem like a strong reason to me; the compiler can just report the conflict. The reason I'm bringing this up is that it seems annoying to have to invent new field names when declaring subtypes, though obviously it's not limited to subtypes. Peter From zoltan.somogyi at runbox.com Tue Apr 20 16:01:24 2021 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Tue, 20 Apr 2021 16:01:24 +1000 (AEST) Subject: [m-dev.] allowing duplicate field names in module In-Reply-To: <20210420151425.GG1441@kola.localdomain> Message-ID: 2021-04-20 15:14 GMT+10:00 "Peter Wang" : > What are the reasons that field names are required to be unique within a > module, and not just within a type? > > AFAIK, it's because if the user wanted to supply type/mode declarations > for multiple fields with the same name, the generated functions would > conflict. That doesn't seem like a strong reason to me; the compiler > can just report the conflict. > > The reason I'm bringing this up is that it seems annoying to have to > invent new field names when declaring subtypes, though obviously > it's not limited to subtypes. I agree with your concern in your third paragraph; I am also against this limitation. Before we started work on Mercury, I was mostly a C programmer, and so I was familiar with the game of picking a unique prefix for the names of the fields of each struct, and wanted to avoid that for Mercury. The reason Mercury nevertheless still requires this is not the reason surmised in your second paragraph. I remember a conversation I had with Fergus over this exact issue. I remember it because it was one of the few times that it seemed that I couldn't even make Fergus understand my point, much less accept its validity. He was writing the typechecker at the time, one of whose jobs is of course disambiguation. The names of predicates and types are module qualified, and in his design approach to the typechecker, the function symbols inside types were module qualified as well (hence the prohibition on two function symbols in the same module having the same name/arity pair). I tried to convince him that function symbols should be *type* qualified, i.e. they should be qualified by the identity of the type whose definition they belong to, and the module qualification should be on the *type's* name, not on the function symbols, specifically to avoid this limitation, but I don't he understood me. (In retrospect, he was probably quite tired at the time.) Or, maybe he did understand, and just didn't want to do the extra work required to handle function symbols differently from predicates and types. (Evaluable functions did not exist yet.) I couldn't overrule him, because this happened at a time when nearly all the programming work on the Mercury compiler was done by Fergus and Tom, because I had far too heavy a teaching load to make major contributions in that area. This design approach is why the cons_table in the module_info has full hlds_cons_defns as values. If it were up to me, the cons_table would be nothing more than map from function symbol names to the list of type_ctors whose definitions include a function symbol with that name. Over the years, I made small steps in that direction, but the fundamental design of the typechecker means that any attempt to make function symbols type qualified requires *lots* of work. Zoltan. From zoltan.somogyi at runbox.com Thu Apr 29 12:38:21 2021 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 29 Apr 2021 12:38:21 +1000 (AEST) Subject: [m-dev.] pragmas should specify pred/func as well as name and arity Message-ID: Most pragmas tell the compiler something about a predicate or function. We have two pieces of syntax that pragmas use to specify *which* predicate or function. The first syntax we implemented was simple name/arity. The other, implemented later, is either pred(argmode1, ..., argmodeN), or func(argmode1, ..., argmodeN) = retmode. The latter of course was intended to be more precise, because it was intended to specify one *procedure* of a predicate or function. But it is also more precise in another way: it actually specifies whether it applies to a predicate or function, which the first syntax does not. This leaves open the door to a potential problem where the programmer intends a pragma to apply to e.g. pred foo/2, but the compiler also applies it to func foo/2. This has not been a significant problem in the past, for two reasons. First, the first pragmas we implemented (apart from things like foreign_procs, which look like pragmas syntactically but which we now handle as the totally separate kind of thing they are) were things like pragma inline, for which it did not matter all that much whether it applied to both a pred and a func, or to just the one the programmer meant. The second reason, unique to us, is that we tended to frown on having both a pred foo/2 *and* a foo/1, so the issue was rarely relevant, though we *do* have some instances of defining e.g. both pred foo/2 and pred foo/3, and then *function versions of both*, i.e. func foo/1 and func foo/2. However, for pragmas that assert something, such as promise_pure, applying them to both a predicate and a function when the programmer intended applying them to only one is a more significant problem. I believe we should update the pragmas that use the first syntax to first allow, and eventually require, the programmer to say whether they mean pred foo/2 or func foo/2. I can see three broad approaches to how this could be done. Approach 1 would be to wrap the name/arity pair in either pred() or func(). This would look good, but unfortunately the second syntax also uses terms whose top function symbol is either pred or func, and there are some pragmas that allow the subject that they apply to to be specified using either the first or the second syntax (see attached table), so this would probably serve as a source of confusion. And the compiler's error messages, having to describe two possible ways to fix any syntax errors (one to reach each kind of valid syntax), couldn't help as much as we would like them to. Approach 2 would be to add a "_pred" or "_func" suffix to the pragma name, such as ":- pragma inline_func(foo/2).". We have already used this approach when replacing ":- external(foo/2)." with ":- external_{pred,func}(foo/2).". However, there are some pragmas, such as "terminates", for which neither that suffix, nor a similar prefix, would look all that natural. Approach 3 would be to add an extra argument, containing simply either "pred" or "func", to the pragma's argument list, just before the argument that now contains just foo/2. There are also blended approaches: we could require a suffix such as "_proc" for pragmas that specify the argument modes, a form of approach 2, and then require a pred() or func() wrapper for the form of the pragma that does not specify modes, i.e. approach 1. The point of separating out the _proc form is to mitigate the error message problem described above. As the attached table shows, only a few kinds of pragmas allow the subject of the pragma to be *either* a single procedure or all procedures in the named function or predicate. For example, we could replace the type_spec pragma with three others: type_spec_pred and type_spec_func when you want type specialization for all modes, and type_spec_proc when you want it for just one. There is also what we might call "approach 0": simply obsolete the pragmas, such as promise_pure, whose effect can be accomplished by wrappers around goals. Does anyone have any other approaches to fixing this problem? And what are your preferences? It would be simplest if we chose the same approach for all pragmas, but we could adopt different approaches for different pragmas. We would need to introduce any such changes gradually. We would implement any new syntax alongside the old, generating messages telling programmers to switch to the new form when we find the old. These messages could have severity warning, but with an option to shut them up, such as --no-warn-for-old-pragma-syntax. That would need to persist past the next stable release, after which we could first up the severity to error, and then later still disable the code parsing the old syntax altogether. Opinions? BTW, in case anyone wanders what brought up this problem: the code in recompilation.check.m that I have worked on the last day or two needs to know what entities a pragma applies to if it is to make correct decisions about when a recompilation is needed. Zoltan. From zoltan.somogyi at runbox.com Thu Apr 29 12:40:27 2021 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 29 Apr 2021 12:40:27 +1000 (AEST) Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 12:38:21 +1000 (AEST), "Zoltan Somogyi" wrote: > As the attached table shows It should now be actually attached. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: PRAGMA_PRED_OR_FUNC Type: application/octet-stream Size: 1518 bytes Desc: not available URL: From novalazy at gmail.com Thu Apr 29 14:33:34 2021 From: novalazy at gmail.com (Peter Wang) Date: Thu, 29 Apr 2021 14:33:34 +1000 Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: References: Message-ID: <20210429143334.GU1422@kola.localdomain> On Thu, 29 Apr 2021 12:38:21 +1000 "Zoltan Somogyi" wrote: > Most pragmas tell the compiler something about a predicate > or function. We have two pieces of syntax that pragmas use to specify > *which* predicate or function. The first syntax we implemented was simple name/arity. > The other, implemented later, is either pred(argmode1, ..., argmodeN), > or func(argmode1, ..., argmodeN) = retmode. > The latter of course was intended to be more precise, because it was > intended to specify one *procedure* of a predicate or function. But it is > also more precise in another way: it actually specifies whether it applies > to a predicate or function, which the first syntax does not. > > This leaves open the door to a potential problem where the programmer > intends a pragma to apply to e.g. pred foo/2, but the compiler also > applies it to func foo/2. > > This has not been a significant problem in the past, for two reasons. > First, the first pragmas we implemented (apart from things like foreign_procs, > which look like pragmas syntactically but which we now handle as the > totally separate kind of thing they are) were things like pragma inline, > for which it did not matter all that much whether it applied to both > a pred and a func, or to just the one the programmer meant. > The second reason, unique to us, is that we tended to frown on > having both a pred foo/2 *and* a foo/1, so the issue was rarely relevant, > though we *do* have some instances of defining e.g. both pred foo/2 > and pred foo/3, and then *function versions of both*, i.e. func foo/1 > and func foo/2. > > However, for pragmas that assert something, such as promise_pure, > applying them to both a predicate and a function when the programmer > intended applying them to only one is a more significant problem. > I believe we should update the pragmas that use the first syntax > to first allow, and eventually require, the programmer to say whether > they mean pred foo/2 or func foo/2. Can we require something more specific than name/arity if there is actual ambiguity? I already dislike having to specify the arity when there is only one such thing by that name. > I can see three broad approaches to how this could be done. > > Approach 1 would be to wrap the name/arity pair in either pred() or func(). > This would look good, but unfortunately the second syntax also uses terms > whose top function symbol is either pred or func, and there are some pragmas > that allow the subject that they apply to to be specified using either the first > or the second syntax (see attached table), so this would probably serve > as a source of confusion. And the compiler's error messages, having to > describe two possible ways to fix any syntax errors (one to reach each kind > of valid syntax), couldn't help as much as we would like them to. This seems ideal to me. I don't really understand the problem with error messages. If the compiler cannot parse the term, I think the compiler can just say something like: The argument must have one of these forms: NAME/ARITY pred(NAME/ARITY) func(NAME/ARITY) NAME(MODES) and the user should get the idea. > > Approach 2 would be to add a "_pred" or "_func" suffix to the pragma name, > such as ":- pragma inline_func(foo/2).". We have already used this approach > when replacing ":- external(foo/2)." with ":- external_{pred,func}(foo/2).". > However, there are some pragmas, such as "terminates", for which neither > that suffix, nor a similar prefix, would look all that natural. I don't especially like it. > Approach 3 would be to add an extra argument, containing simply either > "pred" or "func", to the pragma's argument list, just before the argument > that now contains just foo/2. If the argument was optional then I could ignore it :) > > There is also what we might call "approach 0": simply obsolete the pragmas, > such as promise_pure, whose effect can be accomplished by wrappers > around goals. pragma promise_pure is not redundant because this is correct: :- pred foo(io::di, io::uo) is det. :- pragma promise_pure(foo/2). foo(!IO) :- impure do_foo. but this is wrong: foo(!IO) :- promise_pure ( impure do_foo ). I supposed you could ensure that !IO appears inside the impure goal. Peter From jfischer at opturion.com Thu Apr 29 14:45:06 2021 From: jfischer at opturion.com (Julien Fischer) Date: Thu, 29 Apr 2021 14:45:06 +1000 (AEST) Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: References: Message-ID: <9dc12665-2d86-882a-b189-762daf6fb2a1@opturion.com> Hi Zoltan, On Thu, 29 Apr 2021, Zoltan Somogyi wrote: > I can see three broad approaches to how this could be done. > > Approach 1 would be to wrap the name/arity pair in either pred() or func(). > This would look good, but unfortunately the second syntax also uses terms > whose top function symbol is either pred or func, and there are some pragmas > that allow the subject that they apply to to be specified using either the first > or the second syntax (see attached table), so this would probably serve > as a source of confusion. And the compiler's error messages, having to > describe two possible ways to fix any syntax errors (one to reach each kind > of valid syntax), couldn't help as much as we would like them to. I think that a very strong argument in favour of approach 1 is this: it is the syntax we already use in other parts of the language, specifically out-of-line method definitions in type class instances are written as: :- instance foo(...) where [ pred(methodname/arity) is predname func(methodname/arity) is funcname ]. If possible, I think we should avoid having multiple ways of identifying predicates / functions in the language. > Approach 2 would be to add a "_pred" or "_func" suffix to the pragma name, > such as ":- pragma inline_func(foo/2).". We have already used this approach > when replacing ":- external(foo/2)." with ":- external_{pred,func}(foo/2).". > However, there are some pragmas, such as "terminates", for which neither > that suffix, nor a similar prefix, would look all that natural. Having a prefix "pred_" or "func_" might work with terminates, but it's still a bit ugly. > Approach 3 would be to add an extra argument, containing simply either > "pred" or "func", to the pragma's argument list, just before the argument > that now contains just foo/2. That's actually what several of the generated pragmas (e.g. exceptions, trailing_info) do now. (Except that they output "predicate" or "function" rather than "pred" or "func".) > There are also blended approaches: we could require a suffix such as "_proc" > for pragmas that specify the argument modes, a form of approach 2, > and then require a pred() or func() wrapper for the form of the > pragma that does not specify modes, i.e. approach 1. The point of > separating out the _proc form is to mitigate the error message problem > described above. As the attached table shows, only a few kinds of pragmas > allow the subject of the pragma to be *either* a single procedure > or all procedures in the named function or predicate. > For example, we could replace the type_spec pragma with three > others: type_spec_pred and type_spec_func when you want > type specialization for all modes, and type_spec_proc when you want it > for just one. > > There is also what we might call "approach 0": simply obsolete the pragmas, > such as promise_pure, whose effect can be accomplished by wrappers > around goals. > > Does anyone have any other approaches to fixing this problem? > And what are your preferences? > > It would be simplest if we chose the same approach for all pragmas, > but we could adopt different approaches for different pragmas. Ideally the pragmas intended for users should converge (eventually) on the same approach. (The generated ones should do whatever allows them to be most efficiently and unambiguously processed.) > We would need to introduce any such changes gradually. We would > implement any new syntax alongside the old, generating messages > telling programmers to switch to the new form when we find the old. > These messages could have severity warning, but with an option to > shut them up, such as --no-warn-for-old-pragma-syntax. That would > need to persist past the next stable release, after which we could > first up the severity to error, and then later still disable the code > parsing the old syntax altogether. It will need to be done very gradually, over several releases. Julien. From zoltan.somogyi at runbox.com Thu Apr 29 14:54:30 2021 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 29 Apr 2021 14:54:30 +1000 (AEST) Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: <20210429143334.GU1422@kola.localdomain> References: <20210429143334.GU1422@kola.localdomain> Message-ID: On Thu, 29 Apr 2021 14:33:34 +1000, Peter Wang wrote: > > However, for pragmas that assert something, such as promise_pure, > > applying them to both a predicate and a function when the programmer > > intended applying them to only one is a more significant problem. > > I believe we should update the pragmas that use the first syntax > > to first allow, and eventually require, the programmer to say whether > > they mean pred foo/2 or func foo/2. > > Can we require something more specific than name/arity if there is > actual ambiguity? I presume you mean "ONLY when there is an ambiguity". My answer would be "no". Just because there is no ambiguity now does not mean there won't be later. If e.g. a pragma says foo/2, and the only foo/2 is currently a predicate, then the meaning of the pragma should not change to apply to func foo/2 as well, when it is added later. Having a pragma written now apply to code written in the future would be ... surprising. > I already dislike having to specify the arity when > there is only one such thing by that name. You may think there is only one predicate baz, but (a) you may be wrong, and (b) even if you are right right now, you may become wrong later. Code written by Fergus and Tom had lots of predicate names that existed with more than one arity, until I systematically eliminated most such ambiguities, leaving mostly just the intentional ones, such as set.init. (To help with that process, I even added a command to mdb to find those ambiguities.) > > I can see three broad approaches to how this could be done. > > > > Approach 1 would be to wrap the name/arity pair in either pred() or func(). > > This would look good, but unfortunately the second syntax also uses terms > > whose top function symbol is either pred or func, and there are some pragmas > > that allow the subject that they apply to to be specified using either the first > > or the second syntax (see attached table), so this would probably serve > > as a source of confusion. And the compiler's error messages, having to > > describe two possible ways to fix any syntax errors (one to reach each kind > > of valid syntax), couldn't help as much as we would like them to. > > This seems ideal to me. I don't really understand the problem with error > messages. If the compiler cannot parse the term, I think the compiler > can just say something like: > > The argument must have one of these forms: > > NAME/ARITY > pred(NAME/ARITY) > func(NAME/ARITY) > NAME(MODES) > > and the user should get the idea. Actually, there is one more, NAME(MODES) = MODE, for functions, and the first one is one I would prefer not to advertise. (Existing pragmas, but definition, should not get any error messages.) But yes, your approach should solve the error message problem. > > Approach 2 would be to add a "_pred" or "_func" suffix to the pragma name, > > such as ":- pragma inline_func(foo/2).". We have already used this approach > > when replacing ":- external(foo/2)." with ":- external_{pred,func}(foo/2).". > > However, there are some pragmas, such as "terminates", for which neither > > that suffix, nor a similar prefix, would look all that natural. > > I don't especially like it. I don't especially like any of the approaches, but I want *something* that resolves the fundamental pred vs func ambiguity. > > Approach 3 would be to add an extra argument, containing simply either > > "pred" or "func", to the pragma's argument list, just before the argument > > that now contains just foo/2. > > If the argument was optional then I could ignore it :) It eventually wouldn't be, so ignoring it would work only in the short term :-( > pragma promise_pure is not redundant because this is correct: > > :- pred foo(io::di, io::uo) is det. > :- pragma promise_pure(foo/2). > > foo(!IO) :- > impure do_foo. > > but this is wrong: > > foo(!IO) :- > promise_pure ( > impure do_foo > ). You are right. Zoltan. From zoltan.somogyi at runbox.com Thu Apr 29 15:14:01 2021 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 29 Apr 2021 15:14:01 +1000 (AEST) Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: <9dc12665-2d86-882a-b189-762daf6fb2a1@opturion.com> References: <9dc12665-2d86-882a-b189-762daf6fb2a1@opturion.com> Message-ID: On Thu, 29 Apr 2021 14:45:06 +1000 (AEST), Julien Fischer wrote: > I think that a very strong argument in favour of approach 1 is this: it > is the syntax we already use in other parts of the language, Agreed. I think Peter's response may indicate he does too, but I am not sure. Peter? > > Approach 3 would be to add an extra argument, containing simply either > > "pred" or "func", to the pragma's argument list, just before the argument > > that now contains just foo/2. > > That's actually what several of the generated pragmas (e.g. exceptions, > trailing_info) do now. (Except that they output "predicate" or > "function" rather than "pred" or "func".) Yes, and the reason is this: > (The generated ones should do whatever allows > them to be most efficiently and unambiguously processed.) Having one argument for each field in the relevant pragma info struct is the simplest and most efficient way to process them. But that is not the primary consideration for the design of the syntax for pragmas that users are expected to write. > > We would need to introduce any such changes gradually. We would > > implement any new syntax alongside the old, generating messages > > telling programmers to switch to the new form when we find the old. > > These messages could have severity warning, but with an option to > > shut them up, such as --no-warn-for-old-pragma-syntax. That would > > need to persist past the next stable release, after which we could > > first up the severity to error, and then later still disable the code > > parsing the old syntax altogether. > > It will need to be done very gradually, over several releases. Agreed. To help us not forget such things, should we add a new file, named maybe RELEASE_NOTES_NEXT, containing NEWS entries for changes to be done *after* the next release? Zoltan. From novalazy at gmail.com Thu Apr 29 15:16:28 2021 From: novalazy at gmail.com (Peter Wang) Date: Thu, 29 Apr 2021 15:16:28 +1000 Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: References: <20210429143334.GU1422@kola.localdomain> Message-ID: <20210429151628.GY1422@kola.localdomain> On Thu, 29 Apr 2021 14:54:30 +1000 "Zoltan Somogyi" wrote: > > > On Thu, 29 Apr 2021 14:33:34 +1000, Peter Wang wrote: > > > However, for pragmas that assert something, such as promise_pure, > > > applying them to both a predicate and a function when the programmer > > > intended applying them to only one is a more significant problem. > > > I believe we should update the pragmas that use the first syntax > > > to first allow, and eventually require, the programmer to say whether > > > they mean pred foo/2 or func foo/2. > > > > Can we require something more specific than name/arity if there is > > actual ambiguity? > > I presume you mean "ONLY when there is an ambiguity". Yes. > > My answer would be "no". Just because there is no ambiguity now > does not mean there won't be later. If e.g. a pragma says foo/2, > and the only foo/2 is currently a predicate, then the meaning of the > pragma should not change to apply to func foo/2 as well, when > it is added later. Having a pragma written now apply to code > written in the future would be ... surprising. The compiler would warn about the ambiguity though. We already have the behaviour that names that were not ambiguous initially may become ambiguous with additional imports, or changes to imported modules. Peter From zoltan.somogyi at runbox.com Thu Apr 29 15:25:12 2021 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Thu, 29 Apr 2021 15:25:12 +1000 (AEST) Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: <20210429151628.GY1422@kola.localdomain> References: <20210429143334.GU1422@kola.localdomain> <20210429151628.GY1422@kola.localdomain> Message-ID: On Thu, 29 Apr 2021 15:16:28 +1000, Peter Wang wrote: > > My answer would be "no". Just because there is no ambiguity now > > does not mean there won't be later. If e.g. a pragma says foo/2, > > and the only foo/2 is currently a predicate, then the meaning of the > > pragma should not change to apply to func foo/2 as well, when > > it is added later. Having a pragma written now apply to code > > written in the future would be ... surprising. > > The compiler would warn about the ambiguity though. No, it does not. It simply applies the pragma to every pred_info with the given name/arity. See do_add_pred_marker in add_pragma.m. > We already have the behaviour that names that were not ambiguous > initially may become ambiguous with additional imports, or changes > to imported modules. That is different. Pragmas always apply to the entities defined in the current module, so their meaning cannot be affected either by changing the set of imported modules, or the contents of imported modules. Zoltan. From novalazy at gmail.com Thu Apr 29 15:54:58 2021 From: novalazy at gmail.com (Peter Wang) Date: Thu, 29 Apr 2021 15:54:58 +1000 Subject: [m-dev.] pragmas should specify pred/func as well as name and arity In-Reply-To: References: <20210429143334.GU1422@kola.localdomain> <20210429151628.GY1422@kola.localdomain> Message-ID: <20210429155458.GA1422@kola.localdomain> On Thu, 29 Apr 2021 15:25:12 +1000 "Zoltan Somogyi" wrote: > > > On Thu, 29 Apr 2021 15:16:28 +1000, Peter Wang wrote: > > > My answer would be "no". Just because there is no ambiguity now > > > does not mean there won't be later. If e.g. a pragma says foo/2, > > > and the only foo/2 is currently a predicate, then the meaning of the > > > pragma should not change to apply to func foo/2 as well, when > > > it is added later. Having a pragma written now apply to code > > > written in the future would be ... surprising. > > > > The compiler would warn about the ambiguity though. > > No, it does not. It simply applies the pragma to every pred_info > with the given name/arity. See do_add_pred_marker in add_pragma.m. I mean that under my proposal, we would change the compiler to report ambiguities when and *if* they arise. > > > We already have the behaviour that names that were not ambiguous > > initially may become ambiguous with additional imports, or changes > > to imported modules. > > That is different. Pragmas always apply to the entities defined > in the current module, so their meaning cannot be affected either > by changing the set of imported modules, or the contents of imported > modules. Ok. I'm just saying if I had written: :- pragma inline(foo/2). foo(X, Y) :- ... which previously compiled fine, then later I added foo(X, Y) = Z :- ... and the compiler started telling me I needed to disambiguate the pragma inline, it would not be surprising at all. Peter