[comp.emacs] GNU emacs to Unipress

cjosta@taux01.UUCP (Jonathan Sweedler) (12/21/88)

Does anyone have a program that would convert GNU emacs lisp code to
Unipress (Gosling) emacs syntax?  Is this even possible, or are there
too many differences?  I imagine that most simple programs could
be converted.  If such a program does not already exist, could someone
tell me what is necessary to do such a conversion?  

From what I have seen, I assume that the following is the GNU syntax:

(defun NEW-FUNCTION (LOCAL-VARIABLE-LIST) 
	"STRING WHOSE FUNCTION I DON'T KNOW BUT I ASSUME IS HELP OF SOME SORT" 
	(FN1)
	(FN2)...
)

I will have to convert this to (if somebody else hasn't done it already):

(defun
	(NEW-FUNCTION LOCAL-VARIABLE-LIST
		(FN1)
		(FN1)...
	)
)

And the "defvar" function?  This is also help?  I don't need a
conversion that will work 100% of the time (this probably isn't
possible anyway), but rather something just to get me started.

Thanks in advance.
-- 
Jonathan Sweedler  ===  National Semiconductor Israel
UUCP:    ...!{amdahl,hplabs,decwrl}!nsc!taux01!cjosta
Domain:  cjosta@taux01.nsc.com

pierson@mist (Dan Pierson) (12/22/88)

In article <959@taux01.UUCP>, cjosta@taux01 (Jonathan Sweedler) writes:
>Does anyone have a program that would convert GNU emacs lisp code to
>Unipress (Gosling) emacs syntax?  Is this even possible, or are there
>too many differences?  I imagine that most simple programs could
>be converted.  If such a program does not already exist, could someone
>tell me what is necessary to do such a conversion?  
 [ example omitted ]
>And the "defvar" function?  This is also help?  I don't need a
>conversion that will work 100% of the time (this probably isn't
>possible anyway), but rather something just to get me started.

I'm afraid it's much harder than it looks.  The problem isn't trivial
syntax differences, it's data types and all their implications.
Basically, Gosling MLisp isn't Lisp, it's more like Pascal with
parentheses.  If you compare some sources that solve similar problems
from the two systems, you'll see that the code is frequently _very_
different.  For example, since MLisp doesn't have lists, it can't have
alists.  Without alists, MLisp programs tend to be full of horrendous
nested (or multi-case) if's instead of a simple assoc of an alist.
This sort of thing is very pervasive and non-trivial to convert.

Think of a Lisp-to-C translator instead of a Pascal-to-C one.  It's
reasonable to write translators that take in source code of a language
and produce readable, maintainable source code of a similar language
at the same level.  It's _much_ harder to translate from a higher level
language to a lower level one.  For example, the Lisp compilers that
produce C "object code" (e.g. KCL) really produce object code; while
the resulting C code is ASCII, it's not particularly readable because
it is expressed in terms of very low level internals of the lisp
system rather than the Lisp source code.
-- 
                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@multimax.encore.com