From zoltan.somogyi at runbox.com Fri Oct 4 13:46:50 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 04 Oct 2019 13:46:50 +1000 (AEST) Subject: [m-dev.] foreign enum module qualification Message-ID: Foreign enum pragmas specify a mapping from the names of an enum type's constants to their foreign names. At the moment, we allow programmers to module qualify the names of the constants, but there is not much point in that, since the only valid module name that the qualification may yield is the name of the current module. I would guess that the only reason for allow module qualification on the constant names is to reuse code that handles foreign_export_enums, in which module qualification *does* make sense. Would anyone object if we required the constant names in foreign_enum pragmas to be unqualified? It would remove a potential source of user errors. And even though in *theory* this is a breaking change, in practice, it isn't really, since people tend not to write such obviously redundant qualifications. Zoltan. From jfischer at opturion.com Fri Oct 4 13:58:06 2019 From: jfischer at opturion.com (Julien Fischer) Date: Fri, 4 Oct 2019 13:58:06 +1000 (AEST) Subject: [m-dev.] foreign enum module qualification In-Reply-To: References: Message-ID: On Fri, 4 Oct 2019, Zoltan Somogyi wrote: > Foreign enum pragmas specify a mapping from the names > of an enum type's constants to their foreign names. At the moment, > we allow programmers to module qualify the names of the constants, > but there is not much point in that, since the only valid module name > that the qualification may yield is the name of the current module. > > I would guess that the only reason for allow module qualification > on the constant names is to reuse code that handles foreign_export_enums, > in which module qualification *does* make sense. > > Would anyone object if we required the constant names in foreign_enum > pragmas to be unqualified? It would remove a potential source > of user errors. And even though in *theory* this is a breaking > change, in practice, it isn't really, since people tend not to write > such obviously redundant qualifications. No objection from me. Julien. From novalazy at gmail.com Fri Oct 4 15:02:52 2019 From: novalazy at gmail.com (Peter Wang) Date: Fri, 4 Oct 2019 15:02:52 +1000 Subject: [m-dev.] foreign enum module qualification In-Reply-To: References: Message-ID: <20191004150252.GC1266@kola.localdomain> On Fri, 4 Oct 2019 13:58:06 +1000 (AEST), Julien Fischer wrote: > > On Fri, 4 Oct 2019, Zoltan Somogyi wrote: > > > Foreign enum pragmas specify a mapping from the names > > of an enum type's constants to their foreign names. At the moment, > > we allow programmers to module qualify the names of the constants, > > but there is not much point in that, since the only valid module name > > that the qualification may yield is the name of the current module. > > > > I would guess that the only reason for allow module qualification > > on the constant names is to reuse code that handles foreign_export_enums, > > in which module qualification *does* make sense. > > > > Would anyone object if we required the constant names in foreign_enum > > pragmas to be unqualified? It would remove a potential source > > of user errors. And even though in *theory* this is a breaking > > change, in practice, it isn't really, since people tend not to write > > such obviously redundant qualifications. > > No objection from me. Nor from me. Peter From zoltan.somogyi at runbox.com Fri Oct 4 16:33:03 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 04 Oct 2019 16:33:03 +1000 (AEST) Subject: [m-dev.] foreign enum module qualification In-Reply-To: <20191004150252.GC1266@kola.localdomain> References: <20191004150252.GC1266@kola.localdomain> Message-ID: On Fri, 4 Oct 2019 15:02:52 +1000, Peter Wang wrote: > > No objection from me. > > Nor from me. Ok, the attached diff does the first step of this change. For post-commit review by either of you. Zoltan. -------------- next part -------------- A non-text attachment was scrubbed... Name: Log.fe Type: application/octet-stream Size: 1135 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DIFF.fe Type: application/octet-stream Size: 7511 bytes Desc: not available URL: From jfischer at opturion.com Fri Oct 4 17:13:14 2019 From: jfischer at opturion.com (Julien Fischer) Date: Fri, 4 Oct 2019 17:13:14 +1000 (AEST) Subject: [m-dev.] foreign enum module qualification In-Reply-To: References: <20191004150252.GC1266@kola.localdomain> Message-ID: On Fri, 4 Oct 2019, Zoltan Somogyi wrote: > On Fri, 4 Oct 2019 15:02:52 +1000, Peter Wang wrote: >>> No objection from me. >> >> Nor from me. > > Ok, the attached diff does the first step of this change. > > For post-commit review by either of you. That looks fine. Julien. From oub at mat.ucm.es Fri Oct 25 02:31:58 2019 From: oub at mat.ucm.es (Uwe Brauer) Date: Thu, 24 Oct 2019 17:31:58 +0200 Subject: [m-dev.] ubuntu 16.04: can't compile stable branch Message-ID: <878spayxap.fsf@mat.ucm.es> Hi I am running Ubuntu 16.04 and just pulled. I can compile (make deb) the default branch (d782cce137fd) without difficulties. But when I try the same for the stable branch (4565a0afc289) I receive an error which I attach. Regards Uwe Brauer -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: error-deb.txt URL: From zoltan.somogyi at runbox.com Fri Oct 25 02:54:15 2019 From: zoltan.somogyi at runbox.com (Zoltan Somogyi) Date: Fri, 25 Oct 2019 02:54:15 +1100 (AEDT) Subject: [m-dev.] ubuntu 16.04: can't compile stable branch In-Reply-To: <878spayxap.fsf@mat.ucm.es> References: <878spayxap.fsf@mat.ucm.es> Message-ID: On Thu, 24 Oct 2019 17:31:58 +0200, Uwe Brauer wrote: > I am running Ubuntu 16.04 and just pulled. > > I can compile (make deb) the default branch (d782cce137fd) without > difficulties. > > But when I try the same for the stable branch (4565a0afc289) I receive > an error which I attach. You sent this to the developers of the Mercury programming language. Please send it to the developers of the Mercurial version control system, since it is about Mercurial, and NOT about Mercury. The two have nothing whatsoever to do with each other. Zoltan.