On 11/25/2015 12:24 AM, Paul Eggert wrote:
> Daniel Colascione wrote:
>> You could argue that file descriptors are basic. They're just handles to
>> bits of kernel memory, right?
> 
> I'm not making that argument. I am arguing that memory allocation is
> basic, though. It really is. It happens *all the time* in the C code
> inside Emacs, and it's almost surely going to happen all the time in
> module code as well. It should be easy, not a pain.

Modules in C already have to handle checking for failures of their
internal allocations. What makes checking for failures of Emacs-side
allocations so much worse?

There are ways of making working with Lisp easier while preserving
robustness. I've previously proposed providing a utility function that
lets callers write expressions like this:

emacs_value v =
  env->eval_fmt(env, "`(foo (xyz . bar) ,%v ,%s ,(something %d))",
my_emacs_value, "blah", 42);
if(!v) { return NULL; } // Equivalently, if (env->error_p(env)) { return
NULL; }
do_something_with(v);

It's possible to implement eval_fmt mostly in Lisp, and it would let C
callers naturally construct arbitrarily complicated Lisp data structures
while only checking for errors in one place. Sure, it's not the fastest
thing the world, but in hot spots, modules can always drop down to the
very exact, but very verbose, API we've been complaining about here.

It should also be possible to write a function that pulls values out of
existing data structures just like destructuring-bind ---

char* key;
int value;
emacs_value some_plist = mumble;

while (env->is_not_nil(some_plist) && env->extract_fmt(env, some_plist,
"(%s %d . %v)", &key, &value, &some_plist)) {
  do_something(key, value);
  env->emacs_free(key); // extract_fmt allocated memory for the contents
of the string key using the internal emacs allocator
}
if (env->error_p(env)) {
  return NULL;
}

This way, it's possible to do fairly involved things while not checking
for errors at every single step.

It's also possible to implement eval_fmt and extract_fmt as library
functions written in terms of the current module API, but it wouldn't
hurt to provide them directly for the convenience of C callers.