[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Oddities with dynamic modules

From: Kaushal Modi
Subject: Re: Oddities with dynamic modules
Date: Fri, 12 Oct 2018 10:29:17 -0400

On Thu, Oct 11, 2018 at 2:14 PM Eli Zaretskii <address@hidden> wrote:
> Having written the documentation of the module API,

Thanks for writing up all that documentation!

I am not in the capacity to comment on most of your questions as I am
using the Modules feature to get around my lack of C knowledge :)

>  . Why aren't there API functions to _create_ lists and vectors?
>  . Using 'funcall' is unnecessarily cumbersome, because the function
>    to be called is passed as an 'emacs_value'.  Why don't we have a
>    variant that just accepts a name of a Lisp-callable function as a C
>    string?


I needed to create some sugar syntax in Nim (which compiles to C) to
get around that limitation:

proc MakeList*(env: ptr emacs_env; listArray: openArray[emacs_value]):
emacs_value =
## Return an Emacs-Lisp ``list``.
Funcall(env, "list", listArray)

proc MakeCons*(env: ptr emacs_env; consCar, consCdr: emacs_value): emacs_value =
## Return an Emacs-Lisp ``cons``.
Funcall(env, "cons", [consCar, consCdr])

It would be nice to have API for list (and cons).

>  . Why does 'intern' only handle pure ASCII symbol names?  It's not
>    like supporting non-ASCII names is hard.
>  . I could understand why equality predicates are not provided in the
>    API, but I don't understand why we do provide 'eq' there.  Is it
>    that much more important than the other predicates?

I had the same question too. I find equal more useful than eq.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]