Allow #import of built-in variables/specification of an expression to evaluate a built-in value about artic HOT 2 OPEN

For thread IDs in particular, I think it's good that they are functions, because at the IR level that's what they have to be, you might need to generate arbitrary code everytime they're accessed. There may be room for some syntactic sugar (where () is no longer necessary to perform a call, in certain scenarios), but ideally as part of a bigger language expansion, not just piece-meal.

One thing we could add, for C-based backends anyways, is a sort of asm-like construct, but for C code:

// rought draft, don't look into the signature too much
#[import(cc = "thorin", name = "c_mixin")]
fn c_mixin[T](code: &[u8],  yield: &[u8], ...);

fn @get_bits_in_byte() -> i32 {
    let x = c_mixin("#include <limits.h>", "CHAR_BIT");
    return x;
}

That would perhaps even simplify the backend a little bit, allowing to expose more platform things as part of library code without needing back-end support.

from artic.

For thread IDs in particular, I think it's good that they are functions, because at the IR level that's what they have to be, you might need to generate arbitrary code everytime they're accessed. There may be room for some syntactic sugar (where () is no longer necessary to perform a call, in certain scenarios), but ideally as part of a bigger language expansion, not just piece-meal.

Well, I guess another way of looking at what I'm suggesting would be as a means of specifying exactly what code to generate every time the value in question is accessed. And yes, the ability to do more things through library code rather than relying on hardcoding stuff into the C backend is exactly why I think this would be great to have. In particular, it would allows us to try out things in the context of the codebase we're currently working on without having to integrate stuff into the backend just so that we can later find that it didn't work out the way we had hoped…

from artic.