guile-devel
[Top][All Lists]
Advanced

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

Re: ELisp?


From: joakim
Subject: Re: ELisp?
Date: Fri, 11 Nov 2011 10:46:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

Ken Raeburn <address@hidden> writes:

> On Oct 9, 2011, at 15:22, Noah Lavine wrote:
>> 
>> One question I have is, how much of Emacs' C code can Guile use right
>> now? I guess Ken Raeburn's patches are the ones that address that, but
>> I don't know what is left to do.
>
> With the stuff I've done, not much execution happens with Guile's engine, and 
> I'm not sure Guile can actually invoke anything from the Elisp side directly. 
>  I did add an "evaluate as Lisp" Scheme function and vice versa at one point 
> (I *think* it was even in the public repository), but it's a pretty minimal 
> level of support.  It was enough to throw together a simple and crude 
> "interactive Guile mode" similar to the interactive Emacs Lisp mode -- ielm 
> -- that lets you type and evaluate expressions in-process in a buffer.  So 
> when you hit return, Emacs Lisp code looked at the s-expression and passed it 
> off to be evaluated as Scheme, though if I recall correctly, strings were 
> passed back and forth between the two environments because symbols are (were) 
> still too different.

Where is your public repository? I would be interested to have a look.

A String interface is an okay start.

>
>> (I also have the same question about ELisp - what of the language is
>> left to implement? Is it just adding more builtins?)
>
> In addition to "what of the language is left to implement", I'd suggest that 
> the work remaining should include:
>
> * conformance tests
>   ** lots of the Emacs-specific extensions like buffer-local variables and 
> defaults, int-only variables, aliases, etc
>   ** interactions between them (e.g., let-bindings plus local variables when 
> switching buffers)
>   ** stack overflow protection
>   ** out-of-memory handling
>   ** error/signal trapping
>   ** timeouts, event processing
>   ** errors storing to special kinds of variables
>   ** weak hashes (make sure excess references aren't kept around due to 
> handling of symbol function slots, object properties, etc, and that GC 
> doesn't take things it shouldn't)
>   ** defadvice
>   ** debugger? debug-on-entry? debug-on-quit?
> * performance tests
>   ** high-level - e.g., byte-compile, hanoi, font-lock, hairy regexp search 
> and replace
>   ** specific functionality - global/dynamic/local bindings, symbol or text 
> properties
>   ** startup time
>   ** both speed and memory use; include tests on memory-limited configurations
>   ** multiple architectures
>      *** including at least one without Scheme->native compilation
>   ** multiple OSes
>      *** GNU/Linux
>      *** Windows (preferably native, not mingw/cygwin)
>      *** at least one non-GNU-libc one
>      *** the more the merrier
> * tests of Lisp/Scheme interactions
>   ** expected nil/#f/()/#t/t handling in both Lisp and Scheme
>   ** symbol value vs symbol function slot
>   ** inter-language calls
>   ** interactions of Lisp features with Guile threads (if Emacs Lisp doesn't 
> get threads first)
>      *** buffer-local or dynamic bindings and thread creation
>      *** is the current buffer a per-thread concept?
>
> Those would be a lot more convincing than "I typed in a bunch of Lisp 
> commands and read my email, and it all looked okay", though of course we want 
> to try those too.  This is a major and fundamental change we're proposing for 
> Emacs, and not all of the Emacs developers are convinced it's a good thing.  
> Having tests like these (and a lot more for the full Guile-Emacs 
> implementation) may help convince people that we've done our homework.
>
> We don't necessarily have to look better on all the performance numbers.  
> Though, if we don't look better on most of them, maybe it's a sign that we've 
> got more work to do first.
>
>
>> A branch on Savannah sounds like a really good idea though. Then at
>> least there would be a central thing for people to look at and hack
>> on, and more people might get involved. Right now I suspect that most
>> people don't know what's happening or where to look. If you set up a
>> branch, I for one would love to check it out and perhaps contribute
>> some patches. Do you need permission from the Emacs maintainers to do
>> that, or anything else?
>
> If there's a specific plan for moving forward, and someone in particular 
> planning to work on it and coordinate, a branch on savannah may be a good 
> idea.  The plan has got to cover dealing with changes happening in the main 
> Emacs development in the meantime (frequent merges or rare, big merges?), 
> stuff like that.  If it's just, "I'll hack on it for a few months and see how 
> it goes, and then see if someone else wants to take over", I'm not sure it'd 
> be worthwhile.

Okay, so a Savannah branch can wait.

Anyway, I think a successful approach must be incremental. Elisp and
Guile can co-exist for the time being.

As a concrete example, one could use guiles libffi integration to offer
the same feature to Emacs. I could personally use it in my xwidgets
emacs branch to call dynamically into webkit rather than having to make
a c wrapper for each and every function.

So, mainline Emacs would offer optional core guile integration for
advanced features. That would be no worse than embedding guile in any
other application and would offer benefits in its own right.

> Wherever the work gets done, it's important for everyone to have signed 
> assignment or disclaimer paperwork covering both Emacs and Guile, unless 
> they're going to be working very clearly on just one side or the other.

I have papers for Emacs at least, and no issue with signing more papers.

>
> Ken
>

-- 
Joakim Verona




reply via email to

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