[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs lisp source code portability - Possible to use same backend co
From: |
Pascal J. Bourguignon |
Subject: |
Re: Emacs lisp source code portability - Possible to use same backend code when emacs not available? |
Date: |
Sat, 30 Mar 2013 23:05:02 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com> writes:
> Hello!
>
>
> === Question ===
>
> Is it possible to write emacs lisp code that runs without
> modification
> when emacs is not available?
>
> Note: The question is mostly of academic interest. Currently I have
> no
> actual application in mind.
>
>
> === Motivation ===
>
> Think about this scenario:
>
> Someone writes an emacs mode for editing a file format. Because
> convenient editing of the files requires parsing the format he
> implements a parser in emacs lisp. Because the parser is available in
> emacs lisp, he also writes converters in emacs lisp.
>
> At a later point the file format has become complex and popular.
> Popular enough to bring it to non-emacs-users and mobile devices. As a
> consequence the availability of Emacs (as a lisp platform) can no
> longer be assumed. While emacs could be installed as dependency on
> desktop platforms at the cost of a large installer, on mobile
> platforms this may not be feasible.
How is 8 MB large?
One could say that this dependency would be a good thing to promote
emacs and free software in general.
> As a consequence -- as far as I know -- the backend code would have to
> be rewritten in another language.
Hence (require 'cl) and the use as much as possible of CL functions
rather than their equivalent emacs-lisp function.
> === Possible solutions which I may just not know of ===
>
> - An implementation of a subset of common lisp that compiles to emacs
> lisp byte code. `cl` doesn't count, as previous versions used
> constructs like `defun*' and current versions a prefix `cl-`.
Yes, this is an unfortunate move. Notice however, that to convert such
code to cl, you only have to substitute /\<cl-/ by /cl:/.
Or, you could also quite easily define those symbols in Common Lisp:
(do-external-symbols (s "CL")
(let ((cl-s (intern (format nil "CL-~A" (symbol-name s)))))
(cond
((macro-function s)
(setf (macro-function cl-s) (macro-function s)))
((special-operator-p s)
(eval `(defmacro ,cl-s (&rest args) `(,',s ,@args))))
((fdefinition s)
(setf (symbol-function cl-s) (symbol-function s))))
(when (ignore-errros (fdefinition `(setf ,s)))
(setf (fdefinition `(setf ,cl-s)) (fdefinition `(setf ,s))))
(when (boundp s)
(eval `(define-symbol-macro ,cl-s ,s)))))
> - A subset of emacs lisp that depends on as little C-code as possible.
> This might allow writing a standalone-interpreter in a language
> available on the target-system with acceptable effort by reusing
> parts of Emacs' *.el sources.
There's already a standalone interperter of emacs lisp (several
probably). The one I have in mind is written in Common Lisp in the
frame of the Hemlock editor. Not really complete, but it could be a
starting base.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.