Clean API functions names

[aaptel]

Chose and keep a consistent style for API function name. Let's do this while we can (ie before release).

[phst]

I'd suggest to stay as close as possible to definitions in the Emacs Lisp manual and the naming of Emacs functions.

• Instead of "error" we should say "nonlocal exit" (https://www.gnu.org/software/emacs/manual/html_node/elisp/Nonlocal-Exits.html#Nonlocal-Exits)
• Instead of "fixnum" we should say "integer" (https://www.gnu.org/software/emacs/manual/html_node/elisp/Integer-Basics.html#Integer-Basics)
• Instead of using different names for C and Lisp types, let's just say {make,extract}_{integer,float} or so
• Maybe we can find a better name for the "user ptr" thingy? "Module reference"?

[aaptel]

Instead of "error" we should say "nonlocal exit"

Ok, so nonlocal_exit?

Instead of "fixnum" we should say "integer"

Ok.

Instead of using different names for C and Lisp types, let's just say {make,extract}_{integer,float} or so

I don't like using float for double but I agree it's more consistent. What do you think of using get instead of extract?

[aaptel]

Maybe we can find a better name for the "user ptr" thingy? "Module reference"?

What is wrong with "user ptr"?

[phst]

What is wrong with "user ptr"?

Nothing in particular, I'm just not overly fond of function names like get_user_ptr_ptr. It seems like a "user pointer" is an object containing a pointer and a finalizer, so it shouldn't itself be called "pointer."

[aaptel]

get_module_ref_ptr doesnt look that prettier. Maybe we could just use get_user_ptr and get_user_finalizer.

[tromey]

It still seems better to extend Lisp_SaveValue to take an optional finalizer and avoid adding a second opaque pointer type to Emacs. You can just make it possible for the first slot to be a finalizer, there are still SAVE* bits left.

[phst]

That would also work, but I think it wouldn't change the interface or naming. (There is currently no way to create Save_Values from modules.)

[aaptel]

I think user pointer are fundamentally different than Save_Values and as such deserve a type. We might need extra fields in the future that save values cannot accomodate for.

[aaptel]

I've pushed a commit that updated API functions & other denominations according to this discussion. I'm keeping this open in case we still want to change some names. If you are OK with this please say so, so I can close the issue.

@tromey you probably need to update your ffi module.

[tromey]

I don't want to keep bugging you about the type thing, so I promise I won't bring it up again. But anyway my view is that types are important for user code (or I suppose the platform) to differentiate between different kinds of objects. But, in this case, both user-pointers and save-values are just opaque types that are essentially useless to elisp. That is why, in my view, it makes sense to unify them.

[aaptel]

Save_Value is an internal type that is not supposed to be exposed to users.

User-pointer are can be exposed. We could add a symbol or some kind of id as user-ptr sub-types (like we had previously with module_id...).