|
in reply to Re^2: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?
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. |
Re^4: Modernizing the Postmodern Language?
by salva (Canon) on Jul 02, 2020 at 10:20 UTC
|
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] |
|
|
Yes, absolutely. It would be impossible to implement perl 5 on top of any of those VMs and get the same semantics.
But we are fantasizing about the scenario where breaking backward compatibility is acceptable to the point of removing support for XS.
So, does it make sense nowadays to keep using reference counting instead of a proper garbage collector? Deterministic destructor calls is a nice thing, but well, it seems most language designers are glad to sacrifice them in favor of proper automatic memory management.
Does it make sense to use the UNIX process model? isn't it better to move to a higher OS-agnostic abstraction? Actually, proper Windows support was one of the first things proposed on p5p related to improvements people would like to see in future Perls.
Custom dispatch semantics seems to be something you can emulate in most platforms at the cost of degraded performance.
So, it is not just that those platforms may have different semantics, it is that those platforms probably have the right semantics.
| [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] |
|
|
Isn't the problem always reference counting vs. tracing gc, though?
Yes, you have to choose between deterministic destruction or garbage collection.
Languages with garbage collection usually provide a with construction (that I think comes from LISP).
Nowadays it seems that everybody (or at least, most language designers) admits that having a proper garbage collector is something so good that it well worths the trouble of requiring those with guards.
| [reply]
[d/l]
[select] |
|
|
