5 ms·

Programming language designer here. I'm currently making a language, and yes, I'm reserving words for it because I want an easy C ABI. But I'm also making them

Programming language designer here. I'm currently making a language, and yes, I'm reserving words for it because I want an easy C ABI. But I'm also making them easier to avoid. Here's my list of reserved words: * Anything that begins with `y_`. * Anything that begins with `yc_`. * Anything that begins with `YC_`. * Anything with three or more consecutive underscores. * Edit: Anything that begins with an underscore. This is because my language will be able to transpile to C if necessary. The first is for types and items in the standard library (the language's name is Yao, so a `y` makes sense). The second and third are for the C ABI (hence, `yc`) and for historical reasons. `YC_` in particular is for C macros. The last is for name "mangling." I put it in quotes because my language's standard name mangling (it will be the same across every implementation) will not really mangle the names. Instead, it will concatenate them, using five underscores between package names, four underscores between packages and items in a package, and three underscores between an item and its suffix. (For overloaded functions, the programmer has to define a suffix for each one. That suffix is how their names will be different in the C ABI.) My hope is that these rules will not be too onerous. I don't think the reserved prefixes are used much, and I haven't seen anyone use more than one consecutive underscore, though I'm allowing one more, just in case.

pengaru 4y ago
It's unfortunate POSIX didn't adopt a similar convention for its reservations, like a psx_ suffix for its namespace. But I guess with POSIX it was more ratifying established *NIX things as a standard they could all easily agree on without too much disruption.
cyber_kinetist 4y ago
‘y_’ is too strict in my opinion. You declare lots of variables like y_1 or y_ans when you write any sort of numerical calculation code (like in games or physics simulations).
- gavinhoward 4y ago
  It seems too strict, but I should clarify: these rules only apply to the C ABI. Declaring variables with those names actually will not conflict if they are done in pure Yao. There's a special way to access the C symbols of functions and types, and it's deliberately different, for this very purpose.
  - cyber_kinetist 4y ago
    Ah if that’s only for the C ABI then that’s much better. I still see someone writing numerical algorithms might use y_* as one of the arguments, though the probability is a lot more slim.
    - gavinhoward 4y ago
      That's true, so I should clarify even further. The restriction isn't on `y[c]_`. It's actually on `y[c]___`. This is because `y` is the package name for the standard library, and the standard library name will always be separated from the rest of the name by 3 or more underscores. Really, the restriction is on 3 or more consecutive underscores in C names, and you can't have have a package name that is either `y`, `yc`, or `YC`. I apologize for the confusion. I was in a hurry and on mobile with the original post.

pengaru 4y ago

It's unfortunate POSIX didn't adopt a similar convention for its reservations, like a psx_ suffix for its namespace. But I guess with POSIX it was more ratifying established *NIX things as a standard they could all easily agree on without too much disruption.

cyber_kinetist 4y ago

‘y_’ is too strict in my opinion. You declare lots of variables like y_1 or y_ans when you write any sort of numerical calculation code (like in games or physics simulations).

gavinhoward 4y ago
It seems too strict, but I should clarify: these rules only apply to the C ABI. Declaring variables with those names actually will not conflict if they are done in pure Yao. There's a special way to access the C symbols of functions and types, and it's deliberately different, for this very purpose.
- cyber_kinetist 4y ago
  Ah if that’s only for the C ABI then that’s much better. I still see someone writing numerical algorithms might use y_* as one of the arguments, though the probability is a lot more slim.
  - gavinhoward 4y ago
    That's true, so I should clarify even further. The restriction isn't on `y[c]_`. It's actually on `y[c]___`. This is because `y` is the package name for the standard library, and the standard library name will always be separated from the rest of the name by 3 or more underscores. Really, the restriction is on 3 or more consecutive underscores in C names, and you can't have have a package name that is either `y`, `yc`, or `YC`. I apologize for the confusion. I was in a hurry and on mobile with the original post.