Re: Dynamic loading progress

[Tom Tromey]

Daniel> Yes, we do. I'd prefer eq, since the definition will never change, and
Daniel> having a nice convenient way to access eq is useful in more situations
Daniel> than a specialized test for eq nil.

Both are useful and it is cheap to provide a method, so why not have
both eq and nilp?

Daniel> Maybe we should actually get rid of get_environment and rely entirely on
Daniel> passed-in environment objects. It simplifies the API and avoids
Daniel> definitional problems.

Yeah, I brought this up earlier and I still don't understand the reason
for the runtime/environment split.

>> 4. Some of the function (free_global_ref, the int/float extractors)
>> don't return emacs_value and have no clear way to signal an error.
>> For these function the caller always has to use
>> check_error/get_error. Is that good enough?

Daniel> free_global_ref, like all resource-releasing functions, should be
Daniel> infallible. For other functions, asking users to check the error state
Daniel> after a call is fine, although we should also return reasonable dummy
Daniel> values (0 and NaN, probably) as well in case they don't.

It might be handy if there was a special emacs_value meaning that an
error occurred.

Tom