Re: Dynamic loading progress

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Stephen Leake <address@hidden>,
>     address@hidden
> Date: Sat, 14 Feb 2015 21:18:51 +0900
> 
> Eli Zaretskii writes:
>  > > From: Stephen Leake <address@hidden>
>  > > Date: Fri, 13 Feb 2015 15:48:07 -0600
>  > > 
>  > > My use case requires calling lisp functions; in particular,
>  > > put-text-property, but also other higher-level lisp functions in
>  > > ada-mode.
>  > 
>  > Why do you need to call Lisp in the module?  I think it's a no-no for
>  > modules to call Lisp; that should be done in the Lisp code that uses
>  > the module.
> 
> I don't understand.  XEmacs's ELLs (dynamically loadable modules) have
> no problem with calling Lisp (use Ffuncall) or using symbols (use
> Fintern).  The only requirement that I've seen expressed in this
> thread that XEmacs ELLs don't satisfy is that a module should be
> compilable for use with multiple versions of XEmacs

This last requirement is what is being discussed here.  The capability
of creating Lisp objects depends on the internals, and AFAIU we would
like to avoid having that dependency.

>  > Why does an implementation of a parser need to call Lisp?
> 
> I can't give you a reason in the case of a parser, but in general
> compiled Lisp functions may want to provide Lisp hooks, or implement
> inner loops for simple functionality in C but do flexible handling of
> more complex functionality in Lisp.

I wasn't talking about using Lisp by modules, I was talking
specifically about calling Lisp from C.  Implementing new primitives
for performance purposes doesn't need that, at least it isn't clear to
me why it would.