Languages which are not C should not depend on C. A language design is much more compelling when its own compiler, runtime, stdlib, etc are self-hosting (i.e. written in the language itself). Constraining ourselves to a language design which can route all of its syscalls through the libc abstraction layer (which is THICK) constrains our language designs in ways I dislike.
@sir also, ABI definitions shouldn't depend on C.
@Wolf480pl strong disagree with this one
@sir why tho?
@Wolf480pl the ABI isn't an abstraction as much as it's a language. System-V is the lingua franca of ABIs and the constraints it imposes are managable/desirable and necessary for dissonant modules to communicate. By constraining ourselves to the C ABI then we (1) discourage being too clever and (2) prevent the introduction of FFI layers with awkward idiomaticy transitions
@sir I guess we meant different things by ABI.
I meant ABI as in "binary signature of this particular set of functions", while you meant sth like "a method to translate source-level signature of a function to binary calling protocol".
Like, when you describe a type of a function, one way to do it is to write its C signature, like:
which uses C-specific types eg size_t, or int, whose size can differ across machines, and can be different from the size of those types in the language from which you're calling this function from.
Alternatively, you could describe the function like this:
which is IMO less ambiguouss.
Of course you still need to know the calling convention - in which registers to pass arguments, etc.. In theory it'd be nice if we had a declarative syntax to describe that, too, but I agree that it's better if all functions use the same calling convention.
@Wolf480pl yeah, this is the wrong definition of an ABI. You mean the C type system
@Wolf480pl though note that you lose some semantics here: void* is deliberately an untyped pointer (cause malloc doesn't know what you're using it for - it might not be u8) and size_t is an architecture-specific size. u8 also isn't always necessarily the lowest common denominator - it's *probably* (but not definitely) the smallest possible addressable unit, but it's also likely to be too slow for some use-cases. Not to mention encoding concerns like pointer alignment and so on... there are reasons C is the way it is and they should be taken account if considering a different API design
Welcome to your niu world ! We are a cute and loving international community Ｏ(≧▽≦)Ｏ !