unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Emacs lisp source code portability - Possible to use same backend code when emacs not available?
@ 2013-03-30 18:11 Klaus-Dieter Bauer
  0 siblings, 0 replies; 2+ messages in thread
From: Klaus-Dieter Bauer @ 2013-03-30 18:11 UTC (permalink / raw)
  To: help-gnu-emacs

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Emacs lisp source code portability - Possible to use same backend code when emacs not available?
       [not found] <mailman.23114.1364670647.855.help-gnu-emacs@gnu.org>
@ 2013-03-30 22:05 ` Pascal J. Bourguignon
  0 siblings, 0 replies; 2+ messages in thread
From: Pascal J. Bourguignon @ 2013-03-30 22:05 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-03-30 22:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.23114.1364670647.855.help-gnu-emacs@gnu.org>
2013-03-30 22:05 ` Emacs lisp source code portability - Possible to use same backend code when emacs not available? Pascal J. Bourguignon
2013-03-30 18:11 Klaus-Dieter Bauer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).