3 ms·
Your old C code and your old C++ code will almost always compile as is with a newer standard. Depends on the code: Some of it won't compile without providing j
by cygx 9y ago
Your old C code and your old C++ code will almost always compile as is with a newer standard.
Depends on the code: Some of it won't compile without providing just the right set of flags.
In case of C, for me the crucial feature is not so much full backwards compatibility, but interoperability (you can link the object code regardless of the language version) and the convenience of using the same frontend executable.
In case of Perl, the former is currently possible to some degree via the Perl5 module Inline::Perl6 and the Perl6 module Inline::Perl5.
Personally, I would like to see the latter become a reality as well - this is the solution I'd perfer over trying to distance Perl6 from Perl5 via rebranding.
- raiph 9y agoIf you browse the #perl6-toolchain logs[1] you'll see folk making steady progress toward practical interop of multiple versions of the P6 language (6.c, 6.d, etc.), P6 compilers (Rakudo 2017.07 etc.), and P6 modules on the one hand and hosting this stuff on CPAN on the other. But perhaps you know about that already. I may be imagining things but, peering years into the future, it seems this versioning management aspect of the P6 toolchain might end up being the foundation of a new multiple lang/compiler/module version juggling Perl package manager that can be used with P5, P6, python etc. Does that make sense to you? [1] https://irclog.perlgeek.de/perl6-toolchain https://irclog.perlgeek.de/perl6-toolchain