Re: Emacs lisp source code portability - Possible to use same backend code when emacs not available?

Re: Emacs lisp source code portability - Possible to use same backend code when emacs not available?

[Pascal J. Bourguignon]

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 {}.

Emacs lisp source code portability - Possible to use same backend code when emacs not available?

[Klaus-Dieter Bauer]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

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.

As a consequence -- as far as I know -- the backend code would have to
be rewritten in another language.


=== 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-`.

- 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.


kind regards, Klaus-Dieter

[-- Attachment #2: Type: text/html, Size: 2118 bytes --]