On 10/19/2015 03:38 PM, Philipp Stephani wrote:
> Philipp Stephani <p.stephani2@gmail.com <mailto:p.stephani2@gmail.com>>
> schrieb am Fr., 16. Okt. 2015 um 01:15 Uhr:
> 
>     I just realized that we need (at least) one more public environment
>     function, either "null" or "eq". Otherwise conditions cannot be
>     written in module code.
>     I'd vote for bool is_not_null, it seems to be the most basic one,
>     and doesn't invert the condition.

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

> There are still a few open questions:
> 
>  1.  How to represent throw/catch. Currently it's not possible to throw
>     from modules, but that should change because otherwise modules can't
>     be transparent. For example, the following couldn't work:
> 
>     emacs_value top_level = env->intern(env, "top-level");
>     if (!top_level) return NULL;
>     return env->funcall(env, top_level, 0, NULL);
> 
>     because `top-level' uses `throw'.
>     There are several ways to represent `throw'. My suggestion would
>     still be to use an enum instead of the bool value for get_error and
>     check_error. Otherwise the fact that a `throw' has happened has to
>     be encoded somehow in the error symbol, which to me seems rather
>     hackish and not future-proof. (What happens if Emacs would ever
>     allow to signal a list?)

An enum to indicate the current thread's non-local error propagation
state is probably fine.

>  2. Whether type_of should return an enum or a symbol. I'd vote for the
>     symbol, as in Daniel's original design.

A symbol means that we can define as many types as we want.

>  3. Can runtime->get_environment ever fail?

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

>  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?

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