without breaking anything, is that possible?
No.
It is impossible to change the internals in any important way and keep XS code working.
Several years ago, Nicholas Clark (a perl's internals guru) tried porting perl 5 to parrot (the Perl 6 runtime), and IIRC, he didn't get too far because of XS. See Ponie has been put out to pasture.
| [reply] |
Also, once you remove the XS compatibility requirement, it would be very naive to reinvent a new guts just for running Perl 7.
When perl 5 came out, they were forced to invent everything from scratch, but now, there are lots of mature, efficient and feature rich runtimes you can reuse: .Net, JVM, MoarVM, etc.
| [reply] |
When perl 5 come out, they were forced to invent everything from scratch, but now, there are lots of mature, efficient and feature rich runtimes you can reuse: .Net, JVM, MoarVM, etc.
The problem is when the semantics of the VM don't match the semantics of the language, especially with regard to memory management, dispatch, process models, etc.
| [reply] |
but now, there are lots of mature, efficient and feature rich runtimes you can reuse: .Net, JVM, MoarVM, etc.
Isn't the problem always reference counting vs. tracing gc, though? If you expect DESTROY to run when your objects go out of scope, for example, most gc runtimes won't destruct objects in a timely fashion and I think some won't call destructors at all. I want to say dotNET core got rid of finalizers, for example. But regardless of details, I agree that runtime-independence is the kind of aspirational thing that would make the pain of retiring XS worth it.
| [reply]
[d/l] |
