Hello PolyMLers,
Some time ago I proposed PolyML switch to building with the C++11 standard [0]. The main blocking issue that surfaced was Isabelle supporting Ubuntu 12.04 which ships without a C++11-enlightened compiler. In January 2019, Makarius bumped the supported Linux release to Ubuntu 14.04 [1] which has a C++11 compiler. Are there any remaining issues preventing a migration to C++11? Do people feel strongly for or against this? The immediate benefits are similar to what I listed in my original posting:
- PLock, PLocker, PCondVar implementations could all be deleted and dropped with std::mutex, std::lock_guard, std::condition_variable respectively - NORETURNFN could be replaced with [[noreturn]] - Bitmap could be dropped and replaced with std::vector<bool>
The general motivation here is reducing the maintenance overhead and allowing performance to evolve with libstdc++/libc++. I expect we could get a lot of mileage out of code clarity wins too (e.g. range-based for loops).
I haven?t CCed isabelle-dev because I think they would have no opinion on this topic, but Makarius if you think it?s relevant please loop them into this thread as well.
Thanks, Matt
[0]: http://lists.inf.ed.ac.uk/pipermail/polyml/2017-December/002125.html [1]: http://isabelle.in.tum.de/repos/isabelle/rev/88b8bc6a6e5f
On 19/05/2019 05:57, Matthew Fernandez wrote:
Some time ago I proposed PolyML switch to building with the C++11 standard [0]. The main blocking issue that surfaced was Isabelle supporting Ubuntu 12.04 which ships without a C++11-enlightened compiler. In January 2019, Makarius bumped the supported Linux release to Ubuntu 14.04 [1] which has a C++11 compiler. Are there any remaining issues preventing a migration to C++11? Do people feel strongly for or against this? The immediate benefits are similar to what I listed in my original posting:
First note that I am presently busy with the Isabelle2019 release (and will be on travel after its launch in a few weeks).
For Isabelle technology (which also includes Poly/ML), I am generally in favour to use what is both "current" and "stable" -- the precise meaning of that is up to judgment by experts, but I am not an export of C++.
This often means to use the latest release version, but sometimes latest -1. (Current examples for -1 in Isabelle: scala, Haskell stack; latest: java-11, although some users might prefer -1 here.)
BTW, for Poly/ML on Windows, there is still a slightly odd situation that its canonical build process is stuck with a very old version of g++ on MingW: http://isabelle.in.tum.de/repos/isabelle/file/acc1749c2be9/Admin/polyml/INST...
I would like to see this bumped eventually, independently of the C++11 question.
Makarius
On May 19, 2019, at 04:51, Makarius <makarius at sketis.net> wrote:
On 19/05/2019 05:57, Matthew Fernandez wrote:
Some time ago I proposed PolyML switch to building with the C++11 standard [0]. The main blocking issue that surfaced was Isabelle supporting Ubuntu 12.04 which ships without a C++11-enlightened compiler. In January 2019, Makarius bumped the supported Linux release to Ubuntu 14.04 [1] which has a C++11 compiler. Are there any remaining issues preventing a migration to C++11? Do people feel strongly for or against this? The immediate benefits are similar to what I listed in my original posting:
First note that I am presently busy with the Isabelle2019 release (and will be on travel after its launch in a few weeks).
For Isabelle technology (which also includes Poly/ML), I am generally in favour to use what is both "current" and "stable" -- the precise meaning of that is up to judgment by experts, but I am not an export of C++.
This often means to use the latest release version, but sometimes latest -1. (Current examples for -1 in Isabelle: scala, Haskell stack; latest: java-11, although some users might prefer -1 here.)
For some context, the ISO C++ standards are C++98, C++03, C++11, C++14, C++17 and the forthcoming C++20. If you do not set the C++ standard via command line flags (-std= for GCC and Clang, /std: for MSVC), you get whatever version of the standard that compiler release decided was a sensible default. This is the situation PolyML is currently in. The standards are roughly backwards compatible, so in practice this means if you don?t explicitly set a standard you?re stuck with the ad hoc subset of commonly implemented features prior to 1998. IMHO C++11 is the first version of the standard that brings some well-needed sanity to the language. In particular, threading and locks are in the standard, obviating the need for libraries to write their own abstraction layer over POSIX/Windows. The features added by C++14 and C++17 are less revolutionary and unlikely to be of immediate use to PolyML.
BTW, for Poly/ML on Windows, there is still a slightly odd situation that its canonical build process is stuck with a very old version of g++ on MingW: http://isabelle.in.tum.de/repos/isabelle/file/acc1749c2be9/Admin/polyml/INST...
I would like to see this bumped eventually, independently of the C++11 question.
If I understand the version numbering correctly, those MinGW versions are derived from GCC 4.9.3 which supports C++11.
On 19/05/2019 17:46, Matthew Fernandez wrote:
If I understand the version numbering correctly, those MinGW versions are derived from GCC 4.9.3 which supports C++11.
Such claims of supporting certain standards are rarely accurate. It usually takes years to make things really work. See also this reply on the old thread: http://lists.inf.ed.ac.uk/pipermail/polyml/2017-December/002139.html
I am all for bumping up that old MinGW build environment, but it is up to David Matthews to do something about it, or leave the status-quo unchanged.
Makarius
On Sun, 19 May 2019 at 10:43, Makarius <makarius at sketis.net> wrote:
On 19/05/2019 17:46, Matthew Fernandez wrote:
If I understand the version numbering correctly, those MinGW versions
are derived from GCC 4.9.3 which supports C++11.
Such claims of supporting certain standards are rarely accurate. It usually takes years to make things really work. See also this reply on the old thread: http://lists.inf.ed.ac.uk/pipermail/polyml/2017-December/002139.html
Agreed, but you can get a pretty accurate record from https://www.gnu.org/software/gcc/projects/cxx-status.html#cxx11 which shows everything relevant was completed before 4.9. In practice, I have not experienced anything that makes me doubt this table.
I am all for bumping up that old MinGW build environment, but it is up to David Matthews to do something about it, or leave the status-quo unchanged.
Makarius
On 19/05/2019 19:48, Matthew Fernandez wrote:
Agreed, but you can get a pretty accurate record from? https://www.gnu.org/software/gcc/projects/cxx-status.html#cxx11 which shows everything relevant was completed before 4.9. In practice, I have not experienced anything that makes me doubt this table.?
I do doubt such tables by default: they are just more claims with more details. Such things need to be tried out more explicitly.
I am all for bumping up that old MinGW build environment, but it is up to David Matthews to do something about it, or leave the status-quo unchanged.
I see 3 possibilities here:
(1) leave status-quo: stability remains mostly unchanged, with minor downwards tendency in the long run (old gcc on new OS/HW versions)
(2) bump gcc, leave c++ standard unchanged: slight increase of stability (assuming that gcc generally becomes better over time)
(3) bump c++ standard, leave gcc unchanged: potential loss of stability (old gcc on new language standard -- unproven technology)
Makarius
On 19/05/2019 18:43, Makarius wrote:
On 19/05/2019 17:46, Matthew Fernandez wrote:
If I understand the version numbering correctly, those MinGW versions are derived from GCC 4.9.3 which supports C++11.
Such claims of supporting certain standards are rarely accurate. It usually takes years to make things really work. See also this reply on the old thread: http://lists.inf.ed.ac.uk/pipermail/polyml/2017-December/002139.html
I am all for bumping up that old MinGW build environment, but it is up to David Matthews to do something about it, or leave the status-quo unchanged.
Actually, it looks as though I am currently using GCC 5.1.0 on Msys2 and that seems to work fine. I think things have stabilised since I wrote the original instructions for installing Msys2/Mingw.
David
I've been thinking about this and reading the various comments. On the whole I'm not convinced that any change would actually be worthwhile at the moment. There would be a very good case for using some of these features if the code were being written from scratch but it's far from clear that there will be any gain from changing the code now.
Bitmap is used in the garbage-collector and there is one bit for each word in the heap. As I understand it, std::vector<bool> does not guarantee to use just a single bit for each bool but that is essential to keep the memory size down. The code, including the way bitmaps are allocated, has been carefully crafted to work with the garbage collector.
The situation continues to evolve and there may be good reasons to make some of these changes in the future but maybe just not now.
Thanks for your comments.
David
On 19/05/2019 04:57, Matthew Fernandez wrote:
Hello PolyMLers,
Some time ago I proposed PolyML switch to building with the C++11 standard [0]. The main blocking issue that surfaced was Isabelle supporting Ubuntu 12.04 which ships without a C++11-enlightened compiler. In January 2019, Makarius bumped the supported Linux release to Ubuntu 14.04 [1] which has a C++11 compiler. Are there any remaining issues preventing a migration to C++11? Do people feel strongly for or against this? The immediate benefits are similar to what I listed in my original posting:
- PLock, PLocker, PCondVar implementations could all be deleted and dropped with std::mutex, std::lock_guard, std::condition_variable respectively
- NORETURNFN could be replaced with [[noreturn]]
- Bitmap could be dropped and replaced with std::vector<bool>
The general motivation here is reducing the maintenance overhead and allowing performance to evolve with libstdc++/libc++. I expect we could get a lot of mileage out of code clarity wins too (e.g. range-based for loops).
I haven?t CCed isabelle-dev because I think they would have no opinion on this topic, but Makarius if you think it?s relevant please loop them into this thread as well.
Thanks, Matt
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
-
David.Matthews＠prolingua.co.uk -
makarius＠sketis.net -
matthew.fernandez＠gmail.com