Re: Dynamic loading progress

[Stephen Leake]

Daniel Colascione <address@hidden> writes:

> On 02/14/2015 04:39 PM, Stephen Leake wrote:
>> Eli Zaretskii <address@hidden> writes:
>> 
>>>> Date: Sat, 14 Feb 2015 18:02:22 +0200
>>>> From: Eli Zaretskii <address@hidden>
>>>> Cc: address@hidden
>>>>
>>>>> From: Stephen Leake <address@hidden>
>>>>> Date: Sat, 14 Feb 2015 09:32:54 -0600
>>>>>
>>>>> Emacs ada-mode does indentation in two steps; first it parses the source
>>>>> code, and the parser actions are lisp functions that eventually call
>>>>> put-text-property to store information about the syntax and/or semantics
>>>>> on many identifiers. Then the indentation code uses those text
>>>>> properties to compute indentation.
>>>>>
>>>>> I have a generalized LALR parser implemented in elisp that is fast
>>>>> enough for many user's Ada files, but some users have much bigger files,
>>>>> and it takes them 10 seconds to parse. So I need a faster
>>>>> implementation. So far my benchmarking says I can get close with a
>>>>> machine compiled parser.
>
> You don't a parser in C. You need a smarter parser. Look up
> "incremental", please.

Yes, an incremental parser would help. I have looked at that; I'd much
rather write that in Ada than in lisp.

I tried using an Ada parser in a separate process communication via
pipes over stdin/stdout; the communications overhead was too much.

So a module implementation would still be a good thing. For the moment,
just moving the current parser into a module is the first step; if that
is not fast enough, implementing an incremental parser is the next step.

>>>>> So the module would contain the generalized LALR parser; the actions of
>>>>> the parser would still be calls to the lisp functions.
>
> The right way to let C libraries call Lisp functions is to let C
> libraries accept C callback functions, then thunk from C callbacks to
> Lisp functions in the CFFI layer. That's what other CFFI implementations
> do. This way, your library _still_ doesn't need to know about specific
> Lisp internals.
>
> The module proposal in this thread will harm Emacs development because
> it'll put unnecessary constraints on the elisp implementations. Look at
> how much trouble PyPy has with CPython modules.

It appears that the people actually working on this issue don't have
experience with the various forms of module interface.

Perhaps you could take a stab at writing a CFFI layer that is sufficient
for the curl module?

-- 
-- Stephe