Draft: Add nqp::getnextcuid

[ab5tract]

This is a mechanism for HLLs to rationally supply CUIDs at runtime without fear of collision.

I'm presenting it here for discussion as to its utility before I bother with JVM support and a better commit message.

[niner]

What's the advantage over use QAST; QAST::Block.next-cuid? And what's the use-case?

[ab5tract]

AFAIK we don't expose QAST to userland like we do with nqp, but I could be wrong here.

./rakudo-m -MQAST -e1
===SORRY!=== Error while compiling -e
Could not find QAST in:
    ...
at -e:1

I don't have any particular use cases in mind (anymore). I opened the PR because the work is already done and I figured that it would be at least worth discussing.

Maybe this will enable something that myself and others haven't thought of yet?

[lizmat]

Wouldn't a use case be Inline::Perl5 an API to create CUIDs for its own usage, that are guaranteed not to interfere with Rakudo itself?

[niner]

QAST is an NQP module, so the correction version is:

> rakudo -e 'use QAST:from<NQP>; say QAST::Block.next-cuid'
7

Inline::Perl5 doesn't need cuids. It needs to be able to export INIT phasers to its user. Cuids are just an implementation detail necessary for using the $*W.add_phaser implementation detail. It will need neither once we have a real solution in place.

[ab5tract]

QAST is an NQP module, so the correction version is:

> rakudo -e 'use QAST:from<NQP>; say QAST::Block.next-cuid'

7

So obvious now that you've pointed it out. That clearly shows this PR is not necessary.