Please consider adding literals support

[igor-elovikov]

Concisely describe the proposed feature
Let's have a look on an implementation of popular pcg hash in taichi. Roughly it looks like this:

uint pcg_hash(uint input)
{
    uint state = input * 747796405u + 2891336453u;
    uint word = ((state >> ((state >> 28u) + 4u)) ^ state) * 277803737u;
    return (word >> 22u) ^ word;
}

In taichi I should do something like this:

@ti.func
def pcg_hash(inp: ti.u32) -> ti.u32:
    n1: ti.u32 = 747796405
    n2: ti.u32 = 2891336453
    n3: ti.u32 = 277803737

    b28: ti.u32 = 28
    b22: ti.u32 = 22
    b4: ti.u32 = 4

    state: ti.u32 = inp * n1 + n2
    word: ti.u32 = ((state >> ((state >> b28) + b4)) ^ state) * n3

    return (word >> b22) ^ word

There are other issues rather than verbosity (mentioned separately here: #4210, apparently I can't even declare typed const expressions), but here I'd like to point to using literals for convenience.

Describe the solution you'd like (if any)

Not sure what is the best way to do that.
I can think of at least two methods.

1. Making dtype callable at least in taichi context.

@ti.func
def pcg_hash(inp: ti.u32) -> ti.u32:
    state: ti.u32 = inp * ti.u32(747796405) + ti.u32(2891336453)
    word: ti.u32 = ((state >> ((state >> ti.u32(28)) + ti.u32(4))) ^ state) * ti.u32(277803737)

    return (word >> ti.u32(22)) ^ word

Much better and with some additional analysis on arguments can be used as an alternative to ti.cast

2. Fancy indexing or exploiting ast.Call

@ti.func
def pcg_hash(inp: ti.u32) -> ti.u32:
    state: ti.u32 = inp * 747796405[ti.u32] + 2891336453[ti.u32]
    word: ti.u32 = ((state >> ((state >> 28[ti.u32]) + 4[ti.u32])) ^ state) * 277803737[ti.u32]

    return (word >> 22[ti.u32]) ^ word

Considering the fact that 25[ti.f32] {1.0, 2.0}[vec3f] (1.0, 2.0)[vec3i] 25(ti.f32) {1.0, 2.0}(vec3f) (1.0, 2.0)(vec3i) are valid python syntax (making set or tuple callable doesn't make sense in the interpreter but it's still valid)
Here we can use some sort of trailing type declaration. A bit isoteric, but who knows

Additional comments
It's probably a very specific issue, but I would be nice to have at least an optional support to be more explicit in the language.

Right now I've tested hash function and it works as expected, but I'd still like explicitly set unsigned here as at some backends signed bit shifting can be undefined.

[k-ye]

Thanks for proposing this! Personally I find 1 to be the (much) more intuitive approach

[ailzhang]

+1 on the first approach. :D

[igor-elovikov]

Agreed, it's also close to how pycuda works when passing parameters to the kernel.

[strongoier]

Closed via #4440.