This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> What would be involved in making guile able to run elisp code? Is the > reader general enough? What sort of (how much) new syntax/new library > procedures are necessary? (I don't know elisp, I just write scheme > and hope emacs likes it) I think this is talked about somewhere on the web site. The idea is to write a new reader for Emacs Lisp, or whatever language you want to handle, and then write a translator from Emacs Lisp into Scheme. This translation is non-trivial; for example, Emacs Lisp's `let' does dynamic binding, while Scheme's `let' does static binding. In emacs Lisp, (car nil) is nil, whereas in Scheme, (car '()) is an error. So clearly, there's some non-trivial work involved here. But it's really just a compilation problem, where we can amend the target architecture (Guile) to make the translation easier. The long-term goal is to support all kinds of languages this way. Ideally, we'd have translators for Perl and Tcl, too. (For the sake of discussion, we'll set aside concerns about whether Perl is sufficiently well-defined to allow alternative implementations. That parser would be a killer.) > What sort of efficiency issues are there? Currently guile takes a > long time to read in source code This is because the module system is poorly implemented. > and unexec is fast but very limited. One thing I'd like to see, in the long term, is for Guile to evolve into a language that allows separate compilation. I *think* that, once you have enough of a separation between the compile phase and the run phase, you might be able to make the limitations of unexec go away, because you've already got a well-defined boundary between the phases, across which certain kinds of objects are not expected to be live. This boundary would be a nice place to take a dump (so to speak). There are alternatives to unexec, too. > How difficult would it be to make the emacs C code talk to guile? I don't think it would be that bad, actually. There aren't any demands I can think of offhand that Guile makes of C code that Emacs doesn't already follow (aside from threading issues, and some concerns about strings and vectors getting GC'd too early), so you could pretty much do a brute conversion, recompile, and start fixing errors. > An additional side effect of hooking guile to emacs would be to allow > users more flexible customization/extension syntax. It really isn't > very difficult to add a new syntax to guile. Sure. Syntax variation should be managed by the module system, though. The argument goes something like, you can use whatever syntax you want, as long as you warn me, and make sure I don't have to worry about your syntactic extensions in the other code I'm running. Let's not create chaos. > Guile is also multithreaded. This may be a problem for emacs code. > Actually, ideally, guile should become OS-level multithreaded. > Moreover, it should also have parallel or mostly-parallel garbage > collection. (see http://reality.sgi.com/employees/boehm_mti/gc.html) > Currenttly the lengthy pauses for garbage collection are a serious > limitation of guile's performance. This is a more serious problem. I'm not sure how we'd resolve it. We might simply configure Guile without the threading support for Emacs. > So, how much work/what effort would be involved in this? Two frogs.