[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic loading progress
From: |
Daniel Colascione |
Subject: |
Re: Dynamic loading progress |
Date: |
Mon, 19 Oct 2015 18:58:53 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
On 10/19/2015 03:38 PM, Philipp Stephani wrote:
> Philipp Stephani <address@hidden <mailto:address@hidden>>
> 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.
signature.asc
Description: OpenPGP digital signature
- Re: Making --with-wide-int the default, (continued)
- Re: Making --with-wide-int the default, David Kastrup, 2015/10/16
- Re: Making --with-wide-int the default, Eli Zaretskii, 2015/10/16
- Re: Making --with-wide-int the default, David Kastrup, 2015/10/16
- Re: Making --with-wide-int the default, Eli Zaretskii, 2015/10/16
- Re: Making --with-wide-int the default, David Kastrup, 2015/10/16
- Re: Making --with-wide-int the default, Stephen J. Turnbull, 2015/10/16
- Re: Making --with-wide-int the default, David Kastrup, 2015/10/16
- Re: Dynamic loading progress, Philipp Stephani, 2015/10/15
- Re: Dynamic loading progress, Philipp Stephani, 2015/10/15
- Re: Dynamic loading progress, Philipp Stephani, 2015/10/19
- Re: Dynamic loading progress,
Daniel Colascione <=
- Re: Dynamic loading progress, Tom Tromey, 2015/10/19
- Re: Dynamic loading progress, Daniel Colascione, 2015/10/19
- Re: Dynamic loading progress, Tom Tromey, 2015/10/19
- Re: Dynamic loading progress, Daniel Colascione, 2015/10/19
- Re: Dynamic loading progress, Stephen Leake, 2015/10/20
- Re: Dynamic loading progress, Philipp Stephani, 2015/10/20
- Re: Dynamic loading progress, Aurélien Aptel, 2015/10/22
- Re: Dynamic loading progress, Aurélien Aptel, 2015/10/22
- Re: Dynamic loading progress, Eli Zaretskii, 2015/10/22
- Re: Dynamic loading progress, Philipp Stephani, 2015/10/22