http://qs321.pair.com?node_id=11118834


in reply to Re^4: Modernizing the Postmodern Language?
in thread Modernizing the Postmodern Language?

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.

  • Comment on Re^5: Modernizing the Postmodern Language?

Replies are listed 'Best First'.
Re^6: Modernizing the Postmodern Language?
by salva (Canon) on Jul 03, 2020 at 09:29 UTC
    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]
      So, it is not just that those platforms may have different semantics, it is that those platforms probably have the right semantics.

      I'm less convinced, having lived through a couple of big revisions of Parrot and what eventually became Raku. One reason Raku remains so stubbornly slow is because it insists on having a grammar so extensible that you can't even assume a single definition of whitespace.

      When you bake the assumption that every call to the tokenizer has to be a virtual method into either the language specification or the implementation, you're going to expose the results of that assumption to everything.

[reply]
        s/One reason Raku remains so stubbornly slow/One reason parsing in Raku remains so stubbornly slow/
[reply]

In Section Meditations