From post at volker-wysk.de Wed May 1 04:34:01 2024 From: post at volker-wysk.de (Volker Wysk) Date: Tue, 30 Apr 2024 20:34:01 +0200 Subject: [m-users.] Change in compiler behaviour for 22.01.8 ? Pointer type strictness increased? In-Reply-To: References: Message-ID: <0033d36478c95e7cba965c4f5161dca6a5ab1ac1.camel@volker-wysk.de> Am Samstag, dem 27.04.2024 um 10:25 -0700 schrieb M McDonough: > > I just want to note this, as it's caused me issues in the past. It's a > bad idea to have anything other than a variable or integral expression > (no function calls, no macros, etc) as the argument to MR_list_cons > (and I would generally say any of the MR_* macros unless you've read > them carefully). You can end up with issues where things are executed > in an unexpected order, and in particular on the low-level C grades, > this can cause big issues with Mercury registers being clobbered > leading to very hard to debug issues with seemingly impossible > behavior. Hmmm... I've read your thread from July 2023 about this problem. I'm wondering if it could be remedied by wrapping it in an inline C function, like this: static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail) { MR_Word result = MR_list_cons(head, tail); return result; } This would ensure that the expressions head, tail and the body of MR_list_cons are evaluated in the expected order. Cheers, Volker From w.karpiel at o2.pl Sun May 12 15:55:25 2024 From: w.karpiel at o2.pl (Wojciech Karpiel) Date: Sun, 12 May 2024 07:55:25 +0200 Subject: [m-users.] Mercury for the web Message-ID: <53508676-fdf3-4906-a645-e10dc7052ce6@o2.pl> Hi! Have you managed to run Mercury client-side on the web (e.g. compiled to Javascript/WebAssembly)? If yes, then how? I saw an attempt here [1] tough i don't know if there was any followup to that e-mail thread. [1] https://lists.mercurylang.org/archives/reviews/2020-March/021184.html Regards Wojciech Karpiel From jfischer at opturion.com Sun May 12 23:01:58 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 12 May 2024 23:01:58 +1000 (AEST) Subject: [m-users.] Mercury for the web In-Reply-To: <53508676-fdf3-4906-a645-e10dc7052ce6@o2.pl> References: <53508676-fdf3-4906-a645-e10dc7052ce6@o2.pl> Message-ID: On Sun, 12 May 2024, Wojciech Karpiel wrote: > Have you managed to run Mercury client-side on the web (e.g. compiled to > Javascript/WebAssembly)? If yes, then how? > I saw an attempt here [1] tough i don't know if there was any followup to > that e-mail thread. > > [1] https://lists.mercurylang.org/archives/reviews/2020-March/021184.html I'm not aware of anything since 2020. Julien. From post at volker-wysk.de Fri May 24 22:31:06 2024 From: post at volker-wysk.de (Volker Wysk) Date: Fri, 24 May 2024 14:31:06 +0200 Subject: [m-users.] Mercury macro trouble Message-ID: <2835999d8695685fe5bebef6aad2310ae049b3b8.camel@volker-wysk.de> Hi! Some quotes from this list: M. McDonough on 2023-07-19:  "After some debugging, I now suspect that I know the answer, and it's that MR_list_cons isn't safe to call directly outside of a foreign_proc because it can interact with the Mercury register usage." Peter Wang on 2023-07-20: "The problem is that the argument of MR_list_cons(), the call to CreateNode(), is not evaluated before MR_list_cons() starts doing anything. You should make the call CreateNode() first, assign the result to a variable, then perform the MR_list_cons()." M. McDonough on 2024-04-27: "I just want to note this, as it's caused me issues in the past. It's a bad idea to have anything other than a variable or integral expression (no function calls, no macros, etc) as the argument to MR_list_cons (and I would generally say any of the MR_* macros unless you've read them carefully). You can end up with issues where things are executed in an unexpected order, and in particular on the low-level C grades, this can cause big issues with Mercury registers being clobbered leading to very hard to debug issues with seemingly impossible behavior." I think, this is bad and should be addressed. The obvious solution would be to use inline C functions with the same names as the macros, instead. Gcc's statement expressions aren't needed. So I'm asking the Mercury team to scrap all those macros and use inline functions instead. :-) No, seriously, I can understand that the Mercury team is reluctant to touch those long-proven macros. This leads to the second best solution: Wrap those macros in inline functions. And instruct the user to use them instead of the macros. For instance, like this: static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail) { MR_Word result = MR_list_cons(head, tail); return result; } This should amend the problem. Or am I missing something? It seems odd to me that this obvious solution hasn't been implemented already. Cheers, Volker From jfischer at opturion.com Sun May 26 15:01:06 2024 From: jfischer at opturion.com (Julien Fischer) Date: Sun, 26 May 2024 15:01:06 +1000 Subject: [m-users.] Mercury macro trouble In-Reply-To: <2835999d8695685fe5bebef6aad2310ae049b3b8.camel@volker-wysk.de> References: <2835999d8695685fe5bebef6aad2310ae049b3b8.camel@volker-wysk.de> Message-ID: Hi, On Fri, 24 May 2024 at 22:31, Volker Wysk wrote: > Some quotes from this list: > > M. McDonough on 2023-07-19: > "After some debugging, I now suspect that I know the answer, and it's that > MR_list_cons isn't safe to call directly outside of a foreign_proc because > it can interact with the Mercury register usage." > > Peter Wang on 2023-07-20: > "The problem is that the argument of MR_list_cons(), the call to > CreateNode(), is not evaluated before MR_list_cons() starts doing > anything. You should make the call CreateNode() first, assign the > result to a variable, then perform the MR_list_cons()." > > M. McDonough on 2024-04-27: > "I just want to note this, as it's caused me issues in the past. It's a > bad idea to have anything other than a variable or integral expression > (no function calls, no macros, etc) as the argument to MR_list_cons > (and I would generally say any of the MR_* macros unless you've read > them carefully). You can end up with issues where things are executed > in an unexpected order, and in particular on the low-level C grades, > this can cause big issues with Mercury registers being clobbered > leading to very hard to debug issues with seemingly impossible > behavior." > > I think, this is bad and should be addressed. > > The obvious solution would be to use inline C functions with the same names > as the macros, instead. Gcc's statement expressions aren't needed. > > So I'm asking the Mercury team to scrap all those macros and use inline > functions instead. :-) The intended use of those macros was for the implementation of the Mercury system itself. They aren't inline C function because in that role it's probably not useful for them to be inline C functions. (To say nothing of the fact that when those macros were originally written, C did not have a standard notion of an inline function.) The secondary role of these macros as a mechanism by which users can manipulate lists in foreign code has arisen, more or less, by accident. > No, seriously, I can understand that the Mercury team is reluctant to touch > those long-proven macros. Whether those macros are appropriate for users is another question. As C macros, they (obviously) have all the inherent issues with C macro argument evaluation (as in the above examples), but that's not really a Mercury problem. > This leads to the second best solution: Wrap those macros in inline > functions. And instruct the user to use them instead of the macros. For > instance, like this: > > static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail) > { > MR_Word result = MR_list_cons(head, tail); > return result; > } > > This should amend the problem. Or am I missing something? It seems odd to me > that this obvious solution hasn't been implemented already. My suggestion would be that the list module in the standard library provide function versions of these operations (as indeed it does for the C# and Java backends). Users should be directed to those, instead of the runtime macros ... ... or users should just foreign export pragmas the operations they need to manipulate lists in foreign code. As indeed you would need to do if you wanted to manipulate just about any other data structure in the Mercury standard library from foreign code. This approach also automatically handles whether arguments need to be boxed etc. Julien. From post at volker-wysk.de Mon May 27 03:39:12 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 26 May 2024 19:39:12 +0200 Subject: [m-users.] Mercury macro trouble In-Reply-To: References: <2835999d8695685fe5bebef6aad2310ae049b3b8.camel@volker-wysk.de> Message-ID: Am Sonntag, dem 26.05.2024 um 15:01 +1000 schrieb Julien Fischer: > Hi, > > On Fri, 24 May 2024 at 22:31, Volker Wysk wrote: > > > Some quotes from this list: > > > > M. McDonough on 2023-07-19: > > "After some debugging, I now suspect that I know the answer, and it's that > > MR_list_cons isn't safe to call directly outside of a foreign_proc because > > it can interact with the Mercury register usage." > > > > Peter Wang on 2023-07-20: > > "The problem is that the argument of MR_list_cons(), the call to > > CreateNode(), is not evaluated before MR_list_cons() starts doing > > anything. You should make the call CreateNode() first, assign the > > result to a variable, then perform the MR_list_cons()." > > > > M. McDonough on 2024-04-27: > > "I just want to note this, as it's caused me issues in the past. It's a > > bad idea to have anything other than a variable or integral expression > > (no function calls, no macros, etc) as the argument to MR_list_cons > > (and I would generally say any of the MR_* macros unless you've read > > them carefully). You can end up with issues where things are executed > > in an unexpected order, and in particular on the low-level C grades, > > this can cause big issues with Mercury registers being clobbered > > leading to very hard to debug issues with seemingly impossible > > behavior." > > > > I think, this is bad and should be addressed. > > > > The obvious solution would be to use inline C functions with the same names > > as the macros, instead. Gcc's statement expressions aren't needed. > > > > So I'm asking the Mercury team to scrap all those macros and use inline > > functions instead. :-) > > The intended use of those macros was for the implementation of the Mercury > system itself. They aren't inline C function because in that role > it's probably not > useful for them to be inline C functions. (To say nothing of the fact > that when those > macros were originally written, C did not have a standard notion of an inline > function.) Okay > The secondary role of these macros as a mechanism by which users can > manipulate lists in foreign code has arisen, more or less, by accident. But it's documented in the "C data passing conventions" section. So it's no accident when users want to use them... > > No, seriously, I can understand that the Mercury team is reluctant to touch > > those long-proven macros. > > Whether those macros are appropriate for users is another question. > As C macros, they (obviously) have all the inherent issues with C macro > argument evaluation (as in the above examples), but that's not really a Mercury > problem. Again, it's documented. As M. McDonough has written, it's easy to run into those issues, when you aren't that knowledgeable about them... > > This leads to the second best solution: Wrap those macros in inline > > functions. And instruct the user to use them instead of the macros. For > > instance, like this: > > > > static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail) > > { > > MR_Word result = MR_list_cons(head, tail); > > return result; > > } > > > > This should amend the problem. Or am I missing something? It seems odd to me > > that this obvious solution hasn't been implemented already. > > My suggestion would be that the list module in the standard library > provide function > versions of these operations (as indeed it does for the C# and Java backends). > Users should be directed to those, instead of the runtime macros ... Yes, that's what I have in mind. Although it applies only to those five list processing macros. > ... or users should just foreign export pragmas the operations they > need to manipulate > lists in foreign code. As indeed you would need to do if you wanted > to manipulate just > about any other data structure in the Mercury standard library from > foreign code. This > approach also automatically handles whether arguments need to be boxed etc. Since you say so, I assume this is efficient. Having those list macros, or function equivalences of them, sure is handy. Lists are one of the most used data structures... Cheers, Volker From jfischer at opturion.com Tue May 28 08:57:13 2024 From: jfischer at opturion.com (Julien Fischer) Date: Tue, 28 May 2024 08:57:13 +1000 Subject: [m-users.] Mercury macro trouble In-Reply-To: References: <2835999d8695685fe5bebef6aad2310ae049b3b8.camel@volker-wysk.de> Message-ID: On Mon, 27 May 2024 at 03:39, Volker Wysk wrote: > > Am Sonntag, dem 26.05.2024 um 15:01 +1000 schrieb Julien Fischer: > > > The obvious solution would be to use inline C functions with the same names > > > as the macros, instead. Gcc's statement expressions aren't needed. > > > > > > So I'm asking the Mercury team to scrap all those macros and use inline > > > functions instead. :-) > > > > The intended use of those macros was for the implementation of the Mercury > > system itself. They aren't inline C function because in that role > > it's probably not > > useful for them to be inline C functions. (To say nothing of the fact > > that when those > > macros were originally written, C did not have a standard notion of an inline > > function.) > > Okay > > > The secondary role of these macros as a mechanism by which users can > > manipulate lists in foreign code has arisen, more or less, by accident. > > But it's documented in the "C data passing conventions" section. So it's no > accident when users want to use them... I didn't say it was an accident that users want to use them, it was the fact that they *are* the documented mechanism that I was referring to as an accident. > > > This leads to the second best solution: Wrap those macros in inline > > > functions. And instruct the user to use them instead of the macros. For > > > instance, like this: > > > > > > static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail) > > > { > > > MR_Word result = MR_list_cons(head, tail); > > > return result; > > > } > > > > > > This should amend the problem. Or am I missing something? It seems odd to me > > > that this obvious solution hasn't been implemented already. > > > > My suggestion would be that the list module in the standard library > > provide function > > versions of these operations (as indeed it does for the C# and Java backends). > > Users should be directed to those, instead of the runtime macros ... > > Yes, that's what I have in mind. Although it applies only to those five list > processing macros. Yes, they are all that the C# and Java backends provide. We are limited in which list processing operations can be supported in this way by how polymorphism is handled. (Essentially, you can only do it like this for operations where the type_info is not required.) > > ... or users should just foreign export pragmas the operations they > > need to manipulate > > lists in foreign code. As indeed you would need to do if you wanted > > to manipulate just > > about any other data structure in the Mercury standard library from > > foreign code. This > > approach also automatically handles whether arguments need to be boxed etc. > > Since you say so, I assume this is efficient. The macros are faster than exported Mercury procedures, but that is not the same as saying the latter are not efficient. I think for most non-contrived use cases the differences between them won't matter. > Having those list macros, or function equivalences of them, sure is handy. There are trade-offs: Foreign exporting the operations means you can ignore a lot of implementation details like boxing of certain argument types, what the MR_hp register is doing etc. OTOH, the advantage of the list operations provided is that while they are polymorphic, you don't need to deal with that. (Pragma foreign_export'ing polymorphic predicates is possible, but it's generally easier not to deal with all that.) Julien. From post at volker-wysk.de Tue May 28 22:16:20 2024 From: post at volker-wysk.de (Volker Wysk) Date: Tue, 28 May 2024 14:16:20 +0200 Subject: [m-users.] Mercury macro trouble In-Reply-To: References: <2835999d8695685fe5bebef6aad2310ae049b3b8.camel@volker-wysk.de> Message-ID: <5db27b06c4510ea1cc6b3d82a9246263fbd253fa.camel@volker-wysk.de> Am Dienstag, dem 28.05.2024 um 08:57 +1000 schrieb Julien Fischer: > On Mon, 27 May 2024 at 03:39, Volker Wysk wrote: > > > > Am Sonntag, dem 26.05.2024 um 15:01 +1000 schrieb Julien Fischer: > > > > > The obvious solution would be to use inline C functions with the same names > > > > as the macros, instead. Gcc's statement expressions aren't needed. > > > > > > > > So I'm asking the Mercury team to scrap all those macros and use inline > > > > functions instead. :-) > > > > > > The intended use of those macros was for the implementation of the Mercury > > > system itself. They aren't inline C function because in that role > > > it's probably not > > > useful for them to be inline C functions. (To say nothing of the fact > > > that when those > > > macros were originally written, C did not have a standard notion of an inline > > > function.) > > > > Okay > > > > > The secondary role of these macros as a mechanism by which users can > > > manipulate lists in foreign code has arisen, more or less, by accident. > > > > But it's documented in the "C data passing conventions" section. So it's no > > accident when users want to use them... > > I didn't say it was an accident that users want to use them, it was > the fact that > they *are* the documented mechanism that I was referring to as an accident. That was just a little rhetoric for my part. > > > > This leads to the second best solution: Wrap those macros in inline > > > > functions. And instruct the user to use them instead of the macros. For > > > > instance, like this: > > > > > > > > static inline MR_Word mr_list_cons(MR_Word head, MR_Word tail) > > > > { > > > > MR_Word result = MR_list_cons(head, tail); > > > > return result; > > > > } > > > > > > > > This should amend the problem. Or am I missing something? It seems odd to me > > > > that this obvious solution hasn't been implemented already. > > > > > > My suggestion would be that the list module in the standard library > > > provide function > > > versions of these operations (as indeed it does for the C# and Java backends). > > > Users should be directed to those, instead of the runtime macros ... > > > > Yes, that's what I have in mind. Although it applies only to those five list > > processing macros. > > Yes, they are all that the C# and Java backends provide. We are limited in > which list processing operations can be supported in this way by how > polymorphism > is handled. (Essentially, you can only do it like this for operations > where the type_info > is not required.) I'm agreeing to your suggestion of providing (inline) function versions of those five macros. This would avoid the painful experiences which M. McDonough had. > > > ... or users should just foreign export pragmas the operations they > > > need to manipulate > > > lists in foreign code. As indeed you would need to do if you wanted > > > to manipulate just > > > about any other data structure in the Mercury standard library from > > > foreign code. This > > > approach also automatically handles whether arguments need to be boxed etc. > > > > Since you say so, I assume this is efficient. > > The macros are faster than exported Mercury procedures, but that is not the same > as saying the latter are not efficient. I think for most > non-contrived use cases the > differences between them won't matter. Okay > > Having those list macros, or function equivalences of them, sure is handy. > > There are trade-offs: > > Foreign exporting the operations means you can ignore a lot of > implementation details like > boxing of certain argument types, what the MR_hp register is doing etc. Hmm. Sounds more involved than I was aware. Good thing that the details can be ignored when using foreign exports. > OTOH, the advantage of the list operations provided is that while they > are polymorphic, > you don't need to deal with that. (Pragma foreign_export'ing > polymorphic predicates is possible, > but it's generally easier not to deal with all that.) Same here. Cheers, Volker